# Environment configuration

Three environments, explicitly separated so production never silently inherits a dev default:

| | dev | staging | production |
|---|---|---|---|
| Where it runs | any dev machine, `platform/docker-compose.dev.yml` | homelab or a resource-limited slice of the dedicated server once it exists | rn-platform-01 / rn-lab-host-01 on Proxmox |
| `COOKIE_SECURE` | unset (plain HTTP) | `1` if served over HTTPS, else unset | `1` — required |
| `TRUST_PROXY` | unset | `1` if fronted by a proxy | `1` — required, real reverse proxy in front |
| `ADMIN`/owner bootstrap | `platform/api/bootstrap-owner.js` manually | same, against staging DB | same, against production DB, run once by a human, credential handled per `docs/PRODUCTION_DEPLOYMENT.md` §10 |
| Secrets | `platform/.env` (gitignored, throwaway) | `infra/environments/staging/*.env` (gitignored, real but low-stakes) | `infra/environments/production/*.env` (gitignored, real, backed up per `docs/BACKUP_DR.md`) |
| Lab image | built locally, `:test` tag | tagged build from CI, `:staging-<sha>` | tagged release, `:<sha>` or `:vX.Y.Z`, never `:latest` |

Each environment directory holds `*.env.template` files (tracked) — copy to `*.env` (gitignored
via `infra/.gitignore`) and fill in real values. **Never commit a filled `.env` file.** See
`docs/PRODUCTION_DEPLOYMENT.md` §10 for how production secrets are actually generated, stored,
and rotated (not just "don't commit them").

`dev/` is intentionally thin — it just points back at the existing
`platform/docker-compose.dev.yml` workflow (Phase 1–3B, unchanged); there was nothing new to
build there for Phase 4.