Skip to main content

​
1. Set a value

Use --stdin or --value-file to keep secret values out of argv, shell history, and process listings. --secret makes the value permanently write-only. Use --restart when the running app needs the new value immediately. Values are per environment: --env dev is the default, and --env prod targets production.

​
2. Inspect values

Use masked output when you only need confirmation:
Plain, non-secret values can be read normally. Secret-shaped values require explicit reveal:
Use --reveal-secrets only when you control where the output goes. Values marked --secret are never returned.

​
3. Scope to specific services

In multi-service apps, target specific services with the canonical repeatable --service flag. It also accepts a comma-separated list.
Never set backend secrets (DATABASE_URL, API keys, tokens) on frontend services. Build-time variables (VITE_*, NEXT_PUBLIC_*, REACT_APP_*) are baked into the JS bundle and visible to end users. Always use --service to target backend-only services when setting secrets.
Scoping rules:
  • Single-service app: env vars go to the only service (no --service needed)
  • Multi-service app, 1 service deployed: auto-targets that service
  • Multi-service app, 2+ services: --service is required; the CLI errors without it
Managed service env vars are provisioned at app scope. Default resources own conventional keys such as DATABASE_URL; named resources own suffixed keys such as REDIS_URL_CACHE. Legacy apps receive managed credentials on every service by default. In floo.app.toml, [services.NAME.env] managed = [] opts that service out, including in single-service apps. Both parsers ignore top-level [env] without error, so an existing [env] managed = [] no longer opts out; move it under [services.NAME.env]. Declare exactly which service receives each handle:
Run floo preflight --json and inspect env_injection_plan before pushing. The filter only applies to keys owned by floo managed-service records. A user-managed external DATABASE_URL remains a normal env var unless the app also has floo managed Postgres owning that key.

​
4. Build-time variables

Frameworks such as Next.js, Vite, and Create React App read some variables at build time and bake them into the bundle. floo passes every env var whose name starts with NEXT_PUBLIC_, VITE_, or REACT_APP_ to the image build as a Docker build arg, and injects it at runtime as well. No flag is needed; the prefix is the contract. The Dockerfile has to thread the value into the stage that runs the build, or it is empty when the bundle is compiled:
A promote rebuilds the image with prod’s values when prod has any of these variables, and otherwise reuses the dev image with the dev values baked in. Set the variable in both environments when the values differ. See Container contract.

​
5. Import from files

Use --all when you want floo to import from the configured env_file paths across services.

​
For agents

CLI reference

See the exact env set, env get, env list, env unset, and env import flags.