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   |
        |               "76.76.21.21"  |  for myapp.com |
        |  cached for the TTL          +----------------+
        v                                      ^
  connects to 76.76.21.21                      |
        |                            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.
  • TTL is how long each copy of the phone book may keep an answer before checking again. One hour is a common default. Lower it to a few minutes a day before you plan to move a domain.
  • 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 holds the records. Pointing your domain's nameservers at Cloudflare moves the whole record set there. That is the switch that matters, and it is the one that takes longest to take effect.

What to do

  1. Buy the domain, then set the records your host tells you to set. Vercel, Netlify, Render and Railway all print the exact record type and value in their dashboard when you add a domain. Paste them, wait, refresh.
  2. Check it from outside your own browser. Run dig myapp.com +short in your terminal, which asks DNS directly and skips every cache your browser might be holding.
  3. Consider putting Cloudflare in front once it works. Move your nameservers to Cloudflare, then switch a record to proxied. Cloudflare then answers on your behalf: it hides your server's real address, absorbs traffic floods, caches static files near the visitor, and gives you a certificate so the site is served over HTTPS. The trade is that Cloudflare now sits in the middle of every request, and a misconfiguration there looks exactly like your app being down.

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. dig from a different network settles it.

Two more. Domains renew automatically until a card expires, and a lapsed domain can be bought by somebody else within weeks. And email records are a separate world: MX, SPF, DKIM and DMARC records live alongside your A record, and moving your nameservers without copying them across is how people silently stop receiving mail.