Pointed here. Still yours.

• You

  The domain name itself

  Registered in your name, at whichever registrar you chose, renewed on whatever cycle you set up there. That relationship never moves to us.

• CustomHosted

  The DNS zone and its records

  Once a domain points here, the records inside it are kept correct as the platform changes underneath — added, updated, and audited without a spreadsheet only one person remembers how to edit.

• CustomHosted

  The TLS certificate

  Issued before the cutover and renewed ahead of every expiry, on a standing schedule — see the lifecycle below.

• Delegate the nameservers

  You change

  One setting at your registrar — the nameservers, pointed at ours.

  We manage after

  Every record underneath from that point on: the zone lives here, changes are made here, and nothing needs a second login to keep in sync.

  Right call when

  Most accounts. It's the simplest path once you've decided a domain lives here.

• Keep DNS where it is

  You change

  Add the specific records we ask for at whichever DNS provider you already use.

  We manage after

  Only what those records point at — the zone itself, and everything else in it, stays under whoever already runs your DNS.

  Right call when

  You run DNS for other domains from one place already, or a records-only handoff was part of the deal your registrar or IT team already has in place.

1. 1

   Issued before the cutover

   A certificate is requested and issued ahead of the switch, so HTTPS is already live the moment traffic moves — not something set up afterward once someone notices it's missing.

2. 2

   Renewed ahead of expiry

   Renewal runs on a standing schedule, well before the expiry date — the same watch signal /monitoring lists under certificates.

3. 3

   HTTPS by default

   Every property gets one, apex and www alike. There is no unencrypted version of the site actually reachable.

4. 4

   Apex, www, and the http:// redirect

   Whichever of the apex or www variant isn't your canonical address forwards to the one that is, and the plain http:// address forwards to https:// — both on by default.

5. 5

   If a renewal ever fails

   Escalated straight to a human rather than left to lapse quietly — the same rule the rest of the watch list follows for anything that doesn't fix itself.

1. 1

   TTLs lowered ahead of time

   Shortens how long resolvers hold onto the old answer, before anything about the records themselves actually changes.

2. 2

   Rehearsed against the standing copy

   Checked against a working copy of the site or app first — the switch itself isn't the first time it's been tried.

3. 3

   The old host keeps serving through the window

   Nothing is torn down until traffic has actually moved — a visitor whose resolver is slow to catch up still reaches a working site, just from wherever it was before.

4. 4

   Rollback is the same move, reversed

   Pointing the records back is not a special procedure — it is this same change, run the other direction, on the same propagation timeline.

The full rule set behind the redirect row above — every URL rule, the cache, and the response headers — is on Delivery. Read how a change gets briefed in the first place on Brief a change, and how it ships on The Loop.

• We're not a registrar

  Registration and its renewal stay between you and whoever you registered the domain with. No record we manage can save a domain that lapses at the registrar.

• We route mail, we don't run mailboxes

  Mail records are pointed at whatever provider you use and carried over untouched. Hosting the inboxes themselves is a separate service we do not provide.

• DNS-level geo-routing or traffic-splitting is a custom quote

  Standard plans point a domain at one place. Splitting traffic by region or condition at the DNS layer is a real thing we can build — just not something a standard plan includes by default.

• Propagation depends on resolvers nobody controls

  Lowering TTLs ahead of a change shrinks the window, but a resolver that ignores TTLs and caches longer than asked is outside anyone's control, ours included.

• Transfer locks and auth codes live at your registrar

  Moving a domain to a different registrar entirely needs a code only your registrar can issue — that step never runs through us.

1. 01Will my email break when my domain points here?

   No, for mail addressed to your domain: your MX records and the TXT records behind SPF, DKIM, and DMARC are carried over exactly as they stood at your previous DNS host — see the record sheet above. That is the inbound half. If your app also sends mail outward — a password reset, a receipt — see Email for the records that add alongside these, untouched.

2. 02How long does the propagation window take?

   It depends on resolvers we don't control, so there's no fixed figure to promise. What we do control: TTLs are lowered ahead of the switch to shrink the window, the change is rehearsed against a standing copy first, and the old host keeps serving until traffic has actually moved.

3. 03Do I lose control of my domain?

   No. Registration and its renewal stay yours at your registrar the whole time — see the ownership table above. What moves to us is the zone underneath it and the certificate, and reverting either is the same change run in the other direction.

4. 04Can I keep DNS somewhere else instead of delegating?

   Yes — add the specific records we ask for at whichever DNS provider you already use, rather than pointing the nameservers here. You keep running DNS; we manage only what those records point at.

5. 05What happens if a certificate renewal fails?

   It's escalated straight to a human rather than left to lapse quietly. Renewal itself starts well ahead of the expiry date specifically so there's room to catch a failure before it becomes visible.

6. 06Can you split traffic by region at the DNS level?

   Not as part of a standard plan — DNS-level geo-routing or traffic-splitting is a custom quote. A standard plan points your domain at one place.

7. 07What does adding a subdomain or a second domain cost?

   A subdomain is a DNS record change, so it costs nothing extra — DNS management is part of every plan. Pointing a whole second domain at a new site is priced as additional static site, another site on the same account, same edge network.

8. 08What about a redirect map or a canonical URL change?

   That's application routing, not a DNS record, so it goes through the same loop as any other code change: briefed under the Agentic iteration — CodeHerder add-on, an agent opens the pull request, a human merges it, and the same pipeline redeploys. See Delivery for the full rule set — every URL rule, the cache, and the response headers.

9. 09Who'd be doing this if I ran DNS and certificates myself?

   You would. The hours ledger prices "renewing tls certificates" at around 0.5 hours per certificate renewal — here, that row moves to us as part of every plan.