Your lovable api key is sitting in the frontend bundle

Your lovable api key worked in preview because it was pasted into a React file — and became public the moment you published the bundle.

The Agent dropped OPENAI_API_KEY next to a fetch call. Stripe secret keys sat in a .env example that shipped in comments. Supabase service role strings appeared in a helper the UI imported directly. Preview felt fine. DevTools on the live site expose every one of those strings to anyone who opens Sources.

Key sitting in the frontend

Secrets in client code are not “hidden.” They are delayed public disclosure.

API key visible in browser devtools

Open your live URL. Sources or Network tab shows the key in a JS chunk or request header. Copy it into curl. The provider accepts the call. You just gave every visitor the same power as your backend.

Repo leak after GitHub connect

You connected Lovable to GitHub. The commit history still contains the hardcoded key from an earlier prompt. Even after you delete the line, bots scrape old commits. Rotation is mandatory.

Works in Lovable preview, undefined in production

The editor injects integration keys for its sandbox. Vercel production never received the name-value pair. The app builds but server routes return 401 or 500 because process.env.OPENAI_API_KEY is empty on the host.

Anon key treated like a password

Supabase anon keys belong in the browser by design, but they are not authorization. Pairing a visible anon key with tables that lack RLS is equivalent to leaving the door open with the key taped to the glass. See security policy work separately; this article focuses on secrets that must never ship client-side.

Key handling ties directly to deployment env configuration. Read vercel env vars for the host copy step and lovable deploy for the full publish checklist.

Why the AI left your lovable api key in client code

AI coding tools optimize for the fastest path to a working demo. Pasting a key into the file that calls the API works immediately in preview. Creating a server route, env var, and redeploy loop takes more steps the model often skips.

Lovable preview can store secrets outside your repo. That feels like safety until you publish through GitHub to Vercel. The preview secret drawer does not automatically become production env vars. Code still references names only the editor knew.

Tutorials blur lines between VITE_ public vars and server secrets. Models copy patterns from blog posts that cut corners. A Stripe publishable key in the client is correct. A Stripe secret key in the client is a liability the AI may not label clearly.

Users ask “wire OpenAI” not “wire OpenAI securely.” The agent complies with the shortest implementation. You discover the exposure during a security review or a surprise bill, not during the first preview click.

Move lovable api keys off the client

Assume every character in frontend bundles is public. Treat recovery as rotation plus architecture, not a comment change alone.

1. Find exposed keys in the project. In Lovable, search for sk-, apiKey, secret, service_role, and provider prefixes. Check env example files and commented blocks too.
2. Classify each key. Public-by-design keys (Stripe publishable, Supabase anon, maps embed keys with domain restrictions) may stay client-side with safeguards. Everything else moves server-side.
3. Delete secrets from frontend files. Remove hardcoded strings and stop importing server-only modules into React components. Replace client calls with fetches to your own API routes.
4. Create server routes or edge functions. Add a Next.js route, Supabase Edge Function, or similar handler that reads the secret from env and calls the provider. Return only the data the UI needs, not the key.
5. Add env vars on the deployment host. Open Vercel → Settings → Environment Variables (or your host equivalent). Paste each secret with Production enabled. Match the exact variable names your server code expects.
6. Rotate leaked keys at the provider. OpenAI, Stripe, Supabase, and others let you revoke and reissue. Do this if the repo was public, shared, or ever contained the key in git history.
7. Redeploy and verify. Trigger a fresh production build. Confirm client bundles no longer contain the secret string. Test the feature through the new server route.
8. Add git hygiene. Ensure .env files stay in .gitignore. Scan history with provider tools if needed. Never commit recovery codes or service role keys again.

After rotation, update Lovable preview secrets too so local and production do not drift to different keys unintentionally.

Checklist before you call lovable api key handling fixed

• No provider secret strings in client JS or public repos
• Server routes own all privileged API calls
• Production host env vars match names referenced in server code
• Leaked keys rotated at the provider
• Fresh deploy: devtools search finds no sk- secrets in bundles
• Public keys only where the provider documents browser use

FAQ

Is it safe to put a lovable api key in frontend code?

No for secrets. Any key bundled into client JavaScript is visible in devtools. Use server routes or edge functions for OpenAI, Stripe secret keys, and Supabase service role keys. Only intentionally public keys like Stripe publishable keys belong in the browser.

How do I move a lovable api key out of the Lovable project?

Delete the key from React or Vite files, add it to your deployment host environment variables, read it only in server-side code, and redeploy. Rotate the key at the provider if the repo was public or shared.

Why did my lovable api key work in preview but fail live?

Preview may inject keys inside Lovable while production builds on Vercel or similar hosts without those values. The variable name exists in code but resolves to undefined on the live URL until you copy it to production env vars.