Add the domain to the project in its settings first. Until the project knows about it, a record at your registrar points at a deployment that won’t answer for that name.

Then create the record the settings page asks for. Which one depends on the name:

• The bare domain, like example.com, takes an A record to the address shown beside it. Most registrars won’t accept a CNAME at the root.
• A subdomain, like www.example.com or app.example.com, takes a CNAME to the hostname shown, which follows the deployment if its address ever changes.

Once the record resolves, the domain turns green in settings and starts serving the latest production deployment. Preview deployments keep their own URLs and aren’t affected.

Usually a few minutes. Settings checks the record every so often and turns green as soon as it sees the right answer.

What slows it down is caching. Resolvers hold on to the old record until its TTL runs out, and some registrars default to a TTL of a day or more. If you’re planning a move, lower the TTL to five minutes the day before, and the switch itself will be quick.

To see what the rest of the world sees, ask a public resolver directly with dig example.com @1.1.1.1. If that returns the new address and your own machine doesn’t, it’s your local cache, and it will catch up on its own.

Yes. A certificate is issued as soon as the record resolves, usually within a minute, and it covers the exact name you added. Adding both www and the bare domain gets you one for each.

Renewal starts thirty days before expiry and needs nothing from you. It only fails if the record stops pointing here, for example after a registrar change that didn’t bring the records across.

If that happens, you’ll get an email two weeks before the certificate lapses, naming the record it expected to find, so there’s time to put it back.

They keep working. Every deployment is immutable and keeps its own URL, so a link you shared last week still opens exactly the build it pointed to, even after the domain moves.

Only the domain moves forward. It always serves the latest production deployment, so anyone on example.com sees a release as soon as it’s promoted, while reviewers on a preview link keep the version they were asked to look at.

If an old preview shouldn’t be reachable anymore, delete that deployment, or turn on deployment protection so every preview asks for a sign-in first.

You can do it here, and it’s the better place for it. A registrar’s redirect often can’t serve HTTPS, so anyone who types https://www gets a certificate warning before they’re sent on.

1. Add both example.com and www.example.com to the project.
2. Open www.example.com in settings and set it to redirect to example.com.
3. Choose a permanent redirect, a 308, so browsers and search engines remember it.

Paths and query strings carry across, so www.example.com/pricing?plan=pro lands on example.com/pricing?plan=pro rather than on the home page.

Nothing here needs to change. The project doesn’t care who your registrar is, only what your records say.

Before the transfer, copy every record to the new registrar, not just the A and the CNAME. Mail records are the ones people forget, and email stops quietly when they go missing. Check them against the old registrar’s zone one by one before you go any further.

Change the nameservers last.