What is an environment variable — and why you never put a key in the code

Almost every beginner gets burned here. You connect some service, it hands you a key — a long string — you paste it straight into your code and push the project to GitHub. Minutes later, bots that scan public repos around the clock find your key and start spending your money. Sounds scary — but the fix is simple, and it's called environment variables.

What it is

An environment variable is a value that lives next to your app, but not inside the code. The code says "give me the key from the environment," and the value itself is stored separately — somewhere strangers won't look.

An analogy: the code is a recipe you can show anyone. You don't write your house key into the recipe — it's in your pocket. Environment variables are that pocket: the code can reach the key, but outsiders reading the recipe can't.

How it works

On your machine, secrets usually go into a file named .env (for environment). Inside are simple name = value lines:

OPENAI_API_KEY=sk-this-long-secret
DATABASE_URL=postgres://...

Then two things matter:

• Code reads the value by name, it doesn't store it. In the code you write something like process.env.OPENAI_API_KEY — "fetch the key from the environment." The secret itself never appears in the code.
• The .env file never enters the repo. You add its name to .gitignore, and Git ignores it — it stays only on your machine. So even public code doesn't leak your keys.

When you deploy the app, your host has its own place for the same variables — an "Environment Variables" box. You enter the same keys there, and on the server the code finds them by name the same way.

Why it matters to you

Beyond security, there's a second point — flexibility. You usually have two environments: your computer (development) and the server (production). They often need different values: a test database on your machine, the live one on the server. If the database address were baked into the code, you'd edit code on every move. With environment variables the code is identical, and values swap per environment. Change the environment — don't touch the code.

And when an AI agent generates a project for you, it almost always splits secrets into .env and drops process.env.* into the code. Knowing what that is and why, you won't freeze at an empty .env.example — you'll see right away: put your keys here, not in the code.

Where you'll meet it first

Usually when you connect your first external service: an API, a database, payments. They'll give you a key and say "put it in environment variables." Often there's a .env.example file next to the project — a template with names and no values. Copy it to .env, fill in your keys — and check that .env is in .gitignore. That one habit prevents the most common and most expensive beginner mistake.

Question: how is .env different from .env.example?

.env is your real secrets file — it isn't committed. .env.example is an empty template that is committed on purpose: it lists the variable names you need, without values. From it, anyone who clones the project sees which keys to set up.

Question: I already pushed a key to GitHub — now what?

Treat it as compromised immediately. Removing it from Git history isn't enough — a copy may already be out. The right move is to go to the service that issued the key and revoke it, then issue a new one and put it in .env. Cleaning history comes later; revoke the old key first.