Supabase Login Redirects to localhost After Deploy: How to Fix It

You deployed your Lovable, Bolt or Cursor app, you click "Sign in", and after logging in you land on http://localhost:3000 instead of your live site. Or sign-in loops back to the login page. Often the cause is a Supabase setting, not your code.

Why Supabase sends you to localhost

Supabase only redirects users to addresses on an allowlist in your project settings. The Site URL is the default address it uses when your code doesn't pass a redirectTo. Supabase's docs say to change it from http://localhost:3000 to your production URL. If your code does pass a redirectTo that isn't on the Redirect URLs list, Supabase ignores it and falls back to the Site URL. That's how you end up on localhost even after "setting production".

Step 1: Set the Site URL to your live address

  1. Open your Supabase dashboard and pick the project your app actually uses. If your preview and live app use different projects, sort that out first.
  2. Go to Authentication → URL Configuration.
  3. Set Site URL to your live origin, for example https://your-app.lovable.app or your custom domain, including https://. Save.

The Site URL is also used for email confirmations and password resets, so this step fixes those links too.

Step 2: Add every address you sign in from to Redirect URLs

On the same page, add your live address and the exact callback path your app uses, plus any preview or local addresses you still test on:

https://your-app.com/**
https://your-app.com/auth/callback
http://localhost:5173/**

Supabase supports wildcards, and ** matches across /. Whatever your code passes as redirectTo has to match an entry on this list, either exactly or through a wildcard. A trailing slash that doesn't match is enough to fall back to the Site URL.

Step 3: Check Google or GitHub sign-in

If you use Google or GitHub login, the provider's authorized redirect URI is Supabase's callback, not your app:

https://YOUR_PROJECT.supabase.co/auth/v1/callback

Copy it from Authentication → Providers in Supabase and make sure it's listed in Google Cloud Console or your GitHub OAuth app. If it's wrong, you'll see redirect_uri_mismatch at the provider.

Step 4: Remove hardcoded localhost from your code

Search your repo for redirectTo, emailRedirectTo and localhost. Replace fixed addresses with the current origin:

const redirectTo = `${window.location.origin}/auth/callback`;

await supabase.auth.signInWithOAuth({
  provider: "google",
  options: { redirectTo },
});

Then republish or redeploy so the live app picks up the change. Supabase settings apply right away, but code that still points at localhost overrides them.

Step 5: Test with a fresh link

Open a private browser window and sign in again. If you use magic links or email confirmation, request a new email. Links in old emails still point at the old address.

Still stuck?

If the URLs are right and it still loops, the cause may be in the app code. For example, a route guard redirects to the login page before the session has finished loading.

A Single Bug Fix ($29) covers one bug like this, delivered as a GitHub pull request with a plain-English write-up. Milo, our AI agent, reviews every fix before delivery, and you review and merge the pull request yourself. Nothing is merged without you. No fix, full refund. Questions first? See the FAQ.

Sources