Lovable Supabase Login Fails After Publish: Redirect Fix
Login works in the Lovable preview but sends users to localhost or back to the login page after publishing? Fix the Supabase Site URL, redirect URLs and OAuth callback.
If login works in the Lovable preview but fails on your published site, the live domain is almost always missing from your Supabase URL settings. Open Supabase, go to Authentication, URL Configuration, set the Site URL to your live domain, and add that domain with a /** wildcard under Redirect URLs. Then check your Google or GitHub OAuth callback.
AI app builders like Lovable, Bolt and Replit make auth look easy because the preview just works. The preview runs on a temporary address that is already allowed. Your real domain is a new address, and Supabase refuses to redirect users to addresses it does not know. Here is the fix, step by step.
Step 1: Know Which Backend You Use
Lovable can run on its own managed backend or on a Supabase project you connected. One guide says redirect URLs update automatically on the managed backend, but not on your own Supabase project. If you connected your own project, the steps below are yours to do. Check your live site's exact address first, including https and www.
Step 2: Set the Site URL
In the Supabase dashboard, open Authentication, then URL Configuration. Set Site URL to your live domain:
https://yourapp.com
The Site URL is the default place Supabase sends users after login or after clicking an email link. If it still says http://localhost:3000, your users land on localhost, which only exists on your computer. See the Supabase redirect URL docs for the full rules. We could not open that page from our writing environment, so check it for the current wording.
Step 3: Add Redirect URLs With a Wildcard
Under Redirect URLs, add every address where your app can receive the login callback:
https://yourapp.com/**
https://www.yourapp.com/**
https://yourapp.lovable.app/**
http://localhost:5173/**
Add each variant you use: with and without www, your custom domain and the builder's default domain. Keep localhost for development. If an address is not on this list, Supabase falls back to the Site URL, which explains why users sometimes end up on the wrong page.
Step 4: Check the OAuth Provider Settings
For Google or GitHub login, there are two places with URLs. In the provider's console (Google Cloud or GitHub), the authorized callback must be your Supabase project callback:
https://<your-project-ref>.supabase.co/auth/v1/callback
Do not put your app domain there. Supabase handles the callback, then redirects to your app using the lists above. Also confirm the Client ID and Secret are saved in Supabase under Authentication, Providers.
Step 5: Look for Hard-Coded Preview URLs
Open your code and search for where the redirect is built. Generated code sometimes hard-codes the preview address:
await supabase.auth.signInWithOAuth({
provider: "google",
options: { redirectTo: "https://preview-abc123.lovable.app/dashboard" },
});
Replace it with the current origin so it works everywhere:
options: { redirectTo: `${window.location.origin}/dashboard` }
The same applies to emailRedirectTo in signUp and to password reset links. If you cannot find them, ask the builder to list every place the code creates a redirect or callback URL.
Step 6: Fix "Back on the Login Page" Loops
If users sign in and instantly return to login, the session is not being read. Check three things:
- The Supabase URL and anon key in the published build match your project (environment variables are sometimes set only in preview).
- Your route guard waits for the session before redirecting. Use
supabase.auth.getSession()oronAuthStateChangeand show a loading state first. - Your site is not mixing
wwwand non-www, because storage is per origin. Pick one and redirect the other.
supabase.auth.onAuthStateChange((event, session) => {
if (session) navigate("/dashboard");
});
Make sure you have published after changing code. The live site is a snapshot from your last publish, so unpublished edits do not appear. If you use a custom email provider, also check the email template links, since confirmation emails use the Site URL.
Step 7: Test the Whole Flow as a New User
Open a private window on your live domain and test: sign up, confirm the email, log out, log in with email, log in with Google, reset the password. Do it on your phone too. Many auth bugs only show on one path. Our post on Supabase RLS errors in production covers what to check when login works but data comes back empty.
Step 8: Check Email Confirmation and Password Reset
Email links are a second source of broken login. The confirmation and reset emails contain a link built from your Site URL. If you changed the Site URL, send a fresh test email, because old emails still point to the old address. Open Authentication, Email Templates, and check that the links use {{ .SiteURL }} or {{ .ConfirmationURL }} and not a pasted preview address. If emails never arrive, the built-in Supabase mailer has strict rate limits, so connect your own SMTP provider before launch. Check spam folders too, since confirmation mails from a shared sender often land there.
Keep a short checklist for every new domain you add: Site URL, Redirect URLs, OAuth provider callback, email templates, and the environment variables in your builder. Running through five items takes two minutes and prevents a day of lost signups.
How Relia Helps
Login failures are quiet. Users leave, and you never see an error. Relia watches the users, APIs and database of a live product and joins related signals into one incident in plain words, with who was affected. Supabase, Firebase and edge functions are supported. You can set uptime checks on key pages such as your login page. There is a Free plan, and a live demo at app.tryrelia.com/demo.
FAQ
Why does Supabase redirect to localhost after login?
The Site URL is still set to localhost, or your live domain is not in the Redirect URLs list, so Supabase falls back to the default.
What should the Google OAuth redirect URI be in a Supabase app?
Use https://<project-ref>.supabase.co/auth/v1/callback in the Google console. Your app domain goes in the Supabase URL settings.
Why does login work in preview but not on my custom domain?
The preview address was allowed, but your custom domain was not added to Supabase redirect URLs or the OAuth settings.
Do I need to republish after changing Supabase settings?
No. Supabase settings apply right away. Republish only when you change code or environment variables in the builder.