Environment Variables Are Not Secret Management
Environment variables are a fine delivery mechanism for configuration. Managing secrets is a separate job with its own rules.
Most applications read their database URL, API keys and feature flags from environment variables, and that is reasonable. Problems begin when the variables themselves are treated as the secret store: pasted into chats, committed in .env files, copied between machines and never rotated.
Separate configuration from secrets. A port number or a public URL is configuration; it can live in version control. A database password or a signing key is a secret; it must never be committed, and its exposure must be treated as an incident. Keep a committed .env.example with placeholders so the required variables are documented without their values.
Store secrets in a system designed for them: your hosting platform's variable store, a cloud secret manager or a vault. These provide access control, audit logs and rotation. Inject them into the process at runtime rather than baking them into images or build artifacts.
Rotate keys when people leave, when a laptop is lost, and whenever a secret might have been exposed. Use separate credentials for development, staging and production so a leaked development key cannot touch real data. Scope credentials narrowly: a key that can only read is far less dangerous than one that can do everything.
Finally, fail loudly. An application that starts with a missing or malformed secret and falls back to a default is hiding a serious problem. Validate required variables at boot and refuse to run without them.
