Lovable Custom Domain Stuck on Setting Up? Here's How to Unstick It

Why is my Lovable custom domain stuck on Setting up?

Read the status word first, because it tells you which half of the process is stuck. Verifying means Lovable is still waiting for your DNS records to propagate. Setting up means DNS verification already passed and Lovable is issuing the SSL certificate. So a domain parked on Verifying is a DNS-record problem at your provider, while a domain parked on Setting up is a certificate problem — and only the first is fixed by editing records.

A domain sits on Verifying for only a handful of reasons. The records were never added at your DNS provider; they were added to the wrong host (a stray www, or a registrar that silently appends your domain to the Host field); an old record conflicts with the new one; or a proxy layer such as Cloudflare hides the real A record from Lovable's checker. Work through them in that order.

Lovable's connection prerequisites name the first conflict outright: there must be no AAAA records set for the domain you are connecting, because an AAAA record can interfere with domain setup and cause traffic to be routed incorrectly. A leftover IPv6 AAAA record from a previous host is what we call The Phantom AAAA — the single most common pattern we see in rescue tickets, and Lovable's own troubleshooting attributes the 'my domain shows the wrong site or an outdated version' symptom to exactly that record.

What DNS records do I need to add for a Lovable custom domain?

Lovable's manual setup asks for exactly two records per host: an A record pointing the host at Lovable's edge IP 185.158.133.1, and a TXT record on the host _lovable whose value starts with lovable_verify=. Both values are shown in Project → Settings → Domains when you connect the domain — copy them verbatim. Nothing else is required, and any AAAA record on that host has to go.

The Host (or Name) field trips up most people. Lovable suggests a default host for the A record, but depending on your provider it may need to be @, left blank, or set to your domain name — Amazon Route 53, for example, requires blank or the full domain name. Typing example.com into a provider that already appends the zone produces a record for example.com.example.com, which never resolves.

The www subdomain is a separate connection, not a variant of the root. For a domain bought through Lovable, both yourdomain.com and www.yourdomain.com are configured automatically and listed separately. For a domain registered elsewhere, www is not added for you: connect it as its own entry in Project → Settings → Domains and add the records Lovable shows for that host.

Set the TTL as low as your provider allows — Lovable's own DNS records use a 300-second minimum. A high TTL means an old cached record lingers for hours after you fix it, which is why a domain can stay stuck long after the records look correct in your dashboard.

Related: fix env vars that vanish on deploy · browse all Lovable deployment errors

How long does a Lovable custom domain take to verify?

Lovable publishes two different clocks, and confusing them is why people wait too long. DNS changes may take up to 72 hours to propagate, though most are live within a few hours — that is the outer bound on waiting. Separately, Lovable flips the status to Unable to verify when DNS verification has not completed within one hour, which is a prompt to re-check your records, not a verdict that they are wrong.

Propagation is not uniform. Lovable's verification server may query a resolver that still holds your old record while your own browser already sees the new one. That is why a domain can look correct from your laptop and still read as Verifying in Lovable. Lower the TTL before changing records, and confirm against a public lookup tool such as dnschecker.org rather than your local cache.

Certificates run on the same 72-hour ceiling. Lovable issues and installs the SSL certificate itself, and its documentation says that if the certificate has not been issued after 72 hours you should contact Lovable Support — so a domain that verified but never went Live is a support ticket, not a DNS edit.

Inside 72 hours with correct records, the honest answer is wait and re-check. Past it, stop waiting and audit: something does not match, and time alone will not fix it.

Why does my AAAA record break the custom domain setup?

An AAAA record points the host at an IPv6 address, and Lovable requires that none exist on the domain you are connecting — its stated prerequisite is that an AAAA record can interfere with domain setup and cause traffic to be routed incorrectly. A leftover IPv6 entry from a previous host is The Phantom AAAA, and it is the record Lovable's own troubleshooting blames when a connected domain serves the wrong site or an outdated version.

Deleting the stale AAAA record is the single fix that unsticks the largest share of stuck domains in our rescue queue.

Confirm the conflict from a terminal: dig AAAA example.com +short. If it returns an IPv6 address you do not recognise, that is your phantom record. After deleting it, dig A example.com +short should return 185.158.133.1 and nothing else. Until those two commands agree, the domain stays stuck — and note that Lovable documents 185.158.133.1 as its own server, so seeing that IP is confirmation you configured it correctly, not evidence of a previous host.

1. Open the DNS records panel at your DNS provider (not your registrar's marketing dashboard, if they differ).
2. Look for any AAAA record on every host you are connecting — the root and www are separate entries.
3. Delete the AAAA record entirely; Lovable's setup never asks you to add one.
4. Confirm only Lovable's A record (185.158.133.1) and the _lovable TXT record remain on that host.
5. Wait out the TTL, then open Project → Settings → Domains and click Check status.

Do I turn the Cloudflare cloud orange or grey for Lovable?

Set it to grey (DNS only) while the domain verifies. Lovable's instructions during verification are explicit: do not enable proxying on the A record and do not point it at a CDN or reverse proxy, or the domain stays in the Verifying state. Lovable also attributes Cloudflare error 1001 and error 1003 on a connected domain to the proxy rather than to its own hosting, and the fix it gives is the same — switch the records to DNS only.

If you actually need Cloudflare in front of the app, there is a supported path that does not involve grey-clouding and hoping. When you connect the domain, expand Advanced and enable 'Domain uses Cloudflare or a similar proxy'; Lovable then issues a CNAME record instead of the A record, and provisions SSL once that CNAME points correctly. The trade is ownership: with that option on, Lovable does not configure, validate, or monitor your proxy setup — you do.

1. In Cloudflare, open DNS → Records for your domain.
2. Click the orange cloud on the A record so it turns grey (DNS only).
3. Do the same for any other connected host, and confirm the _lovable TXT record is present and complete.
4. Return to Project → Settings → Domains and click Check status.
5. Wait for the status to move through Setting up to Live before changing anything back.

Related: if you also see 404s on refresh after deploy

How do I force a stuck Lovable domain to re-verify?

Use the button that matches your status, because Lovable gives a different control to each one. Verifying and Unable to verify get Check status, which re-reads DNS. Stalled and Failed get Retry, which re-attempts SSL provisioning — and Lovable states plainly that for a Stalled domain you do not need to remove and re-add it. Removing and re-adding is the last resort, not the first move.

Re-adding the domain issues a fresh verification token. If it does, replace the old lovable_verify= value at your DNS provider with the new one — leaving the stale token in place is a frequent reason a re-add stalls the same way the original attempt did.

1. Confirm the records resolve: run dig A example.com +short (expect 185.158.133.1) and dig TXT _lovable.example.com +short (expect the full lovable_verify= value).
2. Open Project → Settings → Domains and read the exact status word next to the domain.
3. On Verifying or Unable to verify, click Check status and confirm the full TXT value is present at your provider — a truncated value is the usual culprit.
4. On Stalled or Failed, click Retry; SSL provisioning is the step that is stuck, not DNS.
5. Only if none of those move it, remove the domain and re-add it in the same panel.

My records look right but the domain is still stuck — what now?

Three blockers survive a correct-looking record set: nameservers that are not the ones you are editing, a truncated TXT value, and a CAA record restricting certificate issuance. Check authority first — if you moved nameservers to Cloudflare but are still editing records at the old registrar, none of your edits are live anywhere, and every lookup you run against the domain will keep returning the old answer.

The TXT value is the quiet one. Lovable's own guidance on Verifying and Unable to verify singles out the full TXT value as the thing to check, because several DNS panels silently truncate a long lovable_verify= string or wrap it in quotes. Compare the value character-for-character against Project → Settings → Domains rather than eyeballing the first few characters.

A CAA record is the other. CAA restricts which certificate authorities may issue for your domain, so a restrictive one will block certificate issuance even when A and TXT are perfect and the domain has already passed verification — which shows up as Setting up, Stalled, or Failed rather than Verifying. Lovable does not publish which authority issues its certificates, so the safe move is to remove the restrictive CAA record or contact Lovable Support for the value to authorise, rather than guessing at a CA name.

If you have worked through every item here and the domain still will not verify, hand it to an engineer rather than burn another day. A focused deployment fix audits your live DNS, finds the exact conflicting record, and confirms the certificate issues.

Connecting the domain is usually the last item on a launch list, which makes it the right moment for the one people skip: cleaning up the code before launch. Missing error handling, dead files left by abandoned prompts and localStorage standing in for a database are all survivable in a demo and expensive the day real traffic arrives on the domain you just pointed here.

Related: get a Lovable app rescue and deployment fix · book a deployment fix call