Environment Variables (Env Vars)
Dynamic values loaded into a program at runtime to configure its behavior without changing the code.
Detailed Explanation
Env vars are used to store configuration that varies between environments (development, staging, production), such as database URLs, API keys, and feature flags. Keeping these values outside the codebase is a core principle of the 'Twelve-Factor App' methodology and is essential for security and portable deployments.
Quick Summary
Environment variables are name=value pairs injected into a process at startup so the same binary can behave differently per environment. They are the cornerstone of Twelve-Factor configuration and the universal config interface for containerized apps.
Key Takeaways
- Read once at startup; treating them as runtime-mutable causes subtle bugs because not all libraries re-read.
- Local dev typically uses `.env` files; production uses the platform's secret store and the variables are injected into the process.
- Values are always strings; numbers, booleans, and JSON must be parsed by the application.
- Visible to anyone who can read `/proc/<pid>/environ` or run `printenv` in the container, they are not a secrecy mechanism on their own.
- Validate at boot with a schema (Zod, envalid, pydantic-settings) so missing/wrong vars fail loud instead of NaN-ing deep in business logic.
When to use it
- Connection strings (DATABASE_URL, REDIS_URL) that differ per environment.
- Feature flags and tunables that an operator should be able to change without a code change.
- Per-environment behavior switches (NODE_ENV, RAILS_ENV) that turn on dev-only middleware.
- Injecting credentials supplied by a secrets manager at deploy time.
Common Mistakes
- Committing `.env` files with real production values to git, assume any push leaks them forever.
- Reading env vars deep inside business logic instead of loading a typed config object once at boot.
- Forgetting that env vars are inherited by child processes, secrets leak to shells and spawned tools by default.
- Confusing `process.env.FOO` returning undefined for missing vs. empty string; explicit defaults and validation prevent quiet failures.
Environment Variables (Env Vars), Frequently Asked
Are environment variables a safe place to store secrets?
Safer than committing them to code, but not strong. Anyone who can run code in the process can read them, and they often leak into logs, error reports, and child processes. Use a dedicated secrets manager and treat env vars as the delivery mechanism, not the vault.
Should I commit `.env` to git?
Commit a `.env.example` with placeholders so contributors know what's needed. Never commit `.env` itself, add it to `.gitignore` and treat it as containing live credentials.
How do I validate env vars at startup?
Define a schema (Zod, envalid, pydantic-settings, godotenv with required tags) and parse it once at boot. If a required var is missing or the wrong shape, exit immediately with a clear error message, much better than NaN propagating through the app.