Secrets and API keys
These guides are about credentials: Supabase secret keys, Stripe secret keys, model keys, and anything else that should never ship to a browser. The same mistake shows up as a NEXT_PUBLIC_ or VITE_ variable, a committed .env, or a route that prints config. A publishable key is a different object from a secret key, and the guides say which one you are holding.
Guides
Secret keys shipped in the frontend
A Supabase secret key, Stripe secret key, or model API key in the browser bundle is public. Anyone can copy it and use it as your server.
Keys committed to GitHub
A key in a commit is copied to every clone and to GitHub's history. Deleting the file in a new commit does not remove it.
Exposed .env files and debug endpoints
A public .env, a /api/debug route, or a client bundle that prints config hands your secrets to anyone who asks.
Bolt apps, secrets, and Supabase access
Vite documents that VITE_ values are bundled into the client, and Vercel's Bolt export guide says the Secrets panel values are not in the zip you deploy.
Replit secrets and who can read them
Replit's secrets doc says hard-coded credentials leak through a public project, git, or a screen share, and that some collaborators can print secret values even when the UI hides them.
v0 apps, public env vars, and Supabase auth
v0 deploys to Vercel and can connect a backend. Vercel and Supabase document which keys are public and which keys bypass row level security.
Questions
Is the Supabase anon key or publishable key a leak?
No, if row level security is on and you have read the policies. Supabase documents the publishable key as the client key. The secret key and the legacy service_role key bypass row level security. Those are the ones that must stay on the server.
I deleted the key from the latest commit. Is that enough?
No. The old commit is still in history, and anyone who cloned the repo still has it. Remove it from history if you can, and rotate the key at the provider. A new variable name with the old value does not help.
Why do Bolt and v0 guides live with secrets?
Both ship a frontend that can be given a Vite or Next.js public env prefix. Vite documents that VITE_ values are bundled into client code. The guides are about that boundary, and about not treating a host's Secrets panel as a substitute for row level security.
What should I search for first?
Search the repo and the production JavaScript for service_role, sb_secret_, sk_live_, and BEGIN PRIVATE KEY, then search those strings next to NEXT_PUBLIC_ or VITE_. Also request /.env and any debug route on the deployed host.