Lovable OAuth redirecting to localhost after deployment? Fix in 5 minutes

Common mistakes when fixing this

Updating only one or two surfaces. The most common pattern. The founder updates Supabase Site URL and ships, then OAuth still fails because Google Cloud was not updated. Or updates Google Cloud and the app code but forgets the Supabase Redirect URLs allow-list. All four updates are required: Site URL, Redirect URLs, Google Cloud authorized URIs, and the client-side redirectTo. Three out of four is identical to zero out of four — the failure looks the same.

Wrong canonical (apex versus www). If your DNS resolves both yourapp.com and www.yourapp.com but you only added one to the Site URL, the redirect fails for users who land on the other variant. Pick a canonical, redirect the other one to it at the host level, and add only the canonical to Supabase. Every OAuth provider on the planet treats yourapp.com and www.yourapp.com as different origins, and the redirect URL allow-list is exact-match.

Trailing slashes. Some implementations match exact strings, some match by host, and Supabase’s allow-list happens to be exact-match. https://yourapp.com and https://yourapp.com/ are not the same value. Strip trailing slashes from the Site URL, and use ** in Redirect URLs to capture every path under the canonical.

Cached frontend bundle. If you updated the client-side redirectTo but the deployed bundle still ships the hardcoded localhost string, the fix is invisible. Force a fresh deploy, purge the CDN, and hard-refresh. The Network tab will show whether the bundle has the new value.

Forgetting the staging environment. Most teams run a staging URL in addition to production. Both must be in the Supabase allow-list, both must be in Google Cloud, and both must use the same client-side pattern that derives the redirect from window.location.origin rather than a hardcoded value. Anything hardcoded will fail in one environment or the other.

Why Lovable apps hit this so often

Lovable’s preview environment auto-provisions a Supabase project and pre-configures the Site URL to the Lovable preview domain. The generated React code uses a hardcoded redirectTothat matches the preview. None of that is wrong while you are working in the preview — everything works. The break happens at the moment of cutover, because Lovable does not know which production domain you will eventually deploy to. The fix surfaces here are not a Lovable bug; they are an OAuth security property that the founder has to update by hand the day the application leaves the preview.

The same shape applies to Bolt and v0 deployments — the preview is a different origin than production, and OAuth treats the two as different applications. The reason this problem is filed under Lovable specifically is that Lovable’s default Supabase wiring makes it the most common path: roughly fifteen percent of broken Lovable deploys we triage are this exact failure, which is large enough to deserve its own playbook.

When to hire help instead of fixing yourself

The five-minute fix above is genuinely five minutes if you have admin access to all three consoles (Supabase, Google Cloud, your repo) and you are comfortable navigating settings UI. Hire help if any of those is not true: someone else owns the Google Cloud project, your Supabase project is in another team member’s organization, or the app code is generated and you are not sure where to make the redirectTo change. In that case, our $299 Emergency Triage is the fastest path: send us read access and the production URL, we update all three surfaces and verify with a real incognito sign-in within 48 hours.

You should also hire help if you have made the changes and the loop continues. At that point the cause is almost always somewhere outside the four surfaces above — a stale CDN cache holding the old bundle, a cookie domain mismatch, a Supabase project ID drift between environments, or a custom auth handler that overrides the Supabase default. Each of those is fixable but each takes a small amount of architectural context to diagnose, and that diagnosis is faster from outside than from inside.

After the fix — what to test

Sign in via every supported OAuth provider in an incognito window on the production URL. Sign out and sign back in. Refresh the page after sign-in to confirm the session persists across the reload. Open a second incognito window with a different account and confirm the second account does not see the first account’s data — this is the moment to also verify Row-Level Security on any table the OAuth user can read. None of these tests takes more than 60 seconds and together they catch every common follow-on regression.

Your OAuth redirect URLs live in three places: your identity provider (Google Cloud), your auth gateway (Supabase), and your client code (supabase.auth.signInWithOAuth). Lovable sets all three of yours to localhostin preview. Your deployment doesn’t rewrite any of them automatically.

The failure you see is silent: your user clicks “Sign in with Google”, sees the consent screen, clicks allow, and lands on a dead URL. No error in your console beyond the 404. That makes it easy for you to misdiagnose as a general auth bug.

The reason you have three surfaces and not one is an OAuth security property, not a quirk. Your identity provider (Google) must pre-authorize every URL it’s willing to redirect to, otherwise an attacker who captures your auth code could redirect it to their own domain. Your auth gateway (Supabase) then enforces a second allowlist so only your app’s routes can complete the flow. Your client code makes the final redirect to a route you control, typically /auth/callback. When one of your three still says localhost, the browser sends your user to a dev URL that doesn’t exist on the public internet — hence the 404. Updating all three is your only fix; there is no single place you can flip.