← Blog · Published Oct 19, 2026 · by the Vibefixr team

Google login sends users to localhost after you publish? Here’s the fix

You click “Sign in with Google” on your freshly published app, pick your account, and land on http://localhost:3000/#access_token=…, a page that can’t be reached. In the preview it worked perfectly. This is one of the most common “works in preview, broken live” problems, and it’s almost always two settings, not code.

What it looks like

• After Google (or GitHub, Apple…) login, the browser goes to localhost:3000 instead of your site
• Magic links or password-reset emails open localhost
• Login on a Vercel or Netlify preview URL sends you to production, or to localhost
• It started right after you switched to a custom domain

Why it happens

Supabase Auth only sends users to addresses you’ve approved. Two settings control that, both in your Supabase dashboard under Authentication → URL Configuration:

• Site URL is the default destination. Supabase’s redirect URL docs say it’s used when no redirectTo is given in the code, and tell you to change it from http://localhost:3000 to your production URL. The dashboard adds that it’s also used when the URL your code asks for doesn’t match the allow list.
• Redirect URLs is that allow list. Your app can ask to come back to a specific page (the redirectTo option), but only if that exact URL, or a wildcard pattern covering it, is on the list.

So if the Site URL is still localhost and your live domain isn’t on the list, every login ends up on localhost. Supabase’s own troubleshooting note gives the same answer: the exact URL has to be in the Redirect URLs setting.

The fix in two settings

1. Set Site URL to your live domain

For example https://yourapp.com. Use your real production address, with https://. Wildcards aren’t allowed in the Site URL.

2. Add your Redirect URLs

Add the exact production URL your app returns to, for example https://yourapp.com/auth/callback if you have a callback page, or https://yourapp.com/** if you’re not sure yet. Keep http://localhost:3000/** for local development. For preview deployments, Supabase documents patterns like these:

https://**--my_org.netlify.app/**
https://*-<team-or-account-slug>.vercel.app/**

Matching is strict. http vs https, www vs no www, and a trailing slash all count as different URLs.

3. Google Cloud Console: point Google at Supabase, not at your app

If you use your own Google OAuth credentials, the Authorized redirect URI in Google Cloud Console must be your Supabase project’s callback URL, which you can copy from the Google provider page in the Supabase dashboard. It isn’t your app’s address. Google sends the user to Supabase, and Supabase sends them on to your app. Per Supabase’s Google guide, the local equivalent is http://127.0.0.1:54321/auth/v1/callback.

On Lovable Cloud? According to Lovable’s auth docs, the same two settings sit under More → Cloud → Users → Auth settings → Advanced, and Lovable updates them for you: it sets the Site URL to your published lovable.app address and adds a connected custom domain to the redirect URLs. A Site URL you set yourself isn’t touched, and apps on your own Supabase project get no automatic updates. If you use your own Google credentials, a new domain also needs a redirect URI in Google Cloud Console.

Not sure which of these is your problem? The free health check looks at your live app in seconds, or request a free scan and we’ll tell you what we find.

Keep previews working without opening everything

It’s tempting to add one giant wildcard and move on. Supabase’s recommendation is that ** is fine for local development and preview URLs, but your production entry should be the exact URL. The allow list is a security control: it stops an attacker from crafting a login link that sends a freshly signed-in user, and their token, to a site the attacker controls. Keep the patterns as narrow as your hosting allows.

Still landing on localhost?

• The code sends a hard-coded redirectTo. Search the project for localhost:3000 or redirectTo. An AI tool may have written the preview address straight into the login call.
• Email templates. Supabase’s email templates build links from {{ .SiteURL }} or {{ .RedirectTo }}. If you customized a template, check which one it uses.
• Old emails. A reset link sent before you fixed the Site URL keeps its old address. Request a new one.
• You changed domains. Update the Site URL and Redirect URLs (and Google’s settings, if you use your own credentials) to the new domain.
• The callback page 404s on refresh. That’s a hosting rewrite problem, not auth. See 404 on refresh.
• Login succeeds, then the app hangs. Different bug: see app freezes after login.

When it’s more than a setting

One provider and one domain is a five-minute fix. It gets messy with several providers, a custom domain plus lovable.app, preview branches, email links, and a server-side callback, where every flow has to land in the right place. That’s when a review saves you from finding out from users.

FAQ

Related guides

• Your Lovable app freezes or goes blank right after login: here’s why
• Lovable app shows a blank white screen after deploy? Here’s why
• Bolt.new app shows 404 when you refresh a page? Here’s why
• The launch checklist for apps built with Lovable, Bolt, Cursor, Replit and v0
• Your app calls localhost or hits a CORS error after deploy: here’s why

Launching soon? Run through our launch checklist for AI-built apps: 14 checks, each linked to the full guide.

Sources: Supabase: Redirect URLs · Supabase: Login with Google · Supabase: Email templates · Lovable: Users and authentication

Information here is checked against official docs at the time of writing. Platforms change, so verify against the linked sources.