How Environment Variables and Secrets Work in Production

Environment variables keep configuration outside your code, but that does not automatically make every value secret. Anything sent to the frontend can be inspected in the browser; real secrets should stay on the server.

What happens to an environment variable?

  1. Your application needs a configuration value — an address, an ID, a key of some sort.
  2. You decide one thing about it: would it be a problem if a user could read this?
  3. Values that are fine to read can be handed to your frontend code, where they belong.
  4. Anything your frontend code reads ends up in the JavaScript you ship, so treat it as public from the moment you make that choice.
  5. Values that must stay private are set in your production environment on the host, and only server-side code reads them.
  6. Your backend uses those values to talk to other services, so the request is authenticated without the secret ever leaving the server.

The main pieces

Public configuration — Configuration your application needs that was never meant to be private: the address of your site, an analytics ID, a key a provider publishes for use in a browser. It lives in an environment variable for the same reason a secret does — to stay out of your source code — and that is where the similarity ends.

Your frontend — The part of your application that runs in the visitor’s browser. Whatever it reads has to travel there with it, which is why a value used here stops being a decision you can take back once the site is live.

The visitor’s browser — Every visitor gets your frontend code, and every visitor can open the developer tools and look through it. This is not a flaw to work around; it is what the browser is. Any value that arrives here should be one you were happy to hand out.

A secret — A password, a private API key, a signing secret. It is stored the same way as public configuration — as an environment variable — which is exactly why nothing about the variable itself tells you it is sensitive. What makes it a secret is that only your server should ever be able to read it.

Production environment — The settings your hosting or deployment platform provides for configuration and secrets. Values live there rather than in your repository, so they never sit in Git and can be changed without editing code. Providers like Hostinger offer this; the idea is the same wherever you deploy.

Your backend — Your server-side code. It runs on the host, not on anybody’s device, so a value it reads goes no further. This is what makes it the right place to hold a secret — and the reason a browser asks it to act rather than acting itself.

An external service — Whatever your application talks to — a payments API, an email sender, an AI provider. Your backend attaches the secret and makes the request from the server, so the call is authenticated and the key is never part of anything a visitor downloads.

Does putting an API key in .env make it secret?

No. A .env file keeps a value out of your source code, which is worth doing — but it says nothing about where the value ends up. If your frontend build reads it, the value is written into the JavaScript sent to every visitor, and anyone can open the developer tools and read it there.

This is where framework prefixes catch people out. A name like VITE_ or NEXT_PUBLIC_ is not a security setting; in most frameworks it means the opposite — it is how you ask for that value to be included in client code on purpose.

Keep local .env files with real secrets out of Git as well. That is a separate habit and a good one, but it protects your repository, not your bundle.

So the question worth asking is not whether a value is in .env. It is whether that value ever reaches the browser.

What should be public and what should stay secret?

The question is never "is it in a .env file?" — it is "does this value reach the browser?". Plenty of configuration is meant to be visible, and hiding it buys nothing.

A value being called a key does not settle it either. The provider decides which of their keys are designed to be public and which are not, so check what they say about the one you are holding.