Environment Variable
Environment variables are settings that live outside your code. Instead of writing your database password directly in your source code (which would be visible to anyone who reads the code), you store it as an environment variable. Your code reads the value at runtime. This keeps secrets safe and lets you use different settings in different environments (development, staging, production) without changing the code.
An environment variable is a key-value pair set in the operating system or process environment, accessible to running applications via system calls. They are the standard mechanism for externalizing configuration from code.
Twelve-Factor App methodology (factor III: Config) mandates storing configuration in environment variables, separating config from code.
Common environment variables in IT:
| Variable | Purpose |
|---|---|
DATABASE_URL | Database connection string |
API_KEY / SECRET_KEY | Authentication credentials |
NODE_ENV / FLASK_ENV | Deployment environment (development, production) |
PORT | Network port the application listens on |
LOG_LEVEL | Logging verbosity (debug, info, warn, error) |
PATH | Directories searched for executables |
HOME | Current user’s home directory |
TZ | Timezone setting |
.env files: store environment variables in a file (.env) for local development. Libraries like dotenv (Node.js), python-dotenv (Python) load them automatically. Critical rule: never commit .env files to version control. Add .env to .gitignore.
Precedence (typical):
- System environment (set by OS or shell)
- Process-level (set by Docker, systemd, CI/CD)
.envfile (loaded by application framework)- Default values in code (fallback)
Working with environment variables
# Set an environment variable (shell)
$ export DATABASE_URL="postgres://user:pass@localhost:5432/mydb"
# Read in your application
$ echo $DATABASE_URL
# .env file (never commit this)
DATABASE_URL=postgres://user:pass@localhost:5432/mydb
API_KEY=sk-abc123
NODE_ENV=development
# Docker: pass env vars to containers
$ docker run -e DATABASE_URL="postgres://..." myapp
$ docker run --env-file .env myapp
# Node.js: access environment variables
# process.env.DATABASE_URL
# Python: access environment variables
# import os; os.environ["DATABASE_URL"]
# Verify what a process sees
$ env | grep -i database
$ printenv DATABASE_URL Environment variables are universal across every programming language, framework, and deployment platform. Docker passes them with -e or --env-file. Kubernetes stores them in ConfigMaps and Secrets. CI/CD platforms (GitHub Actions, GitLab CI) inject them as pipeline variables. Cloud platforms (Heroku, Render, Vercel) provide web UIs for setting them. The number one security incident related to environment variables is accidentally committing a .env file to Git: once a secret is in Git history, it is exposed even if you delete the file later. Tools like git-secrets, truffleHog, and GitGuardian scan repositories for accidentally committed credentials. For secret rotation, use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) instead of static environment variables.