Environment Variables

Environment variables let the same code run in different environments. Common examples are API URLs, feature flags, database URLs, and secrets.

DATABASE_URL=postgres://...
PUBLIC_API_BASE=https://api.example.com

Static frontend apps often bake variables at build time. Server apps can read runtime variables when the process starts.

Further Learning

• “12 factor app config” — config principle
• “build time vs runtime env variables” — deployment behavior
• “environment variable validation zod” — startup checks

Environment Variables

Environment variables let the same code behave differently in different places — your laptop, staging, production — without changing a single line of code. Think of them as settings you plug in from outside, not baked into the code itself.

DATABASE_URL=postgres://...
PUBLIC_API_BASE=https://api.example.com

Two flavors: build-time vs. runtime

• Build-time — baked into the app when it’s built (common for static frontends).
• Runtime — read fresh each time the server starts (common for backend servers).

Knowing which kind you’re dealing with matters: changing a build-time variable means you have to rebuild, not just restart.

The rule that matters most

Fail fast if something’s missing

Check required variables the moment your app starts, so a missing setting causes an obvious crash immediately — not a confusing failure later:

if (!process.env.DATABASE_URL) throw new Error('Missing DATABASE_URL')

In one sentence

Environment variables let the same code run differently across environments — keep secrets out of anything shipped to the browser, and validate required variables the moment the app starts.

Want to go deeper?

Switch to Expert mode above for build-time vs runtime behavior in more detail and validation with schema libraries.