Environment Variables Are Not Configuration Magic

The starting point

Environment variables are everywhere in modern applications, which can make them feel like a complete configuration system. They are not. They are simply one mechanism for providing values to a process at runtime. Good configuration design still requires deciding which values are secrets, which are public, which have safe defaults, which environments require different values, and what should happen when a required value is missing.

Configuration has different kinds of values

A database password is fundamentally different from a public site origin. Treating both as generic strings hides an important security distinction. Server-only secrets should remain on the server boundary, while values intentionally exposed to browser code need a different handling model.

Required configuration should also fail clearly. A missing database URL should produce an obvious startup or request error rather than silently falling back to a value that points at an unexpected database.

The environment is part of the system

Development, preview, and production environments often need different values. That does not mean the application should contain dozens of conditional branches. The application should define a small configuration contract and let deployment supply the environment-specific values.

Good configuration management therefore combines naming, validation, secret handling, and documentation. Environment variables are just one piece of that system.