VITE_, NEXT_PUBLIC_, EXPO_PUBLIC_: the prefix means publish

Anything in a VITE_, NEXT_PUBLIC_, EXPO_PUBLIC_ or REACT_APP_ variable ships to every visitor. What is safe there, what is not, and how to move secrets server-side.

The rule

Build tools copy certain environment variables into the JavaScript every visitor downloads:

Keeping the value in a .env file does not protect it. The prefix tells the build tool to publish it (reeve.page; SelfSec).

What is OK to publish

• Your Supabase URL and the publishable or anon key
• A Stripe publishable key (pk_...)
• Google keys that are restricted (see the AIza guide)
• Analytics IDs

What is never OK to publish

OpenAI, Anthropic, Gemini, OpenRouter, Groq or xAI keys, Stripe sk_ keys, Supabase sb_secret_/service_role keys, database passwords, and email API keys.

An August 2026 scan of 30,998 vibe-coded apps found OpenAI keys in 33 apps, Anthropic keys in 5, Supabase service_role keys in 3 and Stripe secret keys in 3. Another 204 apps had a random-looking value next to a name like "secret" or "password" (reeve.page).

How to fix it

1. Rename the variable without the prefix (for example OPENAI_API_KEY).
2. Move the code that uses it to the server: a Supabase Edge Function (supabase/functions/) or a Next.js API route (app/api/). Store the value in that platform's secrets, not in your app's .env (reeve.page).
3. Have your frontend call your function, never the AI provider directly.
4. Rotate the old key. It has already been published, and deleting it from your code doesn't take it back (SelfSec).

Prompt to give your AI builder

"Move all calls to into a server-side function. Store the key as a server secret without any VITE_/NEXT_PUBLIC_ prefix. The browser must never see the key."

Want the whole pre-launch process in one place? Get App Security for Vibe Coders, our $9 PDF playbook.

More guides

• Is my Lovable app secure?
• How to enable Supabase Row Level Security (RLS)
• Exposed Supabase service_role key: what to do now
• Lovable security checklist