Environment Variable

An environment variable is a named value stored in the operating system or deployment platform's environment (outside the application's source code) that a running program can read at startup or runtime to configure its behavior — database URLs, API keys, feature toggles, or which environment it's running in (development, staging, production). The core principle they enable is the separation of configuration from code: the exact same codebase and build artifact can behave differently in different environments purely based on which environment variables are set, without needing separate code branches or hardcoded values per environment. Why it matters for AI/SaaS builders: environment variables are the standard, secure way to handle secrets (API keys, database passwords) — they should never be hardcoded into source code or committed to version control, both because it's a serious security risk (a leaked GitHub repo instantly leaks every secret in it) and because different environments legitimately need different values (a staging database URL is not the production database URL). Nearly every SDK and framework — including AI provider SDKs like Anthropic's — reads its API key from an environment variable (`ANTHROPIC_API_KEY`) by convention specifically so keys never end up hardcoded in a codebase. How it works: environment variables are typically set at the OS/shell level (`export API_KEY=abc123`), in a `.env` file loaded by a library like `dotenv` for local development (with `.env` explicitly excluded from version control via `.gitignore`), or configured through a hosting platform's dashboard/CLI for staging and production (Vercel, Heroku, AWS all provide a UI or CLI for setting them per-deployment). The application reads them at runtime via a language-standard mechanism (`process.env.API_KEY` in Node.js, `os.environ["API_KEY"]` in Python). Worked example: a SaaS app's codebase contains `const stripeKey = process.env.STRIPE_SECRET_KEY;` with no actual key value anywhere in the source. Locally, a developer's `.env` file (never committed to Git) sets `STRIPE_SECRET_KEY=sk_test_51H...` pointing at Stripe's test mode. In production, the hosting platform's dashboard has `STRIPE_SECRET_KEY` set to the real `sk_live_...` key, entered once through a secure UI and never appearing in the codebase at all. The identical application code runs safely in both environments — test charges locally, real charges in production — purely because of which environment variable value is injected at runtime. If that same key were hardcoded into the source file instead, it would be committed to Git history permanently (even if later deleted from the current version of the file) and exposed to anyone with repo access, which is exactly the kind of leak that environment variables exist to prevent.