> ## Documentation Index
> Fetch the complete documentation index at: https://getfloo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments

> Every floo app has a dev and production environment. Push to dev, promote to production.

Every floo app has two environments: **dev** and **production**.

## The two URLs

| Environment | URL pattern |
| - | - |
| dev | `<app-name>-dev.getfloo.app` |
| production | `<app-name>.getfloo.app` |

Apps created before September 29, 2026 keep their `on.getfloo.com` hosts (`<app-name>-dev.on.getfloo.com` and `<app-name>.on.getfloo.com`); their URLs do not change.

A push to the default branch deploys to dev. Production stays untouched until you promote.

## The flow

```bash theme={null}
git push origin main                      # deploys to dev
floo deploys watch --app my-app           # verify on the dev URL
# Promote to production
floo releases promote --app my-app --tag v1.2.0
```

Promote always moves the **latest live dev deploy** into production, so a build must go live in dev before it can reach production.

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:

```toml theme={null}
[app]
name = "my-app"
access_mode = "public"

[environments.prod]
access_mode = "accounts"
```

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 app's stored mode when the environment does not exist yet). 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, including a looser mode (`accounts` to `public`) unless your org or app has an approval policy that gates access broadening. With that policy on, make a looser change in dev with `floo redeploy --app my-app --rebuild` and an org-admin-scoped credential. Environment names other than `dev`, `prod`, and `preview` fail the deploy.

Per-environment edge policy goes under `[environments.dev.edge]` and `[environments.prod.edge]`. See the [config spec](/docs/reference/config-spec#edge) for its fields.

## Per-environment env vars

Set an env var for only one environment with `--env`:

```bash theme={null}
floo env set STRIPE_KEY --stdin --secret --app my-app --env dev
floo env set STRIPE_KEY --stdin --secret --app my-app --env prod
```

Scope every secret or key that differs between test and live systems this way.

<CardGroup cols={2}>
  <Card title="Releases and rollbacks" href="/docs/guides/rollbacks">
    How promote flows work, and how to roll back production when you need to.
  </Card>

  <Card title="Environment variables" href="/docs/guides/environment-variables">
    Full scoping rules: app, service, environment.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.