Environment Variables: Configuration Outside Code

Why it exists

Applications need to behave differently in different environments (development, staging, production) without code changes. Hardcoding configuration like database passwords or API endpoints for each environment would be unmanageable and insecure. Environment variables solve this by externalizing configuration from the code itself.

The mental model

An environment variable is a key-value pair that exists in the operating system's shell, outside of your application's source code. When your application process starts, it inherits a copy of these variables. It's like giving your program a set of instructions on a sticky note right before it runs, telling it which database to connect to or what API key to use. The program can then read these values at runtime.

How it works

The operating system maintains a list of variables for each user session. When you run a program, that new process gets a copy of the environment. In a shell, you might set one with a command like EXPORT API_KEY="12345". Your application code then uses a built-in library function (like os.getenv("API_KEY") in Python or process.env.API_KEY in Node.js) to read the value. The process can query any variable in its environment, like the TEMP variable to find a place for temporary files.

When to use it

Use environment variables for any configuration that changes between deployments or machines. This includes three main categories: first, secrets like API keys, database credentials, and encryption keys; second, environment-specific settings like a database host URL or a domain name; and third, toggling application behavior, such as setting a NODE_ENV to "production" to enable performance optimizations.

When not to use it

Avoid using environment variables for non-secret configuration that is static and shared across all environments, like a list of supported timezones. This type of configuration belongs in a regular config file committed to your repository. They are also not ideal for complex, nested configuration structures; for that, a dedicated config file (like YAML or JSON) is often clearer.

One canonical example

A web application needs to connect to a database. In development, it connects to a local database. In production, it connects to a different, managed database. Instead of hardcoding these connection strings, the code reads a single DATABASE_URL environment variable. The developer sets this variable on their local machine, and the deployment system sets a different value on the production servers. The code remains identical in both environments.