How to Add a Custom Domain to a Lovable App
You've built something in Lovable, you're chuffed with it, and now you want it living at yourname.com instead of whatever-fluffy-otter.lovable.app. Fair enough. Setting up a Lovable custom domain is straightforward in principle, but there's a paywall - custom domains are a paid-plan feature - and a handful of DNS gotchas that catch loads of people out. You've got two paths: pay for Lovable Pro and use their built-in flow, or export the app and host it somewhere cheaper. I'll walk through both, plus the DNS faff and the Cloudflare error that traps a lot of people who try this.
The thing nobody tells you in the first 30 seconds
Custom domains on Lovable require a paid plan, currently Pro at $25/month or Business at $50/month (as of May 2026). The free tier publishes only to *.lovable.app. There's no hidden free option, no "just connect it and we'll bill later". If you're on Free and you point a domain at Lovable hoping it'll Just Work, it won't.
That out of the way, here's everything you need to actually get a domain wired up - or, if you'd rather not pay $25/month for one DNS record, the alternative that gets you there for less.
What you need before you start
- A domain you actually own. Namecheap, Cloudflare Registrar, Porkbun, GoDaddy - any of them work.
- A Lovable project that already publishes to
*.lovable.app. If you haven't clicked Publish yet, do that first; everything below assumes the project is live somewhere. - Access to your domain's DNS settings. If you bought the domain through Lovable's own registrar partner, this is handled for you. Otherwise you need to be able to add A, TXT and CNAME records at the registrar (or wherever your nameservers point).
- A paid Lovable plan, or a willingness to read down to the section where I explain how to avoid one.
One canonical note on timing: with the records correct, expect propagation in 5 to 30 minutes. Up to 72 hours in pathological cases, but I haven't seen that in years - DNS today is miles better than the week-long ISP caches I was wrestling with on a Quake clan site back in the Angelfire days.
What you get with Lovable's built-in custom domain
Lovable's paid custom-domain feature gives you automatic SSL, apex and subdomain support, primary-domain redirects, and a DNS-writing helper for some registrars. In more detail:
- Automatic SSL. Lovable provisions a certificate for you (Let's Encrypt under the hood). You don't touch it.
- Entri-assisted DNS for some registrars (GoDaddy, Namecheap, a handful of others). Entri is a little popup that logs into your registrar and writes the records for you. It's nice when it works, fiddly when it doesn't.
- Apex + subdomain support. You can put the app on
yourdomain.com, onapp.yourdomain.com, or on both. You can also connect multiple subdomains to different projects, which is genuinely useful if you're spinning up a few experiments. - Primary domain redirect. Designate one as primary, and the others 301 to it.
So far, so standard. The interesting bit is the DNS configuration, because that's where everyone gets stuck.
Lovable custom domain DNS: A record, CNAME, and TXT
When you start the connect flow, Lovable hands you three things to paste into your registrar:
- An A record at the apex. Host set to
@(or blank, or your domain name, depending on what your DNS provider calls it). Value is an IP address Lovable shows you in the dashboard. Edge IPs can change, so copy the exact IP from your own setup screen rather than from a tutorial. - A TXT record for ownership verification. Lovable generates a unique string you paste into a TXT record. This proves you actually control the domain before they hand you a certificate.
- A CNAME for
www. Hostwww, value is your Lovable subdomain (your-app.lovable.app). If you bought your domain through Lovable, this is added automatically; if you brought your own domain, you have to add it yourself.
There's a fourth thing that isn't a record to add - it's a record to remove. Any existing AAAA records on your domain will quietly hijack traffic to IPv6 addresses that aren't Lovable's, and you'll see "wrong site shown" or "stuck on the old host" symptoms. Delete the AAAAs first. This catches people who've previously hosted on Netlify, Vercel, or Cloudflare Pages, because those providers love their IPv6.
Why A + TXT instead of just a CNAME? Classic DNS limitation. CNAMEs aren't allowed at the apex (yourdomain.com with no subdomain) per RFC, so providers that want apex support either use A records or vendor-specific ALIAS/ANAME flattening. Lovable went with A records, which is the most portable choice.
How to publish your Lovable app to a custom domain
To publish to a custom domain on Lovable, follow these steps inside Lovable and at your DNS provider:
- Open your project, go to Project Settings > Domains (or use the Publish modal and pick Custom domain).
- Enter your domain name and click Connect.
- Lovable shows you the A record IP and the TXT verification string. Keep that tab open.
- In a second tab, open your DNS provider's dashboard:
- Add the A record. Host
@, typeA, value = the IP Lovable showed you, TTL default (3600 or "Auto"). - Add the TXT record. Host as specified by Lovable in the dashboard, type
TXT, value = the verification string in quotes if your provider doesn't add them automatically. - Add the CNAME for
wwwpointing toyour-app.lovable.app. - Delete any AAAA records on the apex and on
www.
- Add the A record. Host
- Back in Lovable, click Check status (or Complete setup). If DNS hasn't propagated yet, it'll say "Verifying"; that's normal, give it a few minutes and try again (see the timing note above).
- Once verified, Lovable provisions the SSL certificate automatically. You'll see the status flip to "Live" or similar.
- Optionally, mark this domain as Primary so the default
lovable.appURL redirects to it.
That's the happy path. Most setups land here without trouble.
Lovable custom domain not working: common errors and fixes
Most failures fall into one of four buckets: Cloudflare proxy on, DNS not propagated yet, leftover AAAA records, or SSL not issued. In rough order of how often I see them:
Cloudflare Error 1000 - "DNS points to prohibited IP"
If you proxy your domain through Cloudflare (the orange cloud icon next to your DNS record), Cloudflare's proxy gets in the way of Lovable's SSL termination and edge routing, and you get Error 1000. This is the single most common failure mode.
Fix: in your Cloudflare DNS dashboard, click the orange cloud next to the A record so it goes grey. That switches the record from "Proxied" to "DNS only", which lets traffic flow straight to Lovable. SSL termination then happens at Lovable's end instead of Cloudflare's, which is exactly what you want. If you also have a CNAME for www proxied, switch that to DNS only as well.
You can still use Cloudflare for the registrar function and other zone settings. You just can't proxy the actual traffic to Lovable; Lovable's edge wants to handle the request directly.
Stuck on "Verifying" or "Unable to verify"
Three common causes:
- DNS hasn't propagated yet. Run
dig yourdomain.comfrom your terminal (or use dnschecker.org) and confirm the A record shows the IP Lovable gave you. If it shows your old host, wait. - TXT value was pasted incomplete. Some registrars strip quotes or truncate long values. Re-add it, pasting carefully and triple-checking.
- Cloudflare proxy is on (see Error 1000 above).
SSL pending forever
Verification succeeded but the certificate didn't issue. Usually this just needs a nudge - hit Retry in the Lovable dashboard and it'll re-trigger the Let's Encrypt request. If it still won't issue, double-check that the A record isn't proxied behind Cloudflare; Let's Encrypt's HTTP-01 challenge needs to reach Lovable's edge directly.
Apex works but www doesn't (or vice versa)
Means one of the two records is missing or pointing at the wrong target. Apex needs the A record; www needs a CNAME to your *.lovable.app subdomain. Both, not one.
The site loads but shows the old hosting provider
Almost always a leftover AAAA record. Delete it.
Lovable custom domain pricing - what you actually pay
Lovable custom domain pricing starts at $25/month on the Pro plan, with Business at $50/month and Enterprise on request. The Free tier is *.lovable.app only. Current as of May 2026:
| Plan | Price | Custom domain support | Best for |
|---|---|---|---|
| Free | $0 | No, *.lovable.app only | Prototyping |
| Pro | $25/mo (or $250/yr) | Yes, unlimited custom domains | Solo builders shipping live apps |
| Business | $50/mo (or $500/yr) | Yes, plus team access controls | Small teams |
| Enterprise | Custom pricing | Yes, plus SSO and compliance bits | Companies with procurement |
The custom domain itself is free once you're on any paid plan. Lovable doesn't charge per-domain.
If you bought the domain through Lovable's IONOS partnership, you pay standard registrar pricing (think $12-$18/year for a .com). That's separate from the Lovable subscription.
The thing to weigh up: if the only reason you're looking at Pro is the custom domain, you're paying $25/month for what is essentially one DNS record and a free Let's Encrypt cert. Worth it if you're also getting value from Lovable's monthly credits and live editing. Not worth it if you've finished building and just want the thing online.
Which brings us to path B.
The alternative path - export your Lovable app and host it elsewhere
If your Lovable app is essentially a static frontend (a landing page, a portfolio, a simple SPA, anything without a live backend running on Lovable Cloud or Lovable's hosted Supabase auth), you can export it and host it on something cheaper or free. I've done this for a couple of throwaway projects and it works fine.
What gets exported
Lovable has a GitHub integration. From the project, hit Connect to GitHub (or Transfer to GitHub, depending on which UI variant you've got). After authorising the GitHub app, Lovable creates a repo and pushes your entire codebase to it - the React/Vite source, components, configs, the lot. It's a real two-way sync; you can clone the repo, build it locally with npm run build, and you've got a dist/ folder of static files ready to host anywhere. Similar pattern to exporting from Webflow, only with a friendlier React codebase coming out the other end.
What does not carry over: anything tied to Lovable's runtime. If you're using Lovable Cloud, hosted Supabase auth proxied through Lovable, or any of the platform-managed services, those endpoints live on Lovable's infrastructure. Export the frontend and the API calls will still go to Lovable; you don't escape the dependency by exporting. For most marketing sites and simple apps this is fine, because they don't have those dependencies in the first place. For an app with real backend state, you'd be looking at migrating Supabase yourself, which is a bigger job.
This export-and-host pattern is the same idea I covered in Replit alternatives and the Claude artifact publishing guide - AI builders are great for the build, but the hosting is often the most expensive bit of the stack relative to what you actually get.
Building the export locally
After Lovable pushes to GitHub:
git clone https://github.com/your-username/your-lovable-app
cd your-lovable-app
npm install
npm run build
You'll end up with a dist/ folder (or build/, depending on the Vite config). That folder is the entire static site, ready to upload anywhere that serves static files.
Point your domain at Hostsmith instead
Full disclosure - this is Hostsmith's blog, so this is the bit where I tell you what we do. It's relevant to the topic.
Hostsmith is static hosting. You upload a folder (or a zip, or individual files), it goes live in seconds, and custom domain support kicks in from the Standard plan upwards (from $9/mo). Upload your Lovable dist/, add your domain in the site settings, and Hostsmith shows you the A record (and CNAME) to paste into your registrar. Same shape as the Lovable flow, different destination. If you've followed along with the drag-and-drop website hosting guide, it's exactly the same drill.
A note on the Free tier: it gives you a regional subdomain - your-site.us.hostsmith.link or your-site.eu.hostsmith.link depending on the partition - at $0, no card. That's enough for static one-pagers, but a built Lovable React/Vite dist/ folder will almost certainly bust the 5MB upload cap on Free - so in practice you're looking at Basic for the size, or Standard if you also want a custom domain.
Where this isn't the right answer: if your Lovable app has a live backend you're actively iterating on, stay on Lovable. The whole point of the platform is that the AI keeps shipping changes for you. Exporting and hosting elsewhere freezes the build. You can always re-export later, but if you're still in heavy build mode you'll just be doing this dance every week.
Lovable hosting vs. export + Hostsmith - side by side
| Capability | Lovable Pro | Export + Hostsmith Standard |
|---|---|---|
| Monthly cost | from $25 | from $9 |
| Custom domain | Yes | Yes |
| Automatic SSL | Yes | Yes |
| Live AI editing | Yes | No (you'd re-export) |
| Backend / DB hosting | Yes (Lovable Cloud) | No, static only |
| Free tier with vendor subdomain | *.lovable.app | *.us.hostsmith.link / *.eu.hostsmith.link (5MB upload cap) |
| GDPR / EU residency option | No specific partition | EU partition available |
Pick on the basis of "still building" vs "shipped and static". Both are reasonable answers; neither is universally right.
Frequently asked questions
Does Lovable require a paid plan for custom domains?
Yes. Pro at $25/month is the cheapest tier that supports custom domains. Free is locked to *.lovable.app.
Can I use Cloudflare with Lovable? Yes as a registrar and for DNS management, but set the proxy status to "DNS only" (grey cloud) for the A record. Proxied (orange cloud) triggers Error 1000.
How long does Lovable custom domain DNS take to propagate? Usually 5 to 30 minutes; longer in rare cases. If you're not live within an hour or two, something is wrong - check the records.
Why is my Lovable custom domain not working? Almost always one of four causes: Cloudflare proxy is on (Error 1000), DNS hasn't propagated yet, a leftover AAAA record is hijacking traffic, or SSL hasn't been issued yet. Work through them in that order.
Can I switch domains later without losing my Lovable URL?
Yes. Your *.lovable.app URL stays active even after you connect a custom domain. You can disconnect and reconnect, swap domains, or add multiple, and the Lovable subdomain remains as a fallback.
Does my Lovable subdomain stay active after I connect a custom domain? Yes, by default. If you want the Lovable URL to redirect to your custom domain instead, mark your custom domain as Primary in the Domains settings.
Can I use a subdomain like app.mydomain.com instead of the root?
Yes. Lovable supports subdomains the same way it supports apex domains. For a subdomain you use a CNAME pointing to your *.lovable.app URL rather than an A record. You can also connect multiple subdomains to different projects.
What happens if I cancel my Lovable subscription?
The custom domain stops resolving to your Lovable app, and your project reverts to publishing on *.lovable.app (with the same plan-tier restrictions Free has). You don't lose the project; you lose the custom-domain feature until you re-subscribe.
Can I host my Lovable app somewhere else and keep my domain? Yes - that's path B above. Export to GitHub, build locally, host the static output anywhere. Point your domain at the new host instead of Lovable. The catch is anything that depends on Lovable's hosted runtime stays tied to Lovable. For purely static apps, this works cleanly.
Funny how things come full circle. Twenty-odd years ago I was uploading Geocities pages via FTP and faffing with A.B.C.D IPs in some registrar's clunky DNS panel. The tools have got a thousand times better, the IPs have got harder to remember, but the underlying dance - one A record at the apex, one CNAME for www, one TXT to prove you're you - is the same as it ever was. If you've got the records right and the proxy off, your Lovable app will be on your domain inside an hour. If it isn't, it's almost always one of the four things in the troubleshooting section above.
For more on the build-then-host pattern across AI tools, see the vibe-coding website guide and the rundown of GitHub Pages alternatives for when you've outgrown the obvious option. And if you've just got a single HTML file you want online, hosting an HTML file online has the quickest route.