Environment variables
Named settings a program reads from outside its code, like where its database lives.
Environment variables are name-and-value pairs that the operating system hands to every program when it starts, such as DATABASE_URL=postgres://… or LOG_LEVEL=debug. The program reads them instead of having those values written into its code. They are an old Unix idea; one you have probably used without noticing is PATH, which tells the computer where to look for commands.
Their main job today is to let the same code run in different places. On a developer's laptop DATABASE_URL points to a small local database; in production it points to the real one. The code does not change, only the environment around it. This split between code and configuration is one of the principles of the well-known Twelve-Factor App guide for building cloud software.
They are also the usual way to give programs secrets, like an API key or a database password, without putting them in the repository. During development many projects keep these in a file named .env that a library loads at startup; that file must be listed in .gitignore so it never reaches Git. In the cloud, services like AWS Lambda, containers and CI/CD pipelines all let you set environment variables, and for sensitive values they can be filled from a secrets manager.
Keep in mind
- Configuration lives outside the code, so one build runs anywhere.
- Each environment, like local, staging or production, sets its own values.
- The common way to pass secrets without committing them.
- Keep
.envfiles out of Git.
