FixLoop

Lovable custom domain not working

Guide · October 20, 2026

Your Lovable custom domain is not working: it sits on Verifying, the browser shows a security warning, it loads your old website, or the site works but login fails. Almost every case is one of five DNS or auth settings, and Lovable's domain status tells you which one.

Open Project → Settings → Domains, read the status next to the domain, then jump to the matching section below. Custom domains need a paid Lovable plan, and the project has to be published before the domain serves anything.

Sources: Lovable: Set up a custom domain and Supabase: Redirect URLs. Checked October 20, 2026.

Stuck on this right now? Paste your error and we'll email you the likely cause within 24 hours, free.

The records Lovable expects

For a domain bought elsewhere and connected with manual setup, Lovable gives you two records. Copy them exactly from the Domains page:

Type  Host                          Value
A     @   (or blank / the domain)   185.158.133.1
TXT   _lovable                      lovable_verify=...   (subdomain: _lovable.blog)

Then check that nothing else is fighting them: no AAAA record on that host, no leftover A or CNAME from your old host, and no CAA record that blocks Lovable's certificate authorities.

Stuck on Verifying or "Unable to verify"

Lovable cannot see the records it asked for yet. In order of how often we see it:

• The A record is proxied. In Cloudflare, an orange-cloud A record hides Lovable's IP. Lovable's docs say that while verification is in progress you should not enable proxying on the A record or point it at a CDN. Switch it to DNS only (grey cloud).
• The TXT value is cut off or on the wrong host. The host is _lovable (or _lovable.sub for a subdomain), and the whole lovable_verify= value has to be there. Some providers append your domain to the host automatically, so _lovable.example.com typed in full can become _lovable.example.com.example.com.
• The host name format is wrong for your provider. Depending on the provider, the root host is @, blank, or the domain name itself. Lovable's docs note Route 53 wants it blank or set to the domain name.
• DNS has not caught up. Lovable says: "DNS changes may take up to 72 hours to propagate, though most updates are live within a few hours." Check with a public DNS lookup, then click Check status.

SSL warning, or stuck on Setting up / Stalled / Failed

Once ownership is verified, Lovable issues the certificate itself. Lovable's status table says that during Setting up, "Until the certificate is ready, the browser shows a security warning instead of your site." That warning is expected for a while. Wait for Live before testing.

If it does not move on, check for CAA records, including on the parent domain (a subdomain inherits them). They must allow at least one of the authorities Lovable uses:

0 issue "pki.goog"
0 issue "letsencrypt.org"
0 issue "ssl.com"

After the change takes effect, click Retry next to the domain. You do not need to remove and re-add it. You also do not need to buy or upload a certificate at your registrar: Lovable issues and serves its own, and a registrar certificate is not used.

The domain loads your old site, or the wrong version

Old records are still answering. Remove every A, AAAA and CNAME left over from the previous host on that name, so only Lovable's A record and TXT record remain. An AAAA (IPv6) record is the sneaky one: visitors on IPv6 can still be sent to the old server.

Cloudflare error 1001 or 1003 comes from Cloudflare's proxy, not Lovable. Set the Lovable records to DNS only. If you really want Cloudflare in front, connect the domain with the Uses Cloudflare or similar proxy option instead: Lovable then gives you a CNAME to your lovable.app URL in place of the A record, and you own the proxy setup.

Site loads on the custom domain, but login fails

This one is auth, not DNS. Lovable's FAQ puts it plainly: "Your app's auth redirect URLs don't include the new domain yet."

• Lovable Cloud backend: Lovable adds the domain to the redirect URLs when it goes Live. If sign-in still fails, add it under Cloud auth settings or ask Lovable in chat.
• Your own Supabase project: add it yourself in Authentication → URL Configuration. Supabase's docs: "The URL in redirectTo should match the Redirect URLs list configuration." Set Site URL to the custom domain too.
• Google sign-in with your own OAuth client: add the new domain in Google Cloud Console as well.

Site URL:       https://yourdomain.com
Redirect URLs:  https://yourdomain.com/**
                https://www.yourdomain.com/**

If you land on localhost:3000 after Google sign-in, Site URL is still the default. The full walkthrough is in Lovable authentication errors in preview vs production.

www vs root, and redirects

Connecting the root domain keeps the Redirect www → root option on by default, so www is listed as a second domain and needs its own records. Lovable redirects every non-primary domain to the primary one with a 302, and its hosting does not offer 301s between connected domains. Set the primary domain from the three-dots menu once it is Live.

Quick checklist

• Project is published and the plan includes custom domains.
• A record = 185.158.133.1, DNS only, no proxy.
• TXT on _lovable with the full lovable_verify= value.
• No AAAA, no leftover A/CNAME from the old host.
• CAA records (here and on the parent) allow pki.goog, letsencrypt.org or ssl.com.
• Status is Live before you judge SSL.
• Custom domain added to Supabase Site URL and Redirect URLs (and Google Cloud, if you use your own client).
• Domain is fine but the app is blank or talks to the wrong backend: Lovable app not deploying or not working after deploy.

Questions

Related: login works in preview, breaks in production, app not working after deploy, connect an existing Supabase project.