What Is an Environment Variable?
An environment variable is a named value stored outside your application's code, in the operating system or hosting platform, that the app reads at runtime. Developers use them to hold configuration and secrets: database passwords, API keys, and settings that change between a developer's laptop, a staging server, and production. Keeping these values out of the source code means secrets never get committed to a repository, and the same codebase can behave differently in each environment simply by changing the variables around it.
- Purpose
- Store config and secrets outside application code
- Read at
- Runtime, by the app process from its environment
- Common examples
- API keys, database URLs, feature flags, PORT
- Local convention
- .env files load variables in development (dotenv)
- Security guidance
- Never commit secrets to version control (OWASP)
What an environment variable is #
An environment variable is a key-value pair that lives in the environment surrounding a running program rather than inside the program itself. The name, like DATABASE_URL or STRIPE_SECRET_KEY, is uppercase by convention; the value is whatever the app needs, a connection string, a password, a toggle. When the application starts, it reads these values from its environment and uses them. The idea predates the web; operating systems have used environment variables for decades to configure programs. On the web it solves two everyday problems: keeping sensitive credentials out of the code, and letting one codebase adapt to different settings without edits. Instead of hard-coding 'connect to this database with this password,' the code says 'connect using whatever DATABASE_URL is set to,' and each environment supplies its own. That small indirection is why environment variables are foundational to any serious /services/web-app-development, from a simple contact form to a full customer platform reading dozens of configured values.
Why configuration belongs outside the code #
Bundling configuration into source code seems convenient until the same code needs to run in two places. Your laptop points at a test database; the live server points at the real one. If those addresses are baked into the code, you must edit and redeploy just to change environments, and you risk shipping a developer's settings to production. Environment variables invert this. The code stays identical everywhere; only the surrounding values differ. This principle, popularized by the widely cited Twelve-Factor App methodology, treats configuration as something injected from outside, not written inside. The payoff is real: safer deploys, easier collaboration, and the ability to rotate a password or swap an API key without touching a single line of code. For a business, it means your site can move between a staging preview and the live domain cleanly, and a developer can hand off a project without embedding their personal credentials in the files you receive.
Why secrets never belong in the repository #
The most important reason to use environment variables is security. Source code is usually stored in a version-control repository like Git, often hosted on GitHub, and shared across a team. Anything committed there lives in the history more or less forever, even if you later delete it. If an API key or database password is written directly into a committed file, anyone with repository access, or anyone who ever gains it through a leak, has your credentials. This has caused countless real breaches. Keeping secrets in environment variables, supplied only to the running server, avoids that exposure. Standards bodies like OWASP explicitly warn against hard-coding credentials for this reason. The practical rule developers follow: no passwords, tokens, or keys in the code, ever. If you audit a project and find secrets committed, treat them as compromised and rotate them. Proper secret handling is a core part of /services/website-security and something worth confirming with any developer you hire.
Working with a .env file #
Locally, developers keep variables in a .env file the app loads at startup, and exclude it from version control.
# .env (never commit this file)
DATABASE_URL=postgres://user:pass@localhost:5432/app
STRIPE_SECRET_KEY=sk_test_123abc
PORT=3000
# .gitignore (do commit this)
.env
.env.local
# reading it in Node.js
# require('dotenv').config()
# then use process.env.DATABASE_URLDifferent values for each environment #
A typical project runs in at least three environments: development on a laptop, staging for previews, and production for the live site. Environment variables let the same code behave correctly in each. Development might point at a local test database and use test payment keys that never charge real money. Staging mirrors production closely but stays private. Production holds the real credentials and live keys. Because only the variables change, a feature tested safely in staging behaves identically once promoted, minus the different values. This separation prevents expensive mistakes, like a test running against real customer data, or a live checkout accidentally using sandbox keys. It also supports clean handoffs during a /services/website-migrations project, where a site moves hosts and every credential must be reset on the new environment. When something works in one place but not another, mismatched or missing environment variables are one of the first things an experienced developer checks. Clear separation between these environments also lets a team preview and approve changes safely before they ever reach real customers on the live site.
Setting variables on your host #
In development you use a .env file, but on a live server you set environment variables through the hosting platform rather than a file. Every modern host provides this. Platforms like Vercel, Netlify, Render, and traditional cloud servers all expose a settings panel or command where you enter each key and value; the running app then reads them exactly as it would locally. Managed platforms encrypt these values and hide them from logs. On a plain server you might set them in the service configuration or a secrets manager. The key point for a business owner is that your secrets should live in the host's secure configuration, not in a file uploaded alongside your code. When choosing /services/managed-hosting, ask how the provider handles environment variables and secrets, because good hosts make rotation easy and keep values out of build logs, which matters the day you need to revoke a leaked key quickly and confidently without redeploying everything.
Common mistakes to avoid #
Several environment-variable mistakes recur across projects. The first is committing a .env file to Git; always add it to .gitignore before the first commit. The second is assuming variables update instantly, because most apps read them only at startup, so changing a value usually requires a restart or redeploy to take effect. A third is naming collisions or typos: because the code trusts whatever name it reads, a misspelled key silently becomes undefined, and the app may fail in confusing ways. A fourth is exposing secret values in a front-end build, discussed next. Finally, teams sometimes lose track of which variables an app needs; a committed .env.example file listing the required keys, with blank or fake values, documents them safely. Avoiding these traps is mostly discipline, and it is the kind of routine hygiene a /services/care-plans provider builds into ongoing maintenance so that credentials stay organized, current, and out of the wrong hands over a site's lifetime.
Public versus private variables in front-end apps #
A crucial subtlety trips up newcomers to modern front-end frameworks: not every environment variable stays secret. Frameworks like Next.js, Vite, and Create React App let you expose selected variables to the browser, usually by requiring a prefix such as NEXT_PUBLIC_ or VITE_. Any variable exposed this way is baked into the JavaScript sent to visitors, so anyone can read it by viewing the page source. That is fine for genuinely public values, like a public analytics ID or a client-side map key with domain restrictions. It is disastrous for a database password or a secret API key. The rule is simple but essential: only publishable, non-sensitive values get the public prefix; true secrets stay server-side and never reach the browser. Confusing the two is a common cause of leaked keys. If your site handles payments, logins, or customer data, confirming this boundary is a basic part of protecting it and a natural checkpoint during any /services/website-security review.
What this means for your site's safety #
For a business owner, environment variables are one of those invisible details that separate a professionally built site from a risky one. You will never see them, but their correct use is a strong signal of a developer who takes security seriously. The practical questions are easy to raise: Are our secrets kept out of the code and stored in the hosting platform? Is the .env file excluded from version control? Can a leaked key be rotated quickly without redeploying everything? Reassuring answers suggest the rest of the build is likely handled with similar care. Environment variables also make your site more portable and resilient, letting it move between hosts or environments cleanly, which matters during growth or a change of provider. None of this costs extra when done from the start; it is simply good practice. Confirming it is in place is a sensible part of any /services/website-security conversation, and it protects the credentials that guard your customers' data and your payment systems from casual exposure or an avoidable leak.
FAQ
Where are environment variables stored?
It depends on the environment. In development they usually sit in a local .env file the app loads at startup. On a live site they live in the hosting platform's secure settings, a dashboard field or secrets manager, and are handed to the running process. They are not stored inside your source code, which is the whole point.
Can environment variables be seen by website visitors?
Server-side variables cannot; visitors never see them. But front-end frameworks can deliberately expose specific variables to the browser, usually through a prefix like NEXT_PUBLIC_. Anything exposed that way is visible in the page source. So keep true secrets server-side and only expose values you are comfortable making public.
What happens if I commit a secret to Git by accident?
Treat it as compromised, even after deleting it, because it remains in the repository's history. Rotate the credential immediately, generating a new key or password and updating it in your host's environment settings. Then add the file to .gitignore. Simply removing the line in a later commit does not undo the exposure.
Do I need to restart my app after changing a variable?
Usually yes. Most applications read environment variables only when they start, so a changed value takes effect after a restart or redeploy, not instantly. Some platforms redeploy automatically when you edit a variable. If a new value seems ignored, an un-restarted process is the most common reason it was overlooked.
What is a .env file?
A plain-text file, named .env, that lists environment variables as KEY=value lines for local development. A library like dotenv loads it into the app at startup so your code can read the values. It should always be excluded from version control via .gitignore so its secrets never get committed and shared.
Are environment variables enough to secure my site?
They are one important layer, not the whole answer. They keep secrets out of your code, but you still need secure hosting, updated software, access controls, and encrypted connections. Think of environment variables as proper key management; full protection comes from combining them with the broader practices in a solid website-security plan.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?