Environment variables

Code should not contain secrets. If a payment key is written into a file, anyone who sees the code, from a former contractor to a leaked repository, can use it. Environment variables keep those values in the server or hosting platform's settings instead, and the code simply asks for "the payment key" by name.

They also let one codebase behave correctly in each environment. The staging site reads test payment keys and a test database; the live site reads the real ones. Nothing in the code changes between them, only the variables.

How it works

Each variable is a name and a value, such as a name for the database password and the password itself. The operating system or hosting platform makes these available to the running program, and the code reads them at start-up or when needed. On most cloud hosting platforms, they are entered in a settings screen for each project and environment, often with values hidden once saved.

During development, variables are usually kept in a local file, commonly named .env, that sits beside the code but is excluded from Git so it is never committed. An example file with the names but no real values is kept in the repository so new developers know what to fill in.

A distinction matters on modern sites. Variables used by the back end stay on the server. Some frameworks also let variables be built into the front-end code that is sent to browsers, usually marked with a special prefix, and anything there is public. Secret keys must never be put in those. Changing a variable usually takes effect only after the application restarts or the site is rebuilt and redeployed, which surprises people who edit a value and see no difference.

Example

A travel agency's booking site uses a payment provider, an email service and a database. The code reads three variables for the payment key, the email key and the database connection. In staging these hold the provider's test key and a copy of the database; in production they hold the live values, entered by the developer in the hosting settings.

When a contractor who had access leaves, the agency rotates the keys: the developer generates new ones in each service, updates the variables in the hosting panel and redeploys. No code changes, nothing is committed, and once the old keys are revoked in each service they stop working. Had the keys been written into the code, they would also have been sitting in every copy of the repository's history.

Why it matters for your business

Leaked keys are one of the most common ways small businesses end up with unexpected bills or exposed customer data, because automated bots constantly scan public code for them. Environment variables are the standard defence and cost nothing extra. As an owner, you can ask where your site's secrets are stored, who can see them and how keys would be replaced if someone left. Keep a list of which services the keys belong to, and make sure those service accounts are in your business's name rather than a freelancer's.

Common mistakes

• Committing the .env file to the repository, putting every secret into the project's permanent history.
• Placing a secret key in a front-end variable that is built into code every visitor downloads.
• Using the same live keys in staging, so tests can send real emails or take real payments.
• Never rotating keys after staff or contractors with access leave.

Questions people ask

What is a .env file?

A .env file is a plain text file listing environment variables as name and value pairs, used mainly during development. It should never be committed to Git or uploaded where the public can download it. On live servers, values are usually set in the hosting platform instead.

Are environment variables secure?

They are much safer than writing secrets into code, but they are not a vault. Anyone with access to the server or hosting account can read them. Limit that access, keep secrets out of front-end variables and rotate keys when people with access leave.

What should I do if an API key leaks?

Revoke or rotate it immediately in the service it belongs to, update the environment variable with the new key and redeploy. Then check the service's usage logs for activity you do not recognise. Deleting the file that contained it is not enough, because copies may already exist.