Your deployed app has an address like myapp-3f9a.vercel.app or 95.217.14.88. You want it to answer at myapp.com. The gap between those two is the entire subject of this page.

Nothing here is difficult. It is unfamiliar, it involves a waiting period that makes people think they broke something, and the vocabulary is worse than the concept.

The idea

is a phone book, and the metaphor holds further than most. You look up a name and get back a number. You do not own the phone book, you own an entry in it, which you rent yearly from a . The phone book is copied to thousands of local branches so that lookups are fast, which is why an edit you make takes time to appear everywhere.

code
  browser types myapp.com
        |
        v
  +-----------------+     "who is myapp.com?"
  |  DNS resolver   | -------------------------+
  |  (your ISP or   |                          v
  |   Cloudflare)   |                  +----------------+
  +-----------------+  <---------------|  nameservers   |
        |              "95.217.14.88"  |  for myapp.com |
        |  cached for the TTL          +----------------+
        v                                      ^
  connects to 95.217.14.88                     |
        |                            you edit records here
        v
  +---------------------+
  |  your host (Vercel, |
  |  Hetzner, Render)   |
  +---------------------+

How it works

You will meet two record types and can ignore the rest until you need email.

  • An A record points a name at a numeric address. myapp.com to 95.217.14.88. Use this when your app runs on a server with a fixed IP address, like a Hetzner box.
  • A CNAME record points a name at another name. www.myapp.com to cname.vercel-dns.com. Use this when your host's address can change, which is normal on managed platforms. The host tells you which value to paste. A CNAME is not allowed on the bare domain itself, only on a subdomain like www, so for myapp.com your host gives you an A record instead, or your DNS provider offers a flattened alias record that behaves like a CNAME at the top of the domain.
  • TTL is how long each copy of the phone book may keep an answer before checking again. Cloudflare's automatic setting is five minutes and Vercel's default is one minute, though older zone files often use an hour. Before you move a domain, lower the TTL and then wait at least as long as the value it had before, or the old answers are still out there.
  • Propagation is just the old answers expiring. Your change was instant at the source. Somebody else's resolver is still holding what it fetched twenty minutes ago.
  • Nameservers decide who answers for your domain. Pointing them at Cloudflare moves the authority, not the records themselves. Cloudflare scans your existing records and copies what it finds, and its own documentation says that scan is not guaranteed to find everything, so anything it missed simply stops existing the moment the switch takes effect.

What to do

  1. Buy the domain at a registrar, then add it to your host. Vercel, Netlify, Render and Railway each print the exact record type and value once the domain is added in their dashboard. Paste those at the registrar, wait, refresh. A .com runs about 10 to 15 EUR a year; watch for a 1 EUR first year that renews at 40, and note that .io and .ai cost several times more.
  2. Check it from outside your own machine. dig @1.1.1.1 myapp.com +short asks a public resolver rather than the one your laptop has been caching in. On Windows use nslookup myapp.com 1.1.1.1, or any web-based DNS checker.
  3. If you put Cloudflare in front, copy your email records before you move nameservers. An MX, SPF, DKIM or DMARC record that does not arrive at the new provider silently stops your mail. Export the zone file if your registrar offers it, or paste every record's value into a text file, since a DKIM key runs to hundreds of characters and cannot be retyped from a screenshot. Add them at Cloudflare, confirm them, then change the nameservers. Afterwards open SSL/TLS and set Full (strict) yourself once your server has its own certificate. The default, Automatic, starts a new domain on the mode called Flexible when it cannot find a certificate on your server, and Flexible gives visitors a padlock while the leg between Cloudflare and your server stays unencrypted.

Where it breaks

The classic wasted afternoon is your browser. It caches DNS answers, and so does your operating system, so the site can be live for everyone else while you still see the old one. Asking a public resolver directly settles it.

A proxied record is worth understanding before you rely on it. Cloudflare answers on your behalf, absorbs traffic floods, caches static files near the visitor and terminates HTTPS at its edge, and the trade is that it now sits in the middle of every request, where a misconfiguration looks exactly like your app being down. It also hides your server's address from DNS, which is not the same as hiding your server. The old address is still in historical DNS records and certificate logs, and it still answers, until you restrict the machine to accept connections only from Cloudflare.

Domains renew automatically until a card expires, and the timeline after that is worth knowing before it happens: your registrar is required to stop the domain resolving within days of the expiry date, so the site goes dark almost immediately, you can usually still buy the name back for a restoration fee for roughly a month after that, and only then can somebody else register it. Some registrars auction it before it drops.