Skip to content
discreet/devs

Guides · 17 October 2026

Login works in the preview but fails on your domain

Supabase only sends people back to addresses it has been told to trust. Move to your own domain without telling it, and confirmation links, password resets and Google sign-in all land somewhere else.

What you're seeing

  • New users click the confirmation email and land on the old preview site, a localhost address, or an error page.
  • Password-reset links open the wrong site.
  • Google or GitHub sign-in finishes, then drops the user back on the login page.
  • Everything still works fine in the preview.

Why it happens

After any email link or social sign-in, Supabase sends the user back to an address. It only uses addresses on its allow-list. If the address your app asks for isn't on the list, Supabase quietly falls back to the Site URL, which is usually still the preview address the builder set up.

So nothing is broken in your code's logic. Supabase just doesn't know your real domain yet, and often the app never tells it where to come back to.

The fix: settings (5 minutes)

  1. In the Supabase dashboard, open Authentication → URL Configuration.
  2. Set Site URL to your live address, exactly as people use it, for example https://www.yourdomain.com.
  3. Under Redirect URLs, add https://www.yourdomain.com/**. Wildcards are allowed, so ** covers every page.
  4. If you still want the preview to work, add it too, for example https://*.lovable.app/**, and your local address if you develop locally.
  5. Pick one of www or no-www and redirect the other to it at your host. Supabase treats them as different sites.

The fix: code (if links still go astray)

The app should tell Supabase where to return on each call, using the address the user is actually on. Search your code for signUp, signInWithOAuth and resetPasswordForEmail, and make sure each passes a redirect:

const origin = window.location.origin;

await supabase.auth.signUp({
  email,
  password,
  options: { emailRedirectTo: `${origin}/` },
});

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

await supabase.auth.resetPasswordForEmail(email, {
  redirectTo: `${origin}/reset-password`,
});

If you use Google sign-in, leave the redirect URI in Google Cloud alone: it should stay as your Supabase project's /auth/v1/callback address. The part that changes is Supabase's allow-list above.

Check it worked

  1. Open your live site in a private window.
  2. Sign up with an email address you haven't used before.
  3. Click the confirmation link. You should land on your domain, signed in.
  4. Repeat for password reset and any social sign-in.

Emails sent before the fix still contain the old address. Anyone who signed up and never got in needs to request a new link.

Still broken?

Then the cause is usually in the app itself: a login page that redirects before the session is read, two Supabase clients fighting over the session, or routes your host doesn't serve on refresh. That's what the diagnosis is for.

More on fixing apps built with Lovable, Bolt, v0 and Cursor.

Send me what's broken.

Two lines and a repo link. I reply within 24 hours (Mon–Sat) with the $249 diagnosis invoice, or tell you straight away if it isn't something I can do well.