It’s how software says, “Use this key here, this database there, and this mode in production,” without writing those values into the code.
Think about an employee handbook and the office safe. The handbook can say, “To open payroll, use the credential in the safe.” It shouldn’t print the password on page 12. The instruction belongs in the handbook, the secret somewhere controlled. Your codebase works the same way: it says “read the key from QUICKBOOKS_API_KEY,” and the value lives outside the code, in an env file, hosting dashboard, or secrets manager. The same code runs on your laptop with test values and in production with real ones. Env vars aren’t only for secrets; they can hold a mode, a feature flag, a public URL, or a region.
How it shows up
You’ll hear about them when an app needs an API key, a database URL, or a deployment setting. “Set the env var in Vercel” means “put the value where the running app can read it, without hardcoding it.” Env vars also explain “it works locally but not in production”: the code is fine, but the production environment is missing a value or points to a different database.
Why you care
This matters with agents. Paste a real key into a prompt or source file and you may have exposed it. Store it in a managed secret system and pass it in as an environment variable, and you have a cleaner pattern, though not a risk-free one, since the running process can still read it. For deployment, they’re part of the checklist: which values does the app need, which are safe to expose, and which must stay private?