Environments, Secrets and Releases

Environments

• Development: your laptop.
• Staging: a copy of production with fake or anonymised data, where you test releases.
• Production: real users.

Many platforms create preview environments for each pull request automatically, so reviewers can click through changes before merging.

Secrets management

• Store secrets in the platform's environment settings or a secrets manager, never in Git, chat or tickets.
• Keep a .env.example documenting every variable with fake values.
• Use different secrets per environment; a leaked staging key must not unlock production.
• Rotate secrets when someone leaves or a leak is suspected.
• Give each service the least access it needs (a read-only API key for analytics, for example).

Releasing safely

1. Merge to main only when CI is green.
2. Deploy to staging, test the key journeys.
3. Deploy to production (ideally automatically from main).
4. Watch logs, error tracking and the health check for 15 minutes.

Rollbacks

Every platform keeps previous deploys. Know where the "rollback" button is before you need it. Rollbacks restore code, not data: a migration that dropped a column cannot be undone by redeploying old code.

Migrations without downtime

Make every schema change backward compatible with the code currently running:

1. Add new columns as nullable; deploy code that writes them.
2. Backfill data.
3. Deploy code that reads the new columns.
4. Only then remove old columns, in a later release.

Scaling

• Vertical: a bigger instance (more RAM/CPU). Increase workers to match.
• Horizontal: more instances behind a load balancer. Requires stateless apps: sessions in signed cookies or Redis, uploads in object storage, rate limits in Redis.

Change one variable at a time and measure response times and memory.

Check yourself

• What is a staging environment for?
• Why does a rollback not undo a migration?
• What must change before you can run more than one instance?