Environment Variables Done Right: Stop Committing Secrets to Git

Environment variables are appropriate for: database connection strings and credentials, API keys and secrets, service URLs that differ between environments, feature flags controlled per environment, logging levels, port numbers, and any value that differs between development, staging, and production. They're not appropriate for: configuration that belongs in code (algorithm choices, data structure sizes), secrets that need rotation without redeployment (use a secrets manager), large config that would be unwieldy as env vars (use a config file), or sensitive data that needs audit logging (use a proper secrets management system like Vault, AWS Secrets Manager, or similar).

Never commit .env files containing real credentials. The file should be in your .gitignore immediately when you create it. Instead, commit a .env.example or .env.template file with all the keys but no values (or dummy placeholder values), so new developers know what variables to set up. The danger of committed secrets is permanent: even after deleting the file, the secret exists in git history and can be extracted with standard git commands. If you accidentally commit a secret, treat it as compromised immediately — rotate the credential before addressing the git history. GitHub secret scanning can catch some exposed secrets automatically.

In production, avoid .env files entirely. Use your platform's native secrets management: Vercel environment variables, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Kubernetes Secrets, or HashiCorp Vault. These systems provide access control (only authorized services can read a secret), audit logging (who read or changed what and when), rotation support (change the secret without changing code), and environment scoping (production can access prod secrets, staging cannot). For container-based deployments, inject environment variables at runtime rather than baking them into the image. Never include secrets in Docker images.