What is environment and config management?
It is how your app gets the settings that differ between environments — database URLs, API keys, feature flags — without hardcoding them. Config comes from environment variables, and the goal is that dev, staging, and production differ only in their config, not their code.
Why it matters
Hardcoded config and leaked secrets are classic full-stack failures: a database URL committed to git, a key baked into the client bundle, "works in dev" breaking in prod. Clean config management keeps secrets safe and environments consistent, which is the floor for shipping responsibly.
What to learn
- Environment variables and
.envfiles - Keeping
.envout of git, with a committed example - Server-only secrets versus public client config
- Per-environment configuration
- Validating config at startup
- Secret management in production
- Dev/staging/prod parity
Common pitfall
Exposing a secret to the client bundle by giving it a public prefix (like
NEXT_PUBLIC_ or VITE_) so it "works" — and shipping the key to every browser.
Only truly public values get a public prefix; real secrets must stay server-side,
read only where the server runs. A leaked client-side key is compromised
instantly.
Resources
Primary (free):
- 12-Factor — Config · docs
- Next.js — Environment variables · docs
- OWASP — Secrets management cheat sheet · docs
Practice
Move all config in an app to environment variables: keep .env out of git with a
committed .env.example, separate server-only secrets from public client values,
and validate required config at startup so a missing variable fails fast. Done
when no secret is in git or the client bundle.
Outcomes
- Supply config via environment variables.
- Separate server secrets from public client config.
- Keep secrets out of git and the client bundle.
- Validate config at startup and keep environments in parity.