supabase oauth sends users back to localhost after publish

Your supabase oauth handshake looked finished in preview, then dumped users on localhost the moment you published.

You clicked Sign in with Google. The consent screen appeared. You approved. The browser redirected — and opened a dead localhost tab instead of your live app. Customers report the same loop on production while your editor preview still works. The provider is not broken. The callback URL chain still points at a host that only existed on your laptop.

OAuth callback still localhost

Symptoms cluster around a few patterns. Match yours before you change random settings.

Browser opens localhost after Google or GitHub

The OAuth provider completes. The address bar shows http://localhost:3000 or http://localhost:5173 with hash fragments. The page fails to load for end users. You see tokens flash and disappear because nothing is listening on that port in production.

Redirect URI mismatch error

Supabase or the provider shows redirect_uri_mismatch. The URI in the error does not match what you registered in Google Cloud Console or GitHub OAuth App settings. Often the mismatch is between a preview URL and a live URL you never added.

Sign-in works in Lovable preview only

Inside the editor, OAuth returns to the Lovable preview origin. After publish, the same button sends users to localhost or an old preview hostname. The session never lands on yourapp.lovable.app or your custom domain.

Supabase logs show wrong redirect_uri

Open Authentication → Logs in Supabase. Failed OAuth rows list redirect_uri=http://localhost:.... That value came from Site URL, Redirect URLs, or hardcoded redirectTo in your client code.

These failures often share one root cause. Fix URL Configuration once and Google, GitHub, and magic-link flows improve together. For the broader publish checklist, see lovable deploy.

Why the AI wired supabase oauth to preview hosts

Lovable generates auth code against the environment it can see. During build, that is the preview origin. The Supabase client inherits default redirect targets unless you override them.

Supabase ships with http://localhost:3000 as a common Site URL default. AI assistants copy that into signInWithOAuth options and env examples because login must work immediately in the sandbox. They optimize for “make OAuth succeed here,” not “make OAuth succeed on a domain you have not published yet.”

Connecting Supabase inside Lovable wires API keys and tables. It does not rewrite Authentication URL Configuration when you hit publish. Google and GitHub OAuth apps also need explicit authorized redirect URIs. The AI registers the Supabase callback for the project ref, but your app’s return path still depends on Redirect URLs you maintain.

OAuth is a chain: your app → Supabase → provider → Supabase callback → your app. Any link still pointing at localhost breaks the last hop for real users. Magic links and password resets use the same Site URL field, so a localhost Site URL poisons email links too.

If login symptoms overlap with email magic links, read lovable login for the full redirect checklist. OAuth-specific fixes start in the same URL Configuration screen.

Fix supabase oauth in Supabase and your provider

Work in this order. Skipping a step brings the localhost redirect back.

1. Publish and copy your live origin. In Lovable, publish if you have not already. Copy https://your-project.lovable.app or your custom domain with https://. No trailing slash unless your app truly lives in a subpath.
2. Open the correct Supabase project. Confirm which project Lovable linked. Open that same project in the Supabase dashboard. Preview and production must not point at different projects unless you intend that split.
3. Set Site URL. Go to Authentication → URL Configuration. Set Site URL to your live origin.
4. Add Redirect URLs. In the same screen, add your live URL, your Lovable preview URL, and http://localhost:5173 if you still test locally. Include explicit callback paths such as https://your-project.lovable.app/auth/callback when your router expects them.
5. Update Google OAuth if you use Google. In Google Cloud Console, open your OAuth client. Under Authorized redirect URIs, list https://<project-ref>.supabase.co/auth/v1/callback. In Supabase, under Authentication → Providers → Google, confirm client ID and secret match.
6. Update GitHub OAuth if you use GitHub. In GitHub → Settings → Developer settings → OAuth Apps, set Authorization callback URL to the same Supabase callback URL. Enable the GitHub provider in Supabase with the matching client ID and secret.
7. Remove hardcoded localhost in code. In Lovable, search for redirectTo, signInWithOAuth, and literal localhost strings. Prefer window.location.origin plus your callback path, or an environment variable that resolves to the current host in production.
8. Republish and test in a private window. Save, publish, then run Google and GitHub sign-in once each on the live URL. Confirm you land inside the app, not on login or localhost.

Old OAuth sessions cached in the browser can mask fixes. Test with a fresh private window after each URL change.

Checklist before you call supabase oauth fixed

• Site URL matches your live origin, not localhost
• Redirect URLs include live, preview, and any local dev origin you still use
• Google or GitHub OAuth app lists the Supabase callback URI exactly
• Client code does not hardcode http://localhost for redirectTo
• Supabase logs show successful OAuth on the live domain
• Private-window test completes sign-in on production

FAQ

Why does supabase oauth redirect to localhost after publish?

Supabase builds OAuth redirect URIs from Site URL and Redirect URLs in Authentication settings. Preview and local dev hosts are listed by default. Your live domain is missing until you add it manually, so the provider sends users back to localhost.

Where do I fix the supabase oauth callback URL?

Open Supabase → Authentication → URL Configuration. Set Site URL to your live origin and add every allowed redirect path under Redirect URLs, including preview and production. Match the same callback in your Google or GitHub OAuth app settings.

Does supabase oauth need different settings for preview and production?

Yes. List both origins in Redirect URLs so developers can test locally and users can sign in on the live site. Code should use window.location.origin or an env-based redirect instead of a hardcoded localhost string.