LovableAuthDNSSupabase

Lovable: sign-in fails after adding a custom domain

Sign-in works on *.lovable.app but fails or redirects incorrectly on the custom domain

In short: The domain is connected (or almost connected), but auth still uses the old Lovable URL, or DNS is stuck behind a proxy, so sign-in never returns to your domain.

Why it happens

A custom domain only serves the app after the project is published, and connecting one requires a paid Lovable plan. While the domain is in Setting up, Lovable is waiting on DNS and an SSL certificate. A proxied (orange-cloud) A record on Cloudflare, a leftover A/AAAA record, or a CAA record that blocks Lovable's certificate authority can leave it there. Once the domain is Active, sign-in still fails if the auth redirect list still has only https://….lovable.app. Lovable's built-in backend is supposed to add the custom domain automatically when it becomes Active; your own Supabase project and your own Google OAuth credentials do not.

How to fix it

1. Confirm you are on a paid Lovable plan and that the project is published. A domain will not serve the app until it is published. Check the status in Project → Settings → Domains.
2. If the status stays on Setting up or Verifying, open the DNS records Lovable shows and add them at your provider. On Cloudflare, set the A (and AAAA, if Lovable gave you one) record to DNS only (grey cloud), not proxied. Remove leftover A/AAAA records that point somewhere else. If you use CAA records, they must allow the certificate authority Lovable uses. Then use Check again and wait for DNS to propagate.
3. When the domain is Active, set it as the primary domain if you want all other addresses to redirect to it.
4. Fix sign-in. For Lovable's built-in backend, ask Lovable in the project chat to add the custom domain to the auth redirect URLs, or add it under More → Users → Settings → Advanced. For your own Supabase project, set Site URL to https://yourdomain.com and add https://yourdomain.com/** (and the www variant if you use it) under Authentication → URL Configuration. Keep the *.lovable.app URL there until you no longer need it.
5. If you use Google (or another OAuth provider) with your own credentials, add the same redirect URI in that provider's console and select it in Lovable / your auth settings. Then try sign-in from an incognito window on the custom domain.

Example

// Supabase Dashboard → Authentication → URL Configuration
// Site URL:  https://yourdomain.com
// Redirect URLs (examples):
//   https://yourdomain.com/**
//   https://www.yourdomain.com/**
//   https://your-project.lovable.app/**

Copy-paste fix prompt

I'm getting this error in my app:

Sign-in works on *.lovable.app but fails or redirects incorrectly on the custom domain

[Paste the full error, stack trace, and the file it points to here]

Likely cause: The domain is connected (or almost connected), but auth still uses the old Lovable URL, or DNS is stuck behind a proxy, so sign-in never returns to your domain.

Task: The custom domain is connected or still verifying, and sign-in fails or redirects to the old Lovable URL. Check publish + paid plan, fix DNS (Cloudflare DNS only if verification is stuck, no leftover A/AAAA, CAA allows the cert), then add the exact custom domain to Lovable or Supabase redirect URLs and to any OAuth provider console. Don't disable auth checks or point Site URL at localhost in production.

Rules:
- First explain the root cause in 2 sentences and list the files you'll change.
- Make the smallest change that fixes it. Don't refactor unrelated code.
- Don't disable security or checks (RLS, auth, signature verification, type checking, CORS allow-all) to make the error disappear.
- Never print or hard-code secret keys.
- Finish by telling me exactly how to verify the fix.

Common with: Lovable, Bolt, Cursor. Last reviewed 2026-11-15.