Skip to content
general software-development

Environment Variable

environment-variables configuration security devops
Plain English

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.

Technical Definition

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:

VariablePurpose
DATABASE_URLDatabase connection string
API_KEY / SECRET_KEYAuthentication credentials
NODE_ENV / FLASK_ENVDeployment environment (development, production)
PORTNetwork port the application listens on
LOG_LEVELLogging verbosity (debug, info, warn, error)
PATHDirectories searched for executables
HOMECurrent user’s home directory
TZTimezone 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):

  1. System environment (set by OS or shell)
  2. Process-level (set by Docker, systemd, CI/CD)
  3. .env file (loaded by application framework)
  4. 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
In the Wild

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.