Infrabasic

Environment Variable Management

Externalize application configuration into environment variables to separate config from code across environments.

Also known as: env vars, environment config, dotenv, .env files, runtime configuration

Description

Environment variable management is the practice of externalizing application configuration -- such as database connection strings, API keys, feature flags, and service URLs -- into environment variables rather than hardcoding them. This follows the third factor of the 12-Factor App methodology, enabling the same codebase to run in development, staging, and production with different configurations without code changes.

In practice, environment variables are managed through multiple mechanisms depending on the context: .env files for local development (loaded via dotenv or framework-native support), CI/CD platform secrets for build-time variables, container runtime environment injection (Docker -e flags or Compose environment blocks), and cloud-native secret managers (AWS Secrets Manager, HashiCorp Vault) for production. A validation layer at application startup (using libraries like envalid, zod, or joi) should parse, validate, and type-check all required environment variables, failing fast with descriptive errors if required values are missing.

Security considerations include never committing .env files to version control (.gitignore), rotating secrets regularly, using separate credentials per environment, implementing least-privilege access to secret stores, and auditing which services and personnel have access to production secrets. A .env.example file (with placeholder values) should be committed to document required variables for other developers.

Prompt Snippet

Implement environment variable management using a validated configuration module. Define a schema with zod that parses and validates all env vars at startup (DATABASE_URL, REDIS_URL, JWT_SECRET, API_KEYS), providing typed access throughout the application. Use .env files locally via dotenv with a committed .env.example documenting all required variables. In production, inject secrets from AWS Secrets Manager via ECS task definition secretsFrom, never from .env files. Fail hard on missing required variables with descriptive error messages including the variable name.