Lovable login is dead after publish

Your lovable login looked finished in the editor, then died the second you hit publish.

The preview felt solid. You clicked sign in, got a magic link or a Google prompt, and landed inside the app. After publish, the same flow falls apart. Users stare at a login button that does nothing, or they complete auth and end up right back where they started.

What you see after publish

Symptoms cluster around a few patterns. Knowing which one you have saves time.

The login button does nothing

You click sign in. The page may flash. No error appears. The network tab shows a request to Supabase, then silence. Sometimes the button handler still points at a preview-only environment variable. Sometimes the redirect URL is invalid and the client aborts before opening the provider.

Magic link lands you back on login

You enter your email. Supabase sends the link. You click it. The browser opens, loads your site, and drops you on the login screen again. The session never sticks. The URL in the address bar may show access_token fragments for a second, then clean up with no user logged in.

Google sign-in loops forever

You pick your Google account. Google approves. The browser redirects. You land on login again. Click Google again. Same loop. The OAuth handshake completes on the server, but the final redirect does not match a URL Supabase will accept for your live domain.

Password reset goes nowhere

Reset email arrives. The link inside points at http://localhost:3000 or an old preview hostname. Users click it and get a browser error, or they reach a page that is not your production app. They assume the product is broken.

Callback still says localhost

Open the email template or the OAuth error in Supabase logs. You see redirect_uri=http://localhost:5173/... or a Lovable preview URL. That is the smoking gun. Production traffic is trying to return to a host that only existed while you were building.

These failures often show up together. Fix the URL configuration once and several symptoms disappear at the same time. For the broader publish checklist, see lovable deploy.

Why the AI pointed Site URL at preview or localhost

Lovable generates code against the environment it can see. During build, that environment is the preview origin. Supabase client setup, OAuth callbacks, and email templates inherit that origin unless you override them.

The AI optimizes for “make login work here and now.” In preview, localhost and the Lovable dev URL are valid targets. Supabase ships with http://localhost:3000 as a default. The agent copies that into redirectTo options and env examples. It is context blindness, not malice.

Supabase does not know your production domain until you type it in. Connecting a project inside Lovable wires up keys and tables. It does not rewrite auth URLs when you publish.

Google OAuth adds another layer. The AI often registers the Supabase callback for the preview default. When you publish to yourapp.lovable.app or a custom domain, nothing in that chain updates itself.

Magic links and password resets use the same Site URL field. If Site URL is still localhost, every email link sends users to localhost.

Preview and production can also point at different Supabase projects if you cloned keys manually. The supabase auth article covers preview-vs-live mismatches in more depth.

Fix lovable login in Lovable and Supabase

Work in this order. Skipping a step brings the loop back.

1. Publish and copy your live URL. In Lovable, publish the project if you have not already. Copy the full origin: https://your-project.lovable.app or your custom domain with https://. No trailing path unless your app truly lives in a subfolder.
2. Open the correct Supabase project. In Lovable, confirm which Supabase project is linked. Open that same project in the Supabase dashboard. If preview and live use different projects, fix that mismatch before touching URLs.
3. Set Site URL. In Supabase, go to Authentication → URL Configuration. Set Site URL to your live origin, for example https://your-project.lovable.app.
4. Add Redirect URLs. In the same screen, add every origin that should receive auth callbacks. At minimum include your live URL, your Lovable preview URL, and http://localhost:5173 if you still test locally. Add explicit callback paths if your app uses them, such as https://your-project.lovable.app/auth/callback.
5. Update Google OAuth if you use Google. In Google Cloud Console, open your OAuth client. Under Authorized redirect URIs, ensure the Supabase callback is listed: https://<project-ref>.supabase.co/auth/v1/callback. In Supabase, under Authentication → Providers → Google, confirm the client ID and secret match that Google project.
6. Fix redirectTo in code if needed. Back in Lovable, search the codebase for redirectTo, emailRedirectTo, and hardcoded localhost. Replace fixed localhost strings with window.location.origin or an environment variable that resolves to the current host in production.
7. Republish. Save changes in Lovable and publish again so the live bundle picks up code fixes. URL-only changes in Supabase apply immediately, but code still pointing at localhost will override them.
8. Test in a clean session. Open a private browser window. Run through email magic link and Google once each. Confirm you land inside the app, not on login.

After a URL change, old magic links in earlier emails still point at old hosts. Send a fresh link when testing.

Checklist before you call lovable login fixed

• Site URL in Supabase matches your live origin exactly, including https://.
• Redirect URLs list includes live, preview, and any local dev origin you still use.
• No localhost remains in password reset or magic link emails sent from production flows.
• Google authorized redirect URIs include the Supabase /auth/v1/callback endpoint for the active project.
• App code uses the current origin for redirectTo, not a hardcoded preview host.
• Lovable publish completed after the last auth code change.
• Tested magic link and social login in a private window on the live URL.
• Supabase Auth logs show redirect_uri matching your live domain, not localhost.

When every box is checked, login should behave the same on the live site as it did in preview. If one provider still fails, compare the redirect in logs against the Redirect URLs list character by character.

FAQ

Why does lovable login work in preview but fail after publish?

Preview runs on a Lovable URL that Supabase already trusts. Your live domain is not in Site URL or Redirect URLs until you add it manually. Auth requests then bounce to localhost or get rejected.

Where do I change the Supabase callback URL for a Lovable app?

Open your Supabase project, go to Authentication, then URL Configuration. Set Site URL to your live domain and add every redirect path to Redirect URLs, including preview and production origins.

Why does Google login loop back to the sign-in screen?

Google sends users to the redirect URI registered in Supabase. If that URI still points at localhost or a preview host, the session never lands on your live app. Update Redirect URLs and the Google Cloud OAuth client authorized redirect URIs to match.