Custom domains scare people off for no reason. There are only a few records that matter, a sane order to add them in, and one apex gotcha that trips up everyone the first time. Learn it once and you’ll never think about it again.
The shape of it
Every modern host — Cloudflare Pages, Vercel, Netlify — works the same way: add the domain in the dashboard (it shows “pending”), point a DNS record at the host’s target, and the host provisions the TLS certificate for you, automatically. No nginx, no certbot, no copying cert files around.
The host’s target is just a hostname you point at:
| Host | Point your record at |
|---|---|
| Cloudflare Pages | your-project.pages.dev |
| Vercel | cname.vercel-dns.com |
| Netlify | your-site.netlify.app |
The order that works
- Add the domain in the host dashboard first, so it knows to expect it.
wwwis easy — add aCNAMEfromwwwto the host target above.- The apex is the gotcha. You cannot put a raw
CNAMEon the bare domain (example.com) — it’s against the DNS spec. Use your DNS provider’s CNAME flattening (Cloudflare does this automatically) or an ALIAS / ANAME record instead. - Pick a canonical — redirect
www→ apex or apex →www, not both live. One home, one URL. - Wait for validation, then confirm it resolves over HTTPS before you celebrate. The certificate usually lands within minutes.
The two things people forget
- Apex vs
www— set up both, then redirect one to the other. Skipping this is whyexample.comworks butwww.example.comthrows a cert error (or the reverse). - Email shares the domain — your app on
example.comand email on the same domain coexist fine; just don’t delete theMXrecords while you’re in there.
Bottom line
It’s a 10-minute job, not a DevOps project: add the domain, one CNAME for www,
flattening/ALIAS for the apex, pick a canonical, confirm HTTPS. The certificate is the
host’s problem now — which is exactly how it should be. Got the app but not the domain yet?
That’s the whole deploy path.