Lovable login not working after you publish? Why it breaks and how to fix it
If sign-in works in the Lovable preview but fails on your published app or your custom domain, the usual cause is that the live address is missing from the app's redirect URLs. Lovable's own documentation names this as the likely reason when preview works and the live site does not (Lovable, Users and authentication). This note runs four checks in the order we would run them: the redirect URL list, your own Supabase settings if you use them, Google sign-in, and email confirmation.
What a redirect URL does
After someone signs in, or clicks a confirmation or password reset link, the auth system sends them back to your app. It only sends them to addresses on an allow list. Lovable describes two settings. The Site URL is where users go after authentication when no redirect URL is specified. The Redirect URLs are the addresses auth providers may redirect to, up to 50 entries. Supabase's documentation describes the same pair: the Site URL is the default redirect when your code does not give one, and the redirect URL in your code should match its Redirect URLs list (Supabase, Redirect URLs).
Check 1: the redirect URL list
Open the list as Lovable's docs describe it, under More, Users, Settings, Advanced, Redirect URLs. Look for the exact address people use: your lovable.app address, your custom domain, and the www and non-www versions if you serve both. The last point is our own advice.
- On the built-in backend, Lovable keeps the list updated. On publish it sets the Site URL to your published address unless it is already on your own domain, and connecting a custom domain adds that domain to the redirect URLs.
- The custom domain page says the domain is added once it is Active (Lovable, Set up a custom domain). Lovable's hosting page says you can check its status under Project, Settings, Domains (Lovable, hosting).
- If sign-in still fails, Lovable's advice is to ask in the project chat to update the URLs for your domain.
- To add an address Lovable does not serve, add it yourself with a /** ending and a domain you control. For local testing use 127.0.0.1, because Lovable rejects localhost.
Check 2: your own Supabase project
If the app uses your own Supabase project instead of the built-in backend, Lovable adds its own addresses but you manage the Site URL and any address Lovable does not serve. Supabase calls the Site URL setting critical for email confirmations and password resets, and its example value is http://localhost:3000, which it says to change to your production URL. For production it recommends the exact redirect path, and says the ** wildcard is useful for local development and preview URLs.
Check 3: Google sign-in
Lovable offers two forms of Google sign-in (Lovable, Google authentication). The managed option needs no Google Cloud setup and needs no change when you connect a domain. With your own Google credentials, every redirect URI you plan to use must be added in Google Cloud as an Authorized redirect URI, and the page says they must match exactly, including scheme, domain, path and trailing slashes.
If you connect a custom domain later while using your own credentials, Lovable adds its redirect URL to the list but does not select it. Until you add the URL in Google Cloud, select it in Lovable and save, sign-in on that domain fails with a redirect URI mismatch error. The Google client must be a Web application client; mobile and desktop types are not compatible.
Check 4: email confirmation and sending limits
- With auto-confirm off, new users must confirm their address by email before they can sign in. Lovable recommends keeping confirmation on for live apps (Lovable, Email authentication).
- Until email sending is set up for your project, authentication emails go through a shared sender with a strict limit, and raising the rate limit setting does not deliver more emails in that case.
- A user stuck unconfirmed is not helped by signing in again, because that does not resend the email. The user can sign up again with the same address, or you can create the account yourself under Add user, which confirms it.
Test it the way a new user would
This part is our own advice, not the docs. After every change, open a private window on the live address, create a new account and walk the whole path: sign up, confirm, sign out, sign in, reset the password. Keep a list of every address the app answers on, because each one needs to be on the redirect list.
When it is not the redirect list
If sign-in works but people can see each other's data, or pages that should need a login are open, that is a different problem and worth fixing before you promote the site. The AI-Built App Audit is a report-only review of sign-in, data access, exposed keys and payments for $299 USD. App Rescue and Move to Cloudflare then offers a Rescue in place for a fixed $999 USD that covers sign-in (auth), SEO and indexing, security and stability while the app stays where it is. Not sure where to start? App Triage is $99 USD for a written diagnosis and plan.
Related notes: why a Lovable or Bolt site is not showing in Google and how to export your code and keep it running. If people can see each other's data, read Supabase row level security mistakes and how to check yours.
Sources
- Users and authentication, Lovable docs
- Email authentication for your app, Lovable docs
- Set up a custom domain, Lovable docs
- Add Google authentication to your app, Lovable docs
- How Lovable hosts your app, Lovable docs
- Redirect URLs, Supabase docs