Environment Variable

Explanation

Environment variables are key-value pairs available to a running process. In Node.js, accessed via process.env.VARIABLE_NAME. They're set by the OS, a shell script, a Docker container, a CI/CD platform, or a .env file loaded by dotenv. The primary use case is secrets and environment-specific configuration: database connection strings, API keys, OAuth client secrets, feature flags, service URLs — anything that varies between development, staging, and production. These must never be hardcoded in source code or committed to version control. A .env file lists environment variables for local development — it's always in .gitignore and never committed. The twelve-factor app methodology explicitly states: store config in the environment. Config is anything that varies between deployments; code is the same in all environments. This separation makes applications portable, auditable, and easier to deploy. In production, environment variables are injected by the platform: Vercel, Heroku, and Railway have UI for this; AWS uses Parameter Store and Secrets Manager; Kubernetes uses Secrets and ConfigMaps. For secrets that rotate frequently, dedicated secret management (HashiCorp Vault, AWS Secrets Manager) supports dynamic credentials and automatic rotation.

Code Example

// .env file — NEVER commit to git
// DATABASE_URL=postgresql://user:pass@localhost/mydb
// JWT_SECRET=super-secret-value-here
// NODE_ENV=development
// PORT=3000

// .gitignore — always add these
// .env
// .env.local
// .env.*.local

// Load .env in Node.js
require('dotenv').config(); // call before any process.env access

const config = {
  db:     process.env.DATABASE_URL,
  secret: process.env.JWT_SECRET,
  port:   parseInt(process.env.PORT ?? '3000', 10),
  isProd: process.env.NODE_ENV === 'production',
};

// Validate required env vars at startup — fail fast
const required = ['DATABASE_URL', 'JWT_SECRET'];
for (const key of required) {
  if (!process.env[key]) {
    console.error(`Missing required env var: ${key}`);
    process.exit(1); // crash at startup, not mid-request
  }
}

// NEVER hardcode secrets:
// const apiKey = 'sk-live-abc123'; // BAD: leaked in git history

Why It Matters for Engineers

Hardcoded credentials in source code are one of the most common causes of security breaches. When code is pushed to a public GitHub repo with API keys or passwords, automated scanners find and exploit them within minutes. Environment variables are the universal, correct solution. This also underlies deployment hygiene: different database URLs for each environment, feature flags for gradual rollouts, verbose logging in development and minimal logging in production — all require environment variables. Getting this right from day one prevents hours of debugging environment-specific bugs later.