You have a site live at something like sunrise-bakery.bldeploy.run. It works,
it's fast, and you can send it to people. But you own sunrisebakery.co.uk, and
that's the one on your business cards.
Connecting the two takes about five minutes of actual work and then a wait. The wait is the part that makes people think they've broken something, so it's worth knowing what's happening.
What a domain actually is
A domain name is a lookup table entry. That's genuinely all.
When someone types your domain, their computer asks a directory service "where does this live?" and gets back an address. Your registrar — GoDaddy, Namecheap, Cloudflare, whoever you paid — controls what that directory says.
So "connecting a domain" means editing one row in that table. Nothing moves. No files are copied. You are changing a signpost.
The record you need
You want a CNAME record, which says "this name is an alias for that name".
At your registrar's DNS settings, add:
Type: CNAME
Name: www
Value: fallback.bldeploy.run
That's it. www.yoursite.com now points at us, and we work out which of your
sites to serve from the name the visitor typed.
Ask your AI to add the domain and it will give you the exact records to paste, including anything specific to your setup. It reads them back from us rather than guessing.
The bare domain problem
Here's where it gets annoying, and it's not our fault or your registrar's — it's a limitation baked into DNS from the 1980s.
You can CNAME www.yoursite.com. You often cannot CNAME yoursite.com with
nothing in front. The standard doesn't allow a CNAME at the root of a domain
alongside the other records that have to live there.
Registrars work around this with a feature called ALIAS, ANAME, or "CNAME flattening", depending on who you ask. Same idea, different name:
- Cloudflare — CNAME flattening, on by default. Just add the CNAME.
- Namecheap — ALIAS record.
- DNSimple, DNSMadeEasy — ALIAS.
- Route 53 — Alias record.
- GoDaddy — historically no support. Forward the bare domain to
wwwinstead, which they do offer.
If yours doesn't support it, use www as your real address and set up a
forward from the bare domain. Plenty of large sites do exactly this.
Then you wait
This is the part worth explaining, because it looks like failure.
DNS results are cached all over the internet — by your router, your ISP, your computer. When you add a record, those caches don't know. They keep serving the old answer until it expires.
How long depends on the TTL on your old records, which is often an hour and sometimes a day. During that window your site may work for you and not for a friend, or work on your phone and not your laptop. That's caching, not a bug.
Two things help:
- Lower the TTL before you switch, if you're planning ahead. Drop it to 300 seconds a day early and the change lands in five minutes instead of an hour.
- Don't keep changing the record while you wait. Every edit restarts the clock and makes it harder to tell what's actually live.
Then the certificate
Once the name resolves to us, one more thing happens automatically: we get an HTTPS certificate for your domain so browsers don't warn people away.
This needs the DNS to be working first — the certificate authority checks that you really control the name. So there's a short period where the domain resolves but HTTPS isn't ready, and the site may not load.
Your dashboard shows both states separately, because they fail for different reasons:
- Name: pending — DNS hasn't propagated, or the record is wrong. Your problem to fix.
- Certificate: pending — DNS is fine, the certificate is being issued. Nothing to do but wait, usually minutes.
A domain works when both say active. If the name is active and the certificate has been pending for more than an hour, something is wrong — that's worth asking about rather than waiting on.
What plan you need
Custom domains start on Starter, which is $4.99 a month or $49 a year and includes one. Pro includes ten.
Free sites keep their bldeploy.run address, which works perfectly well and has
HTTPS. If you're publishing a personal page, you may never want anything else.
Things that trip people up
You still have to renew the domain. We serve the site; your registrar owns the name. If it lapses, the site is unreachable no matter what we do.
Email is separate. If you have email on that domain, it uses MX records,
which have nothing to do with the CNAME you just added. Adding a CNAME for
www doesn't touch your email. Deleting records you don't recognise might.
One domain, one site. Pointing the same name at two sites isn't a thing. If
you want shop.yoursite.com and blog.yoursite.com, those are two records
pointing at two projects.
Test in a private window. Your own browser caches aggressively, and half the "it's still not working" reports are a browser showing you something from twenty minutes ago.
The short version
Add a CNAME for www pointing at fallback.bldeploy.run. Wait for it to
propagate. Wait a bit more for the certificate. Check in a private window.
The five minutes of work are easy. The waiting is the part you have to be told about, or it looks broken.