Skip to main content
Every app on floo has two environments out of the box: dev and production. This is the backbone of how you ship safely.

​
The two URLs

Your git push always deploys to dev first. Production stays untouched until you promote.

​
The flow

Promote always moves the latest live dev deploy into production. You cannot accidentally promote a broken build, it has to have landed cleanly in dev first. A promote reuses the dev image, with one exception: when the prod environment has any env var prefixed VITE_, NEXT_PUBLIC_, or REACT_APP_, floo rebuilds the same commit from archived source with the prod build args, so the prod bundle carries prod values.

​
App config across environments

access_mode applies to every environment by default, and each environment can override it:
Every forward deploy freezes one access mode for each of dev, prod, and preview, resolved in this order: [environments.<env>] access_mode, then [app] access_mode, then the environment’s current applied mode. The mode for the target environment is applied when that deploy goes live; a dev deploy never changes prod. Promote and release copy the map the deploy froze, and they cannot loosen an environment from accounts or password to public; make that change through an authenticated floo redeploy. Environment names other than dev, prod, and preview fail the deploy. Per-environment edge policy is supported under [environments.dev.edge] and [environments.prod.edge]. See the config spec for the current fields.

​
Per-environment env vars

Set an env var for only one environment with --env:
Secrets and keys that differ between test and live systems should always be scoped this way.

Releases and rollbacks

How promote flows work, and how to roll back production when you need to.

Environment variables

Full scoping rules: app, service, environment.