What is an environment variable, in plain English?

Environment variable is a mouthful of a term for a simple and important idea. It is where your app keeps its secrets and its settings, safely apart from the code itself. Understanding it explains two things at once: why secrets must be handled carefully, and why an app that worked in preview so often breaks the moment it goes live.

The idea behind it

Your app needs certain sensitive settings to work: the password to its database, the keys to any services it uses for payments or email, and so on. There are two places these could go. You could write them directly into the code, which is easy but dangerous, because code often ends up somewhere it can be read. Or you could keep them separately, outside the code, and have the app look them up when it runs. That separate store is what environment variables are. The name is literal once you unpack it: they are values, variables, that belong to the environment the app is running in, rather than to the code itself. The code says use the database password, and the environment supplies the actual password at the moment it runs. The secret and the code stay apart, which is exactly the point.

Why secrets must stay out of the code

This separation is not fussiness; it is one of the most important safety practices there is. Code has a habit of travelling. It gets pushed to repositories, shared with helpers, deployed to hosts, and sometimes accidentally made public. Anything written into the code travels with it. So a database password or an API key sitting in the code is a password sitting in every copy of the code, waiting for one of those copies to end up somewhere a stranger can read it. And when a secret leaks, the consequences are real: someone can read your database, run up charges on your account, or misuse a service in your name. Keeping secrets as environment variables means the code can be shared freely without the secrets going with it. AI builders sometimes fail at this, leaving keys sitting in the code or logs, which is why an exposed key is one of the most common serious holes in AI-built apps.

The other job: different settings per environment

Environment variables do a second useful job that explains a common mystery. The same app often runs in more than one place: a private preview where you build and test, and the live version real customers use. These are different environments, and they may need different settings, perhaps a test database in preview and the real one when live. Because the settings live in the environment rather than the code, the same code can run in both places and simply pick up whichever values are set where it is running. This is elegant, but it has a sharp edge. When you deploy your app to the live host, the code travels but the environment variables do not come along automatically, because they belong to the environment, not the code. Unless you set them again on the live host, the live app has the instructions but none of the secrets, so it cannot connect to anything.

Why this explains the classic broken launch

This is the reason behind one of the most common frustrations people hit: the app works perfectly in preview, then shows a blank page or an error the moment it is live. It feels random, but it is almost always the same thing. The preview environment had all the secret settings filled in, so everything connected. The live environment is fresh and empty until you fill it in, and the deploy did not bring the secrets across on purpose. The app is not broken; it is missing its keys. The fix is to add every environment variable your app needs to the live host's settings and redeploy, so it picks them up. And the way to avoid the whole category of surprise is to keep a simple list of every secret your app depends on and confirm all of them are set on the live host before you call a launch finished. Understanding environment variables turns that mystery into a five-minute check.