Guide · Lovable

Lovable login loop: causes and how to fix it

Updated 1 November 2026

Short answer: a login loop (a redirect loop after login) is when you sign in and the app sends you straight back to the login page. In a Lovable app it may come from one of three things: the app checks for a signed-in user before the session has finished loading, the address people use is missing from the Site URL and Redirect URLs, or the session has ended. Check the addresses first, because Lovable's own docs name them as the usual reason sign-in works in preview and breaks once the app is published.

Lovable's docs do not describe a "login loop" by name; the session causes below come from Supabase's docs.

Fixed in your code, then tested live. Check my app free

What you see, and what fixes it

The loop happens only on the published app or your custom domain, never in preview: the published address is missing from the redirect URLs. Fix: add it (Lovable: users and authentication).
You land on localhost, or on an address that is not your app, after signing in: the Site URL may still be the default http://localhost:3000. Fix: set it to your production address (Supabase: redirect URLs).
You come back from Google or an email link, bounce to the login page, and a reload gets you in: the app may have decided you were signed out before the session arrived. Fix: make the app wait until the auth state is known.
You sign in, refresh the page, and are back at login: the session may have ended (sign-out, inactivity timeout, maximum lifetime, or a sign-in on another device). Fix: check those settings (step 5).
It started after you connected a custom domain, and only on www or only on the bare domain: that address may not be in the list. Fix: add the exact address.

Why it happens

A login is a round trip: the person signs in, goes out to your auth provider or an email link, and returns to your app, which must find the session. A loop is that last step failing: the way back leads somewhere else, or the app does not see the session when it first looks.

For the first part, Lovable says that if sign-in works in preview but breaks on your published app or custom domain, the Site URL and Redirect URLs are usually the reason. On Lovable's built-in backend, publishing sets the Site URL to your published lovable.app address, and connecting a custom domain adds it to the redirect URLs. A Site URL you set yourself stays unchanged, and an app on your own Supabase project gets no automatic updates (Lovable).

For the second part, Supabase's client code documents an INITIAL_SESSION event, emitted after the stored session is loaded (supabase-js source; event list: Supabase: onAuthStateChange). Any page guard that asks "is someone signed in?" before that moment can get "no" and send a signed-in person to the login page. The docs do not call this a redirect loop, so treat it as a likely cause, not a proven one.

A real question

In a Supabase GitHub discussion, a user redirected after third-party login reported that the app showed no current user until a manual reload (Discussion #5858, March 2022). A Supabase collaborator replied that it takes a bit for the session to reach local storage when you come back, to use onAuthStateChange, and that this happens only the first time. The thread uses an older Supabase client, but the timing matches the current docs above.

How to fix it, step by step

Find where it loops. If it loops on your published or custom address but not in preview, start with step 2. If it loops everywhere, start with step 4.
Add your live address to the redirect URLs. In Lovable, open More, Users, Settings, Advanced, and add it under Redirect URLs, or ask Lovable in the project chat to add your domain to the auth redirect URLs (Lovable: users and authentication). With your own Supabase project, add it in that project's auth settings instead (Lovable: custom domain).
Set the Site URL to your production address and use the exact address in the list. Supabase says to change the Site URL from http://localhost:3000 to your production URL, and recommends the exact path for production over the ** wildcard (Supabase: redirect URLs). The redirectTo address only works if that exact URL is in the setting (Supabase: wrong redirect URL). If you use Google sign-in with your own credentials, the new domain also needs a redirect URI in Google Cloud Console (Lovable).
Make the app wait for the session. A prompt you can send in the Lovable chat: "Do not redirect to the login page until the auth state has finished loading. Show a loading screen first, then decide using the session from onAuthStateChange." This wording is our suggestion, not Lovable's. The event it relies on is documented by Supabase.
Check that the session is kept. By default the Supabase client sets persistSession to true and tries to store the session in local storage (Supabase: Auth reference). Sessions also end by design when a person signs out, after an inactivity timeout or maximum lifetime if you set one (a Pro-plan setting in Supabase), or when they sign in on another device with one session per user turned on (Supabase: user sessions).
Test as a new person: a private window, a new email, on the live address you share. Try the bare domain and www separately: Lovable redirects www to your primary domain by default for domains connected from another provider (Lovable: custom domain), and the address people open may not be the one in your list.

Frequently asked questions

Why does Lovable sign-in work in preview but loop on my published app?

Lovable's docs say the usual reason is that the published URL or custom domain is missing from the project's redirect URLs. They add these automatically on the built-in backend; if sign-in still fails, or you use your own Supabase project, add the domain yourself.

Where do I find the redirect URLs in Lovable?

Open More, then Users, then Settings, then Advanced, and look for Redirect URLs. You can also ask Lovable in the project chat to add your domain.

Why does reloading the page sign me in?

The session is read from storage when the app starts, and the app may have checked for a user a moment before it arrived. Supabase's client code documents an INITIAL_SESSION event for the moment the stored session is loaded.

Is the Site URL the same as a redirect URL?

No. The Site URL is the default address people are sent to after authentication when no redirect address is given. Redirect URLs are the list of addresses the auth provider may send them to. Both should include your live address.

Can a session limit send me back to the login page?

It can end a session. Supabase offers an inactivity timeout, a maximum session lifetime and one active session per user, on Pro plans and up. The check is applied the next time the session is refreshed, so the sign-out can look sudden.

Can VibeFix fix it for me?

Yes, if you ask. The free check confirms the problem first. Our AI agent can find the cause, fix it in your code and test your live app again. The price is on the pricing page.

Still broken?

If you changed the addresses and the loop is gone for you but new people still get sent back to login, start with a free check. Our AI agent signs up like a new user and shows you, with a screenshot, whether your app breaks for them. If you want it fixed, it fixes it in your code and tests your live app again.

Fixed in your code, then tested live. Check my app free

VibeFix is independent. Lovable, Bolt, Replit, Base44, v0, Supabase, Firebase, Stripe, Vercel and Google are trademarks of their owners.

Want it fixed?

Our AI agent fixes it in your code and tests your live app again. See pricing.

It starts with a free check that confirms the problem on your live app, no account needed.

Check my app free

More guides