Configuration and environments

The same build artifact should run in development, staging, and production — differing only in configuration. Mixing config into code forces a rebuild per environment and is how secrets end up in git history. Keeping them separate is a small discipline with outsized payoff.

Config lives outside the code

The principle (from the well-known "twelve-factor" guidelines): store anything that varies between environments — database URLs, API endpoints, feature flags, credentials — outside the code, typically in environment variables. The code reads them at startup:

DATABASE_URL=postgres://localhost/dev   # development
DATABASE_URL=postgres://prod-host/app   # production

Same code, different environment, no rebuild. This is exactly what the deploy setup for this project does: a systemd unit sets PORT, HOSTNAME, and NEXT_PUBLIC_SITE_URL for the server to read.

Environments as a progression

Code typically flows through a ladder of environments, each more production-like:

• Development — your machine; fast feedback, fake data.
• Staging — a mirror of production for final verification.
• Production — the real thing, real users.

Promoting the same artifact up this ladder (the build-and-release lesson), with only config changing, is what makes "passed in staging" mean "will work in prod."

Never commit secrets

Credentials must never enter the repository — git history is forever, and a leaked key is a breach. Concretely:

• Keep secrets in environment variables or a dedicated secrets manager.
• Add secret files (.env, key files) to .gitignore.
• If a secret is ever committed, rotate it — removing the commit isn't enough, because clones and forks still have it.

Where to go next

That completes Production & Delivery. Once something's running in production, you need to see what it's doing. Next module: Observability & Operations.