Lovable login redirects to localhost: how to fix auth URLs

If signing up or resetting a password in a Lovable app sends people to localhost:3000 or the preview URL, the auth settings still point at development. In Supabase, set Authentication > URL Configuration > Site URL to your live domain, add the live domain and lovable.app address to Redirect URLs, and make the code pass window.location.origin as the redirect. Then send a fresh email, because links in old emails keep the old address.

What you'll see

A new user clicks the confirmation link and the browser opens http://localhost:3000 with "This site can't be reached". Password reset links behave the same way, or land on the Lovable editor preview instead of the real site. Google sign-in on the custom domain may fail with a redirect_uri_mismatch error while it works on lovable.app.

Why it happens

1. Site URL is still the default

Supabase uses the Site URL as the fallback redirect whenever the code does not pass one, and it is the address written into confirmation and reset emails. New Supabase projects start with http://localhost:3000 there.

2. The live domain is not on the allow list

Supabase only redirects to addresses listed under Redirect URLs. If the code asks for https://yourdomain.com and that address is missing, Supabase silently falls back to the Site URL.

3. A hardcoded preview or localhost address in the code

Generated code sometimes sets emailRedirectTo or redirectTo to the address it was built on. That works while building and breaks the moment the site moves to a custom domain.

4. Google OAuth client missing the new domain

If you use your own Google OAuth client, the custom domain has to be listed under Authorized JavaScript origins in Google Cloud Console, or Google refuses the sign-in.

How to fix it

In the Supabase dashboard open Authentication > URL Configuration and set Site URL to https://yourdomain.com. If the project runs on Lovable Cloud instead of your own Supabase account, find the equivalent auth URL setting in Lovable's Cloud settings; the names may differ.
Under Redirect URLs add https://yourdomain.com/** and https://yourproject.lovable.app/**. Supabase recommends exact paths in production, so tighten these to your callback path once things work.
Search the code for localhost, lovable.app and lovableproject in any emailRedirectTo or redirectTo option, and replace them with window.location.origin plus your callback path.
If sign-in with Google uses your own OAuth client, open Google Cloud Console > Credentials, edit the client and add your custom domain to Authorized JavaScript origins. Keep the Supabase callback URL in Authorized redirect URIs.
Publish, then request a brand-new confirmation and a new reset email. Older emails were generated with the previous Site URL and will never work.

Prompt to paste into Lovable

Fix auth redirects for production. Use window.location.origin for every emailRedirectTo and redirectTo (sign up, magic link, password reset, OAuth) instead of any hardcoded localhost or preview URL, and add an /auth/callback route that finishes the session and sends the user to the dashboard. Then tell me exactly which URLs I must add as Site URL and Redirect URLs in the auth settings.

How to check it's fixed

Sign up with a new email on the live domain. The confirmation link should open your domain and leave you logged in.
Run Forgot password and hover the link in the email before clicking: the host should be your domain.
Try Google sign-in from the custom domain on desktop and on a phone, in a private window.

What a QAlaunch scan shows for this

Links or buttons on public pages that point at localhost or a preview address, which fail the scan's link check.
Console errors and failed requests on public pages such as the sign-in screen.
The scan does not log in or open emails, so it cannot follow a confirmation link; test that flow yourself with the steps above.

See exactly what a full report contains in the sample report.

Frequently asked questions

I fixed the Site URL but the email link still goes to localhost. Why?

The link was baked into the email when it was sent. Request a new one. If a new email still has localhost, the code is passing a hardcoded redirect, or the address it passes is not in Redirect URLs and Supabase fell back.

Should I keep the lovable.app address in Redirect URLs?

Keep it while you still test on it. Once the custom domain is primary and everyone uses it, you can remove the extra entries and leave only the exact production callback.

Does this affect Google sign-in too?

Yes, in two places. Supabase needs your domain in Redirect URLs to send users back after Google, and Google needs your domain as an authorised origin if you use your own client ID. Either one missing breaks the flow on the custom domain.

Done for you · not automated

Rather have a QA engineer test it by hand?

If this is a site you're launching or handing to a client, I'll go through it by hand, including the Lovable-specific issues a scan can't reach, like logged-in flows.

$299one-time · 3 business days

Up to 10 key pages tested by hand, not a scan
Every flow a customer uses: forms, sign-up, checkout, booking
Real mobile and desktop browsers
A written report in plain language, with screenshots
A 15-minute call to walk you through it
10 years of professional QA experience

Tell me about your site and I'll reply personally, usually the same day.

No payment now. I'll confirm scope and price first.

Written by Waqas Ahmad, QA engineer with 10 years of professional testing experience. Last checked October 26, 2026.

Sources: Supabase docs: redirect URLs · RapidDev: redirect issues after auth flow in Lovable