Generated Env Files

CNOS is runtime-first, but many repos still rely on .env.local, .env.stage, or similar files.

Use generated env files as a bridge, not as the source of truth.

One-shot build

cnos build env --profile local --to .env.local
cnos build env --profile stage --to .env.stage
cnos build env --profile prod --to .env.prod
cnos build env --profile local-domain --format docker-env --to .docker/runtime/current.env

Watched dev loop

cnos dev env --profile local --to .env.local -- pnpm dev

Public-only frontend artifacts

cnos build env --public --framework vite --profile local --to .env.local
cnos build env --public --framework next --profile prod --to .env.production

Recommended policy

keep .cnos as the source of truth
keep generated .env.* files gitignored
migrate app code toward direct CNOS reads over time
keep secrets on runtime/vault flows instead of materializing them into env files by default
use docker-env when Docker or Docker Compose expects a runtime env file