Lovable login redirects to localhost? How to fix it

When a Lovable app sends people to localhost or the old preview address after they sign in, the cause is almost always the auth settings, not your pages. Supabase-style auth sends users to the Site URL whenever the address your app asked for is not on its list of allowed Redirect URLs, and a fresh Supabase project starts with http://localhost:3000 as its Site URL. Set the Site URL to your real domain, add every address you use to the Redirect URLs, and update your Google settings if you use your own credentials.

This guide shows how to tell which link is misbehaving, where the two settings live depending on how your Lovable backend is set up, the code that can override them, and how to check the fix before your users notice.

Why does the redirect go to localhost or the preview URL?

Every sign-in flow that leaves your app and comes back (email confirmation, magic link, password reset, Google or Apple sign-in) needs to know where to return. Your app suggests an address with a redirectTo value. The auth server only honours that suggestion if it matches an entry in the allow list. If it doesn't, it falls back to the Site URL.

So there are three common ways this goes wrong:

1. The Site URL was never changed. It still says http://localhost:3000 or your lovable.app address.
2. Your new domain is missing from the Redirect URLs. The app asks for https://yourdomain.com/dashboard, the server refuses it and uses the Site URL instead.
3. The code hard-codes an address. Somewhere a prompt produced redirectTo: "https://my-app.lovable.app", so every flow points there no matter what the settings say.

Which setup does your Lovable app use?

Lovable apps store users in one of two places, and that decides who keeps these settings up to date.

Lovable's authentication docs describe this behaviour. On Lovable Cloud the problem usually means someone once set the Site URL by hand, or the domain isn't Live yet. On your own Supabase project, nothing updates unless you do it.

How do I find which link is wrong?

Before you change anything, find the exact address the user is being sent to.

1. Trigger the flow yourself in a private browser window: sign up with a test email, request a password reset, or click "Sign in with Google".
2. For email flows, don't click the link. Copy it and paste it into a text editor. Look for the redirect_to= part. That is where the user will land.
3. For Google or Apple, watch the address bar after you approve. If you see localhost:3000 or the preview address, note it.
4. If Google itself shows an error page with redirect_uri_mismatch, the problem is on the Google side, not in your auth settings. Skip to the Google section below.

If redirect_to shows your real domain but you still end up on localhost, the domain isn't on the allow list. If redirect_to already shows localhost, either the Site URL or the code is the source.

How do I fix the Site URL and Redirect URLs?

On Lovable Cloud

Open More → Cloud → Users → Auth settings → Advanced. Set the Site URL to your primary domain, for example https://yourdomain.com, and make sure the Redirect URLs list includes:

• https://yourdomain.com/**
• https://www.yourdomain.com/** if you also serve the www version
• your lovable.app address, if you still want sign-in to work there

You can also ask Lovable in the project chat to add your domain to the auth redirect URLs. Either way, check the result in the settings screen.

On your own Supabase project

In the Supabase dashboard, open Authentication, then URL Configuration. Change the Site URL from http://localhost:3000 to your production domain and add the same Redirect URLs as above.

A note on wildcards from the Supabase redirect URL docs: * matches characters up to the next . or /, while ** matches anything, including deeper paths. https://yourdomain.com/* allows /login but not /auth/callback. Use /** for your domain, and prefer exact entries where you can.

Could the code be overriding the settings?

Yes, and it's worth checking even after the settings look right. Open the code (in Lovable's Code view or your GitHub copy) and search for localhost, lovable.app and redirectTo. The calls to look at are:

supabase.auth.signUp({ email, password, options: { emailRedirectTo: `${window.location.origin}/welcome` } })
supabase.auth.resetPasswordForEmail(email, { redirectTo: `${window.location.origin}/reset-password` })
supabase.auth.signInWithOAuth({ provider: "google", options: { redirectTo: window.location.origin } })

Using window.location.origin means the app always asks to return to whichever address the user is on. A hard-coded preview URL in any of these will keep sending people back to the preview.

If you edited your email templates, also check that the link uses {{ .RedirectTo }} rather than {{ .SiteURL }}, or the email will ignore the address your app asked for.

What about Google sign-in?

If Google sign-in is "Managed by Lovable", Lovable handles the Google side. If you use your own Google OAuth credentials, Google needs to trust the new address too:

• On Lovable Cloud, Lovable lists the redirect URL for your custom domain under More → Cloud → Users → Auth settings → Google but does not select it. Add it as an Authorized redirect URI in Google Cloud Console, then select it in Lovable and save.
• On your own Supabase project, the authorized redirect URI in Google is your Supabase callback, https://<project-ref>.supabase.co/auth/v1/callback. The return to your domain is controlled by the Supabase Redirect URLs, not by Google.

Google compares these strings exactly. A missing trailing slash or http instead of https is enough to fail.

How do I confirm it's fixed?

Test in a private window, from a fresh start:

1. Sign up with a new test address and click the confirmation link. You should land on your domain.
2. Request a password reset and follow it through to setting a new password.
3. Sign in with Google (or any other provider you offer) and sign out again.
4. Repeat once on a phone, where saved sessions often hide problems.

Emails sent before the fix still contain the old link. Ask affected users to request a new one rather than reuse an old email.

How do I stop this from happening again?

• Pick one primary domain. Lovable redirects your other connected domains to the primary one, so set the Site URL to that same address.
• Keep a domain checklist. Every time you add or change a domain: auth Site URL, Redirect URLs, Google or Apple redirect URIs, and any payment or email links that include the address.
• Ban hard-coded URLs in your project knowledge or prompts: "Always build redirect URLs from window.location.origin."

The wider launch steps are in our guide on connecting a custom domain to Lovable, and the related email problem is covered in sending transactional emails from a Lovable app.

Quick answers

Why does sign-in work in the preview but not on my domain? The preview address is already allowed, your domain isn't. Add it to the Redirect URLs and check the Site URL.

Do I have to change anything in my code? Only if it hard-codes an address. Search for localhost and lovable.app and replace them with window.location.origin.

Why does Google show redirect_uri_mismatch? You use your own Google credentials and the exact redirect URI isn't authorized in Google Cloud Console.

Still bouncing to the wrong place?

If the settings look right and users still land in the wrong spot, the flow probably has a second problem in the code, such as a callback page that never reads the session. Run the free health check to see what is visible from outside, look at how we fix Lovable apps, or tell us what's happening and a person will reply within one business day.