direnv

I used to keep prod secrets in encrypted files checked into git. This meant every deploy required decryption, every env had its own schema, and one careless moment leaked everything. The cognitive load was constant. I moved to the pattern where only env var names live in version control. I commit a .env.example that lists what keys must exist, nothing more. All actual values come from the runtime environment. For local dev I use direnv to load from a .env file that git ignores. For production, Vercel handles injection directly in the UI. Running direnv allow in a project directory loads the .env automatically whenever you cd into it. The.env.example file stays lean: API_KEY=, DATABASE_URL=, AUTH_SECRET=. If someone forks the repo, they see the shape of what they need without seeing actual values. A leaked .env.example is just a checklist. This breaks down in teams that refuse to use direnv or need secrets in CI/CD systems that don't integrate cleanly. If your pipeline expects files instead of environment variables, you end up bolting on an extra layer anyway. But for anything touching Docker or serverless platforms, this approach removes a whole category of mistakes.