Environment Variables: The Config Concept Every Dev Needs

Environment variables appear constantly — in deployment guides, config files, and "set your API key here" instructions — but they're rarely explained from scratch. The concept is small and, once understood, surprisingly powerful.

Values that live outside your code

An environment variable is a named value that lives in the environment your program runs in, rather than inside the code itself. Your program can read it at runtime — "give me the value of DATABASE_URL" — without that value being written into the source.

Why not just put it in the code?

Two big reasons: configuration and secrets.

• Configuration: the same code often runs in different places — your laptop, a test server, production — that each need different settings. Environment variables let the environment supply the right values, so one codebase behaves correctly everywhere.
• Secrets: passwords, API keys, and tokens should never be hardcoded or committed to version control. Keeping them in environment variables keeps them out of your source code and out of your git history.

Same code, different environments, different values — that's the whole point. The code asks "what's the database URL?" and each environment answers for itself.

How they're usually set

In development, they're commonly kept in a file (often named .env) that is deliberately not committed. In production, they're set on the server or platform. Your program reads them the same way regardless of where they came from.

The mental model

Think of environment variables as a small set of labelled notes pinned to the room your program runs in. The program reads the notes when it starts. Move it to a different room with different notes, and it adapts — no code change required. That separation of config from code is a habit that pays off the moment you deploy anything real.