Fix guide · updated 2026-11-07

Supabase login redirects to localhost after deploy

http://localhost:3000/#access_token=… · This site can't be reached

Your app is live. A user taps Sign in with Google, or the link in their confirmation email, and lands on http://localhost:3000 with This site can't be reached. Or they land on your old Lovable preview instead of your real site. This is one of the most common problems right after a first deploy, and the fix takes a few minutes.

Why it happens

After a login, Supabase decides where to send the user. It only sends people to addresses on an approved list. If the address your app asks for isn't on that list, Supabase uses the Site URL instead, and on many projects that's still http://localhost:3000 from development. So the fix is to tell Supabase your real address, in two places, and make your code ask for it.

1. Set the Site URL to your real domain

Supabase dashboard → Authentication → URL Configuration → Site URL: put your live address, for example https://yourapp.com. Save.

2. Add your addresses to Redirect URLs

Same page, Redirect URLs → Add URL. Add every address users should come back to, with /** at the end so every page on it is allowed:

https://yourapp.com/**
https://www.yourapp.com/**
http://localhost:3000/**

Keep the localhost line only if you also run the app on your computer. Using preview deployments? Supabase accepts wildcards, for example https://*-yourteam.vercel.app/** for Vercel previews. For your Lovable preview, copy its address from the browser bar and add /**.

3. Make your code ask for the right address

Tell Supabase where to come back after each kind of login. Using the current page's address means the same code works in preview and in production, as long as both are on the list:

// Google (or any OAuth provider)
await supabase.auth.signInWithOAuth({
  provider: "google",
  options: { redirectTo: `${window.location.origin}/` },
});

// Email + password sign-up: where the confirmation link sends people
await supabase.auth.signUp({
  email,
  password,
  options: { emailRedirectTo: `${window.location.origin}/` },
});

Search your project for signInWithOAuth, signUp and signInWithOtp and check each one.

4. For Google sign-in: fix the callback in Google Cloud

Google Cloud Console → APIs & Services → Credentials → your OAuth client:

• Authorized redirect URIs must contain your Supabase callback, not your site: https://<your-project-ref>.supabase.co/auth/v1/callback (Supabase shows the exact address in Authentication → Providers → Google).
• Authorized JavaScript origins: your site, for example https://yourapp.com.

Seeing Error 403: access_denied for everyone except you? Your Google consent screen is still in Testing mode, which only lets listed test users in. Publish it to production in the OAuth consent screen settings.

Two more things that look like the same bug

• {"error":"requested path is invalid"}: the link sent people to your Supabase project address itself instead of your app. Same fix: the Site URL must be your app's address.
• Old emails still go to the wrong place. Links in emails sent before the fix keep their old address. Send a new confirmation or magic link to test.

If your project runs on Lovable Cloud rather than your own Supabase project, the same two settings exist there: look for the URL and redirect settings in its authentication section.

Still landing in the wrong place?

Supabase → Authentication → Logs shows each login attempt and where it tried to send the user. If sign-in now works but the app shows no data afterwards, that's a different problem, covered in our row-level security guide.