> ## 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 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

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

Your `git push` always deploys to dev first. 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
floo releases promote --app my-app \      # promote to production
  --tag v1.2.0
```

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.

## Per-environment config

Override config values per environment using `[environments.<name>]`:

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

[environments.dev]
access_mode = "public"
```

Resolution: `[environments.<name>]` wins over `[app]`. This lets you run a locked-down production app while keeping dev open for rapid iteration.

Common per-environment overrides:

* `access_mode` — public in dev, accounts in prod
* `resources.cpu` / `resources.memory` — small in dev, bigger in prod
* env vars — test keys in dev, live keys in prod

See the [config spec](/docs/reference/config-spec) for every override-able field.

## Per-environment env vars

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

```bash theme={null}
floo env set STRIPE_KEY=sk_test_... --app my-app --env dev
floo env set STRIPE_KEY=sk_live_... --app my-app --env production
```

Secrets and keys that differ between test and live systems should always be scoped this way.

## Why this matters

Every team wants the same thing: fast iteration without shipping breakage. Dev/prod gives you both:

* **Move fast in dev.** Push, see it live in seconds on the dev URL, share it with teammates.
* **Ship deliberately to production.** Promote when you're ready. Tag the release. Keep production stable.

No branch-per-environment dance, no staging cluster to maintain, no parallel infrastructure. Two URLs, one config file, one promote command.

<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>