What are environment variables and secrets?

What it is, in plain words

Think of a shared office kitchen. The coffee machine is the same for everyone, but each person brings their own mug with their name on it. The machine just fills whatever is put in front of it.

Code works the same way. The program is the machine: the same for everyone who runs it. The environment variables are the mugs with names on them, the settings that differ from one place to the next. Things like:

• ACCOUNT_ID=... (which account to post to)
• API_TOKEN=... (the pass that proves the program may use that account)
• REPORT_EMAIL=... (where to send the result)

When the program starts, it reads these values from its surroundings, its “environment”, instead of having them typed into the code. Some of them are harmless, like an email address. Others are secrets: API keys, tokens and passwords that let the program act as you.

They usually live in one of three places:

1. A secrets or variables page in the hosting service or automation platform, where you paste the value once and the platform hands it to the program.
2. A .env file: a small text file next to the code with one setting per line, which the program loads when it starts.
3. The computer’s own settings, set by whoever installed the job.

A concrete example

My publishing jobs keep their account IDs and tokens in a .env file next to the code. That file is excluded from the code repository on purpose, so the tokens never get uploaded with the code.

Two things I learned from that setup, neither of them about the publishing logic itself:

The file was not loaded when nobody was watching. In August 2026 I set up a job to publish one chosen post at a set time. When I ran it by hand, my terminal loaded the .env file first. When the scheduler ran it, nothing loaded the file, so the token was simply empty and the job failed quietly. It only failed when unattended. The fix was to make the job load the file itself, plus a dry-run mode that prints whether the account and the token are present before anything is scheduled.

A setting keeps a job from hanging. My daily publishing scripts set two environment variables that tell the code-hosting tool never to ask for a password interactively. Without them, an expired login would make an unattended run sit and wait at a prompt nobody will ever see. With them, it fails straight away and the script can send me an alert.

Why it matters when you hire someone

You will rarely type an environment variable yourself, but they decide three things about what you are paying for.

Whether it runs without the freelancer. If the secrets live on the freelancer’s laptop or in their hosting account, the code you received is a machine without mugs. It will not start anywhere else. Ask for the list of variables the code needs, and make sure every value is stored somewhere you control. The guide on who owns the accounts covers the accounts side of this.

Whether “it worked in the demo” means anything. A demo usually runs in the freelancer’s own terminal, where the settings are already loaded. A scheduled run, a server or a fresh install may not have them. That gap is exactly what my first example was. The acceptance checklist for unattended automations asks for runs fired by the real scheduler for this reason.

Whether your keys leak. A secret pasted into the code ends up in every copy of the code, including the repository and any backup. A .env file that is not excluded gets uploaded with everything else. Once a key has leaked, the only fix is to cancel it and make a new one.

What to ask the freelancer

A good answer is short: a list of names, where each value lives, and a sample file. Keep it with your maintenance terms; after a move to a new machine or server, a missing variable is one of the first things to check.