🌍 Environment Management

Managing dev, staging, and production environments consistently.

Environment types

Environment	Purpose	Data	Access
Local/Dev	Individual development	Seed/mock data	Developer
Staging	Pre-production testing	Anonymized prod-like	Team
Production	Live users	Real data	Restricted

Environment parity

Keep environments as similar as possible:

• Same OS, runtime versions, and dependencies
• Same infrastructure (containers, load balancers)
• Same configuration structure (different values)
• Same deployment process

Configuration management

# .env.example (committed — template)
DATABASE_URL=
REDIS_URL=
API_KEY=

# .env (NOT committed — local values)
DATABASE_URL=postgres://localhost:5432/myapp_dev
REDIS_URL=redis://localhost:6379
API_KEY=dev-key-123

Rules

• Never commit .env files
• Commit .env.example as a template
• Validate env vars at startup (fail fast if missing)
• Use different secrets per environment
• Store production secrets in a vault, not env files

Feature flags

Control feature rollout per environment:

if (featureFlags.isEnabled('new-checkout', { env, userId })) {
  // new behavior
}

• Enable in staging first, then canary, then production
• Clean up old flags regularly
• Use a feature flag service (LaunchDarkly, Unleash, or DIY)

Database per environment

• Local: SQLite or Docker container
• Staging: Separate instance with anonymized data
• Production: Managed service with backups
• Never connect local code to production database