Environment Variable

Every program on a computer needs settings. Where is the data located? Which password is used to access another service? Should the program run in test mode or for real users? Such information could be written directly into the program code, but that is impractical and insecure. Instead, it is stored as an environment variable: a name and a value that the operating system hands to the program at startup. A typical example looks like this: DATABASE_URL=postgres://server:5432/data. At startup, the program asks for the name and gets the value back.

Why passwords don’t belong in the code

The most important reason for environment variables is security. Program code today is almost always stored in version control systems like GitHub, that is, on servers that many people have access to. If an access key for an AI service sits right in the code, it ends up there too. Such accidentally published keys are regularly found and misused by automated scanning programs. Bills of several thousand euros for compute time used by someone else are not uncommon in such cases.

The second reason is flexibility. The same software usually runs in several places: on the developer’s laptop, on a test server, and on the real server for customers. Different databases and different keys are needed everywhere. With environment variables, the program code stays identical in all three places. Only the values from outside differ.

This principle even has a name. The so-called Twelve-Factor methodology, a well-known collection of recommendations for web applications, explicitly demands: configuration belongs in the environment, not in the code. Anyone who follows this can move an application to a different server without changing the program code.

From the operating system to the program

Technically, the operating system manages a list of names and associated values for each running process. A process is simply a program that is currently being executed. If this process starts another program, it passes its list on to the child. Inheritance therefore always flows downward. A program can change its own variables, but not those of the program that started it.

During development, the values are usually written into a text file called .env. It contains, line by line, entries following the pattern NAME=VALUE. This file is deliberately excluded from version control so that it does not become public. On real servers, other systems take over this task, such as the hosting provider’s management interface or dedicated secret vaults.

A common misconception: environment variables are not encrypted. They are simply text managed by the operating system. Anyone who already has access to the server can generally read them out. So they protect against secrets slipping into the code — not against someone breaking into the server.

From PATH to OPENAI_API_KEY

The best-known environment variable is called PATH and exists on Windows, macOS, and Linux. It contains a list of folders in which the system searches for programs. Typing a word into a command line triggers exactly this search. Error messages like “command not found” usually just mean that the appropriate folder is not listed in PATH.

In the AI world, one mainly encounters OPENAI_API_KEY or similarly named variables from other providers. Almost every guide for an AI programming tool begins with the step of setting this key as an environment variable. The program library then reads it automatically, without it needing to be mentioned in the code.

Environment variables also show up in the news, usually when something has gone wrong. Reports about data leaks frequently cite improperly secured .env files as the cause. Attackers systematically scan the internet for servers that accidentally serve up such files publicly. A single configuration mistake is then enough to expose thousands of credentials.