Best Practices

Environment files are deceptively simple. A few KEY=value pairs, what could go wrong? Quite a bit, actually. Here’s how to manage them without shooting yourself in the foot. The Basic Rules 1 2 3 4 # .env DATABASE_URL=postgres://localhost:5432/myapp API_KEY=sk_test_abc123 DEBUG=true Rule 1: Never commit secrets to git. 1 2 3 4 5 6 # .gitignore .env .env.local .env.*.local *.pem *.key Rule 2: Always commit an example file. 1 2 3 4 # .env.example (committed to repo) DATABASE_URL=postgres://localhost:5432/myapp API_KEY=your_api_key_here DEBUG=true New developers copy .env.example to .env and fill in their values. The example documents what’s needed without exposing real credentials. ...

Deploy on Friday. Release on Monday. That’s the power of feature flags. The traditional model couples deployment with release—code goes to production, users see it immediately. Feature flags break that coupling, letting you deploy dark code and control visibility separately from deployment. The Core Pattern A feature flag is a conditional that wraps functionality: 1 2 3 4 5 if (featureFlags.isEnabled('new-checkout-flow', { userId: user.id })) { return renderNewCheckout(); } else { return renderLegacyCheckout(); } Simple in concept. Transformative in practice. ...