Skip to main content

​
1. Set a value

--stdin or --value-file keeps secret values out of argv, shell history, and process listings. A new key is stored as a write-only secret unless its name has a build-time prefix or you pass --config; --secret turns an existing config key into a secret. --restart redeploys dev so the running app gets the new value immediately. Values are per environment: --env dev is the default, and --env prod targets prod. --restart works only for dev. A prod change takes effect with the next prod release; see Environments.

​
2. Inspect values

floo env list masks every value:
floo env get returns config values, such as one set with --config. A secret-shaped config value, such as an injected DATABASE_URL, needs the global --reveal-secrets flag:
Use --reveal-secrets only when you control where the output goes. Secrets are never returned.

​
3. Scope to specific services

In multi-service apps, target services with the repeatable --service flag, which 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. Set secrets with --service pointing at backend-only services.
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. Until a service declares managed, every service receives managed credentials. In floo.app.toml, [services.NAME.env] managed = [] opts that service out, including in single-service apps. The CLI rejects top-level [env] as an unknown key; a deploy ignores it with an unknown_manifest_key warning. Move [env] managed = [] under [services.NAME.env]. Declare exactly which service receives each handle:
Run floo preflight --json and inspect env_injection_plan before pushing. The filter applies only 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

Next.js, Vite, and Create React App bake some variables into the bundle at build time. 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. The prefix is the contract; no flag is needed. The Dockerfile must thread the value into the stage that runs the build, or it is empty when the bundle compiles:
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

--all imports from each service’s configured env_file path.

​
JSON output

CLI reference

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