Connect a custom domain to your Lovable site
Custom domains in Lovable are a paid feature - Pro starts at $25/month, or $250 a year (checked August 2026). If you're happy to pay that, the whole job is two DNS records: an A record pointing your domain at 185.158.133.1, and a TXT record on the host _lovable with the lovable_verify= value Lovable gives you. Add those, publish the project, wait. That's it, and the exact steps are below.
If you'd rather not pay $300 a year to put a folder of HTML on a domain you already own, there's a second route most guides get wrong: Git sync is free on every Lovable plan, including Free. The Download codebase button is the Pro-only one. Connect GitHub instead and your code is out, at zero cost, and the domain can point anywhere you like.
Here's what each route actually involves.
Route A: connect the domain inside Lovable
Two things have to be true before you start. The project must be published - a connected domain serves nothing until it is. And the domain must have no AAAA records, because an IPv6 record left over from a previous host will quietly route traffic somewhere that isn't Lovable.
Domain setup lives in three places, all the same screen: Project → Settings → Domains, the Publish dialog → Add domain, or Workspace settings → Workspace domains. Click Connect domain, type the domain, and Lovable opens an Entri modal. Entri can detect your registrar and write the records for you if you log in and authorise it. If your provider isn't listed, scroll to the bottom of the Select your domain provider modal and pick Go to our manual setup.
Manual setup gives you these:
| Type | Host | Value |
|---|---|---|
| A | @ (see below) | 185.158.133.1 |
| TXT | _lovable | lovable_verify=… (copy the full string) |
The host field is where people lose an afternoon. Depending on the registrar it needs to be @, left completely blank, or set to the literal domain (example.com). Amazon Route 53, for one, wants it blank or as the domain name. Copy the TXT value in full - a truncated verification string is the single most common reason a domain sits on Verifying forever.
Three more things the setup screen doesn't shout about:
wwwis not included. For a domain you bought elsewhere, connectingexample.comdoes not connectwww.example.com. Add it as a second domain if you want both. Domains bought through Lovable get both set up automatically.- Cloudflare users: set the records to DNS only - the grey cloud, not the orange one - or you'll get Cloudflare error 1001 or 1003. If you genuinely want to keep proxying, expand Advanced during setup and enable Domain uses Cloudflare or a similar proxy; Lovable then hands you a CNAME instead of the A record and stops validating your proxy config for you.
- Redirects between your domains are 302s. Lovable lets you mark one domain as primary and redirects the rest to it, but the docs are explicit that it does not support 301 permanent redirects between connected project domains. If you connect both apex and
www, the non-primary one redirects temporarily and forever. It works for humans. It's not what you'd choose for search engines.
Then watch the status:
- Verifying - DNS is still propagating. Check status re-reads your records.
- Unable to verify - An hour passed without success. Usually a wrong or truncated record - occasionally just slow propagation, which can take up to 72 hours.
- Setting up - Verification passed; the SSL certificate is being issued. Nothing for you to do.
- Stalled or Failed - SSL provisioning is late or failed. Both have a Retry button - you do not need to remove and re-add the domain.
- Live - Serving your project over HTTPS. The finish line.
- Offline - It worked and then stopped: the DNS records changed underneath it. Recover shows you what they should be.
What Route A costs
Pro's entry tier is 100 credits for $25/month, or $250 billed annually ($21/month) (checked August 2026). Business starts at $50/month for the same 100 credits. Free gives you 5 build credits a day capped at 30 a month, and no custom domain.
The credits are the point of the plan; the domain is a feature bundled with it. Also bundled: removing the "Edit with Lovable" badge, editing code, and downloading the codebase. And to be fair to Lovable, hosting itself is genuinely uncapped - the docs state your plan does not cap visitors, requests or bandwidth, and a live site consumes no credits on its own. You're buying build capacity and getting a domain with it.
Route B: get the code out, point the domain wherever
This is where the received wisdom is wrong. Lovable's plan matrix lists Git sync (GitHub and GitLab) as available on Free, Pro, Business and Enterprise, and the GitHub integration docs confirm it: on Free, Pro and Business plans you go straight to the github.com installation flow. Lovable creates a private repository and runs a two-way sync on one branch at a time.
Download codebase - the button at the bottom of the file tree in the code editor - is the Pro-only one. So on a Free account the export exists; it's just spelled "GitHub".
Go to Project settings → Git → GitHub, click Add account, install and authorise the Lovable GitHub app, then Connect. You now have the source. Your domain's DNS points at whatever host you build it on, and Lovable is no longer in the serving path.
Route C: if you already pay for WordPress hosting
There's a collision in Route A that catches people out, and it's worth naming even if you never touch my plugin.
If example.com currently runs a WordPress site, its apex A record points at your WordPress host. Connecting that same apex to Lovable means replacing that record with 185.158.133.1. The moment it propagates, the WordPress site at that domain is gone - front end, /wp-admin, all of it. It's still on the server, it just has no name pointing at it any more. If what you wanted was the Lovable app alongside WordPress, connect a subdomain instead: Lovable accepts app.example.com or blog.example.com the same way, and your apex stays where it is.
But if the plan was for the Lovable site to be the site on that domain, you're about to pay a second hosting bill for a domain your first host already serves. That's the case Parkstatic exists for: a GitHub Action builds the repo from Route B and ships the output into your WordPress install, so WordPress serves the build from the domain it already answers for. No DNS change at all - the A record stays pointed at your host. Builds run on GitHub Actions, free on public repos and 2,000 minutes a month on private ones under GitHub Free, and the plugin licence is $29.99/year or $89.99 once (checked August 2026), against $250-300/year for Pro. The cost comparison and the rebuild-vs-host decision go deeper than I will here.
When to just pay Lovable
I'd rather you spent the $25 than wasted a weekend, so: if you have one site, no existing hosting, and no interest in GitHub, Route A is the right answer. Two DNS records and a Pro subscription beats standing up infrastructure you didn't want. Same conclusion if your app uses Lovable Cloud - a database, auth, file storage, AI features - because moving the front end off Lovable doesn't move any of that with it, and you'll end up paying for both halves. And if your project was created after 13 May 2026 and genuinely needs rendering per request, no static host, mine included, is the right home for it. Static hosting only works for sites that are actually static - that's a real constraint, not a marketing footnote.
Route C only pays off in one specific situation: you're already paying a host, and the Lovable site is the thing that should live on that domain.
If that's you, the deploy guides cover the setup builder by builder, and getting started takes about fifteen minutes end to end.