Lovable login not working on your custom domain: 6 causes

Which address do you land on after signing in?

Open your custom domain in a private window, try to sign in, and read the address bar when it stops. Then open Chrome's developer tools, go to the Network tab, type auth/v1 into the filter, and try again. The request named authorize (for Google) or otp (for a magic link) carries a redirect_tovalue. That's the address your app asked Supabase to send the user back to, and it has to be on the list exactly as written.

Cause 1: your domain isn't in Supabase's redirect URLs

Supabase keeps two settings for where users go after they sign in. The Site URL is what its docs call the default destination when the code doesn't name one. The Redirect URLs list is every other address the code is allowed to ask for. Lovable's docs say that on its built-in backend, publishing sets the Site URL to your lovable.app address, and connecting a custom domain adds the domain to the redirect list. On your own Supabase project, nothing is automatic.

So the usual story on your own project: the code asks to come back to https://app.example.com/, that address isn't on the list, and Supabase sends the user to the default instead: the lovable.appaddress if that's what you set when you published, or localhost:3000if nobody changed it. The sign-in worked. The customer is logged in on an address they never typed, and your domain still shows the login page. Lovable's own FAQ puts it in one line: if sign-in works in preview but not on the published app or custom domain, the published URL or custom domain is missing from the redirect URLs.

The fix on your own Supabase project

In your Supabase project, open Authentication, then URL Configuration. Set the Site URL to the address customers use, with https and no trailing slash. Then add your domain to Redirect URLs. Supabase supports wildcards, and its docs explain that * stops at a dot or a slash while ** matches anything, so https://app.example.com/** covers every page on the domain. The docs recommend the exact path for production rather than a catch-all, so if your app always returns to one page, list that page.

https://app.example.com/**
https://www.app.example.com/**      # only if www is served too (cause 2)
https://yourapp.lovable.app/**      # keep it for your own testing
# plus the preview address Lovable shows, if you test sign-in there

Then check what the code asks for. Lovable usually generates the address from the page the user is on, which is right, because it follows whichever domain the user came in on:

await supabase.auth.signInWithOAuth({
  provider: "google",
  options: { redirectTo: `${window.location.origin}/` },
});

If it hard-codes the lovable.app address instead, every sign-in will land there no matter which lists you fix. Search the code for lovable.app and replace it with window.location.origin. Lovable's docs cap the list at 50 entries, which is plenty, but wildcards keep it short.

The fix on Lovable Cloud

Lovable's docs say the domain is added to the redirect URLs automatically once it shows as Live. If it still fails, ask Lovable in the project chat to add the domain, or open More, then Users, then Settings, then Advanced, and add it under Redirect URLs yourself. A Site URL you set by hand is left alone, so if you ever typed one, check it's your domain and not the preview.

Cause 2: www, the bare domain, and http vs https

Both allow-lists are matched as text. Lovable's Google docs spell it out: redirect URIs must match exactly, and scheme, domain, path, and trailing slash all count. To the list, https://example.com and https://www.example.com are two different sites, and http:// is a third. A customer who typed wwwwhen you only listed the bare domain gets sent to the Site URL, and you can't reproduce it because you never type www.

Lovable handles half of this for you. Its custom domain docs say that when you connect a root domain, the "Redirect www to root" option is on by default, so www is connected as a separate domain and visitors on it are sent to the bare one. If you left that on, every customer ends up on one address before the sign-in page loads, and one redirect entry is enough. If you turned it off, or connected www as the primary and the bare domain separately, both are being served and both need an entry.

For http, there's nothing to list. Lovable issues a certificate for every connected domain, so list only https entries and let the certificate finish (cause 6) before you test.

Cause 3: Google says redirect_uri_mismatch

Google sign-in has a second allow-list, in Google Cloud, and it holds a different address. Supabase's Google guide says the authorised redirect URI you add in Google Cloud is your Supabase project's callback, which you copy from the Google provider page in the Supabase dashboard. It looks like https://abcdefgh.supabase.co/auth/v1/callback. Your own domain is not what goes there. Google sends the user to Supabase, and Supabase sends them on to your domain, so changing domains normally needs nothing in Google Cloud at all.

Two things break that. First, someone added your domain to Google Cloud instead of the Supabase callback, or added the callback with a typo, a trailing slash, or http. Google refuses with "Error 400: redirect_uri_mismatch" and shows the URI it was sent. Copy that URI exactly as shown into Authorised redirect URIs on your OAuth client. The same guide says to add your app's origin, the address with no path such as https://app.example.com, under Authorised JavaScript origins, and to remove any localhost origin before going live.

Second, and specific to Lovable: if you use your own Google credentials on Lovable Cloud, Lovable's Google sign-in docs say connecting a custom domain adds its redirect URL to the list in Lovable but doesn't select it. Until you add that URL as an authorised redirect URI in Google Cloud, go back to Lovable, select it, and save, Google sign-in fails on the new domain with a redirect URI mismatch. The setting is under More, then Users, then Settings, then Google. Lovable's managed Google sign-in needs none of this, because Lovable owns the OAuth client.

1. Read the URI in Google's error message. That's what was sent.
2. In Google Cloud, open the OAuth client. It must be a Web application client; Lovable's docs say mobile and desktop types don't work with its redirect flow.
3. Add that exact URI to Authorised redirect URIs, and your domain to Authorised JavaScript origins. Save.
4. On Lovable Cloud with your own credentials, select the new redirect URL in Lovable and save there too.
5. Try again in a private window, on the custom domain.

Cause 4: the Google consent screen shows your Supabase project

This one doesn't stop sign-in, but customers stop themselves. Because Google sends users to Supabase first, the consent screen says they're continuing to abcdefgh.supabase.co, not to your app. Supabase's own guide says that doesn't inspire trust and makes phishing easier, and recommends two fixes.

Branding and verification in Google Cloud

Fill in Branding on the Google Auth Platform page: app name, logo, home page, privacy policy, and terms. Then submit for verification. Supabase notes it isn't automatic and can take a few business days. Lovable's docs add that an unpublished Google app only admits the test users you list, which is why a founder's own Google login works and a customer's doesn't.

A custom auth domain in Supabase

Supabase's custom domains page describes the second fix: a subdomain of yours, such as auth.example.com, in front of the project, so the consent screen names your site. It's a paid add-on on a paid plan, takes one subdomain per project on a CNAME record, and the certificate can take up to 30 minutes. The catch is that it changes the callback: once the domain is active, Supabase uses it for OAuth, so you add https://auth.example.com/auth/v1/callback in Google Cloud alongside the old one, which keeps working. Skip this step and you have just created cause 3.

On Lovable Cloud with managed Google sign-in, Lovable's docs say the consent screen already shows your app name. That's the simplest route if you don't need custom scopes.

Cause 5: signed in on one address, logged out on the other

A Lovable app keeps the Supabase session in the browser's local storage, and the browser keeps that storage separately for each origin. Signing in on https://www.example.com stores a session there; opening https://example.comfinds none. Your app hasn't lost the login, it's looking in a different box. The same applies between your domain and the lovable.app address, which is why a customer who signed in on one and clicked a link to the other reports being logged out.

The fix is the one from cause 2: one address serves the app, the other redirects to it before any page loads, and every link you send, every email template, and every redirectTouses the primary. If both addresses genuinely have to work, as when customers have bookmarked both, make sure both are in the redirect list and accept that a session on one won't carry to the other. Supabase's custom domains page adds one more case: Sign in with Twitter stores a cookie tied to the project's domain, so if you use it with a Supabase custom domain, your front end has to use that domain too.

Cause 6: the domain isn't live yet and serves an old build

Sometimes nothing in auth is wrong. The domain is still pointed at the old host, or at Lovable but without a certificate, and what you're testing isn't the app you published. Lovable's custom domain docs say DNS changes can take up to 72 hours, though most are live in a few hours, and that the certificate is issued automatically once the records resolve. A sign-in attempt in between hits whatever used to be there: an older build with the old code, a parked page, or a certificate warning.

• Old site still showing.Lovable's docs say to remove leftover A, AAAA, or CNAME records for the host, leaving only Lovable's A record (185.158.133.1) and the _lovable verification TXT record. An AAAA record in particular can route some visitors to the old host while others see the new one.
• Cloudflare.The same page says to set Lovable's records to DNS only, the grey cloud, not Proxied. Proxied records produce Cloudflare errors and can stall the certificate.
• Certificate stuck. Check for CAA records. Lovable lists pki.goog, letsencrypt.org, and ssl.com as the authorities to allow, then click Retry. No certificate after 72 hours is a support ticket.

Until Settings, then Domains shows the domain as Live, don't change any auth setting based on what you see. Fix the records, wait, then start the table at the top again.

Lovable Cloud vs your own Supabase project

Which of the six you're likely to hit depends on where the backend lives. Lovable's docs are clear that auth settings are managed in Lovable on the built-in backend and in the Supabase dashboard when the app uses your own project, with no automatic updates in the second case.

Most apps with paying customers end up on their own Supabase project, because that's where backups, custom SMTP, and the access-rule audit in the Supabase RLS checklist live. The price of that control is the left-hand column stops happening for you. If you've also taken the front end off Lovable, the domain steps change too, and they're in moving a Lovable app to your own hosting.

Test sign-in on the custom domain after the fix

Login was one of the three things broken in the social challenge app when I took it over from an agency, next to payments and security, on a product where users stake real money. Fixing an allow-list takes minutes. Finding out from the first customer who tried your real domain costs the customer. Run this once on each address people can reach, in a private window, before you announce the domain:

1. Open https://example.com and https://www.example.com. One should redirect to the other before the page loads, and the padlock should show on both.
2. Sign in with email and password. The address bar should stay on your domain, not jump to lovable.app.
3. Sign in with Google. The consent screen should name your app, and the return should land on your domain.
4. Request a magic link or a sign-up confirmation to a real inbox. The link should open your domain. If it opens localhost or the reset page is broken, the rest of that flow is in Lovable password reset link not working.
5. Reload while signed in, then open a second tab on the same address. Still signed in on both.
6. Repeat steps 2 and 3 on a phone, including iPhone Safari.
7. Sign out. The login page should load on your domain with no stale data.

Sign-in on the real domain is one of the eleven checks on the free Lovable post-launch checklist, next to access rules, secret keys, and Stripe webhooks, if you want the whole list in one place.

When to get help with Lovable login on a domain

If the table pointed at one cause and the fix took ten minutes, you're done. Get help when the login is one of several things that broke on launch, when customers can reach data after signing in that they shouldn't see, or when the app is about to take payments and nobody has tested sign-in, reset, and checkout end to end on the real domain. Settings nobody opened tend to travel together: a missing redirect entry usually sits next to a missing access rule.

Logins and auth are one of the six areas in my Launch-Ready Review, a fixed-price check of a vibe-coded app for $900–1,500 in three to five days, with a written report and a priced fix list. If the list is long, fixing it is a Production Sprint for $3,000–7,500, and the review fee comes off it. Either way, send me the app's linkand the address the browser lands on after you try to sign in, and I'll tell you which cause it is.