Introduction
Environment variables are key-value pairs provided to your process by the OS or runtime. They’re the standard way to pass config and secrets without hardcoding. Below: how they work and how to use them safely. They keep configuration and secrets out of source code so you can change values per environment and avoid committing credentials. We'll cover how to set and read them, validate and document them, and make your app fail fast when something is missing.
What Is Environment Variables Explained
An environment variable is a named value (e.g. DATABASE_URL=postgres://...) that the process can read at runtime. The OS or process manager (systemd, Docker, your IDE) sets them before starting the app. The app reads them via the language API (e.g. process.env in Node, os.environ in Python). They’re typically used for config that changes per environment (dev, staging, prod) and for secrets.
Why It Matters
Hardcoding URLs, keys, or ports makes it hard to switch environments and leaks secrets into the repo. Environment variables keep config and secrets outside the code so you can change them per deploy and avoid committing them.
How to Calculate It
| Variable | Example value |
|---|---|
| PORT | 3000 |
| MAX_CONNECTIONS | 100 |
| TIMEOUT_MS | 5000 |
| LOG_LEVEL | 2 |
Real-Life Example
Your app needs a DB URL. In dev you put it in .env (and .env is in .gitignore). In production the platform injects DATABASE_URL. The code does const url = process.env.DATABASE_URL; if (!url) throw new Error('DATABASE_URL required');. Same code, different values per environment.
Common Mistakes
Committing .env or real secrets. Not validating env vars at startup (failing later in a weird way). Using different names per environment. Assuming a default that’s wrong in prod. Logging env vars (they may contain secrets).
Practical Tips
- Keep secrets out of the repo; use .env locally and platform secrets in prod.
- Document required vars in .env.example (no real values).
- Validate and normalize env vars once at startup.
- Use a single source of truth per env (one .env or one config service).
- Don’t log or expose env vars in errors or debug output.
FAQs
Conclusion
Environment variables keep config and secrets out of code. Set them per environment, validate at startup, and never commit real secrets. Use .env.example to document what’s needed.