# settings.py import environ env = environ.Env() environ.Env.read_env(os.path.join(BASE_DIR, '.env.development')) To prevent your project from descending into "environment variable hell," follow these battle-tested principles. 1. Always Commit .env.development (With Care) This is a controversial point. You should not commit .env.production (it contains secrets). However, .env.development should be committed to your repository because it contains no real secrets—only local URLs, mock keys, and safe defaults. Committing it ensures all developers on your team have the same baseline configuration.
// package.json
The next time you start a new project, don't leave your team to guess which variables they need. Write the .env.development file first—and watch your onboarding friction disappear. .env.development
The .env.development file is a used exclusively when your application runs in a development environment. # settings
"scripts": "dev": "node scripts/validate-dev-env.js && NODE_ENV=development nodemon src/index.js" You should not commit
const z = require('zod'); const envSchema = z.object( API_URL: z.string().url(), PORT: z.string().transform(Number).default('3000'), DEBUG_MODE: z.enum(['true', 'false']).transform(v => v === 'true') );
The validation script checks that required .env.development keys exist before the app starts. For complex microservice architectures, you can combine multiple files: