Why your app's keys live in labelled envelopes outside the code, which envelopes the browser gets a copy of (VITE_, NEXT_PUBLIC_), and where secret keys actually belong, from the tools' own docs.
Most of the key leaks in vibe-coded apps come back to one misunderstanding about where settings live. TNW's April 2026 report cites a first-quarter assessment of more than 200 vibe-coded applications in which "more than 60% exposed API keys or database credentials in public repositories." That's not a coding failure. It's not knowing which box a secret goes in. So here are the boxes.
Secrets go in a locked drawer the server can open, not in the code on the desk. · Illustration generated with Higgsfield
The picture: labelled envelopes
Think of your app's code as a recipe, and environment variables as labelled envelopes handed to the cook at the start of the shift. The recipe says "use the ingredient in the envelope marked DATABASE_URL." The envelope's contents can differ between the test kitchen and the real restaurant without anyone rewriting the recipe. And the recipe can be shown to anyone, because the valuable stuff is in the envelopes.
Which envelope goes where
Public settings (site name, Supabase URL + publishable key)
Who can read it
Everyone, including visitors
Put here
A browser-exposed variable (VITE_ / NEXT_PUBLIC_) is fine
A server-only variable or the host's secrets store
Database password / connection string
Only your server
Server-only, never prefixed
The .env file itself
Anyone who can read the repo
Your machine only; listed in .gitignore
The prefix trap, in the tools' own words
Build tools need a way to know which settings the browser is allowed to have, so they use a naming rule. Vite's docs, used by many AI app builders: "Variables prefixed with VITE_ will be exposed in client-side source code after Vite bundling." and "VITE_* variables should not contain sensitive information such as API keys." Next.js works the same way the other way round: variables without the NEXT_PUBLIC_ prefix are "only available in the Node.js environment, meaning they aren't accessible to the browser." So the prefix isn't decoration. It's a switch that says "copy this into every visitor's browser."
What happens to a VITE_ variable
.env on your machine
VITE_OPENAI_KEY=… (a mistake)
The build
The tool copies every VITE_ value into the app's JavaScript
Your host
Serves that JavaScript to anyone who visits
Every visitor's browser
Now holds your key. See what that means below
.env on your machine
VITE_OPENAI_KEY=… (a mistake)
The build
The tool copies every VITE_ value into the app's JavaScript
Your host
Serves that JavaScript to anyone who visits
Every visitor's browser
Now holds your key. See what that means below
The name decides the destination. A secret with a public prefix ends up in step 4.
What "every visitor holds your key" means in practice is in your API keys are in the browser. For Supabase specifically, the publishable key is designed to be in that position; the secret key isn't, because it "provides full access to your project's data, bypassing Row Level Security."
Where secrets actually belong
On your computer: a .env file, listed in .gitignore so it never goes into your repository. Supabase's docs put it plainly: "A .env file committed to Git exposes every secret in it to anyone who can read the repository."
When the app is live: your hosting platform's environment-variables or secrets page. Supabase Edge Functions have their own (docs); Vercel, Netlify, Cloudflare and others have equivalents.
Used only by server code: a function that runs on the host, not in the browser, reads the secret and does the work. The browser calls that function.
Different per environment: use separate keys for preview and live where the vendor allows it, so a leaked test key can't touch real data.
Quick answers
What is an environment variable?
A named setting, like DATABASE_URL or OPENAI_API_KEY, that your app reads when it starts instead of having it written into the code. Locally they usually sit in a .env file; on a live host they sit in the platform's environment-variables or secrets settings.
Are VITE_ environment variables secret?
No. Vite's docs say variables prefixed with VITE_ are exposed in client-side source code after bundling, and that they should not contain sensitive information such as API keys.
Are NEXT_PUBLIC_ variables safe for API keys?
Only for keys designed to be public. Next.js bundles NEXT_PUBLIC_ variables into the browser code. Variables without the prefix stay on the server, which is where secret keys belong.
Should I commit my .env file to GitHub?
No. Add it to .gitignore. Supabase's docs warn that a .env file committed to Git exposes every secret in it to anyone who can read the repository.
This page has no affiliate links or sponsored placements. Security advice is only useful if nobody's paying for it. It isn't a substitute for a security review: if your app holds other people's personal data, payments or health information, have a developer or a security professional look at it before launch.
