Which environment variables end up in my app's browser code?
Any variable whose name starts with your framework's public prefix: VITE_ in Vite (Lovable, Bolt), NEXT_PUBLIC_ in Next.js, REACT_APP_ in Create React App, EXPO_PUBLIC_ in Expo, PUBLIC_ in SvelteKit and Astro. Those are copied into the JavaScript every visitor downloads.
Why
Build tools copy prefixed variables into the bundle on purpose, so the browser can use them. That is right for public values like the Supabase URL and anon key, and wrong for anything secret.
Secrets that must never have a public prefix: the Supabase service_role key or sb_secret_ keys, Stripe secret keys (sk_live_, sk_test_), OpenAI and other AI provider keys, email provider keys, and database connection strings. Use them only in server code, such as an edge function or API route, reading them from the host's environment.
If a secret was ever shipped with a public prefix, treat it as leaked: rotate it at the provider, then move it server-side.
How to check
- Search your .env files and code for public prefixes in front of anything that looks like a secret.
- Open your deployed site's JavaScript (the files under /assets/) and search for sk_, service_role and your provider names.
- Shippable checks both: the CLI reads your .env files and code, and the live scan reads the bundle your visitors download.
More on this: Secret keys shipped to the browser, from the Vibe-Code Top 10.
Check your app
Your first app is free, and it is read-only. You prove the app is yours with a one-line tag first.
More questions
- Is the Supabase anon key safe to expose?
- How do I check if my Supabase tables are readable by anyone?
- Is my Lovable app secure?
- Does verify_jwt protect my Supabase edge functions?
Updated 2026-10-06.