Custom domains

The Custom domains page (labelled ACM — automated certificate management) is where your own hostnames meet your gateways. It's a single apex-grouped list — every hostname nests under its apex (app.example.com and staging.example.com both sit under example.com), split across Personal and Team tabs. A group is either verified (the apex is in your wildcard pool, so a *.example.com cert covers every subdomain) or synthetic (subdomains exist but the apex was never verified, each carrying its own per-host cert). Custom domains require a paid plan; wildcard apexes require Pro or Team.

The console owns DNS verification and certificates end to end — you never handle certificate files. Every certificate is issued via DNS-01: you add one CNAME record at your DNS provider, the console proves control and issues, and the relays serve the certificate for you.

A team gateway's custom domains and verified apexes come out of the team's own pool, separate from your personal one — the Team tab shows them.

The CNAME recipe

Whenever a certificate needs DNS proof, the console shows a Setup recipe with two copy fields:

• the CNAME record name — a _acme-challenge… name under your domain,
• the target — a verification hostname the console controls.

Add that record at your DNS provider, then press Verify on the row. Issuance takes about a minute after DNS propagates. Leave the record in place — it is reused for renewals.

Each row carries a TLS badge showing the certificate lifecycle: DNS setup needed (record not verified yet) → verifying… → TLS ✓ (issued; hover for the expiry date). failed means the last attempt did not complete — fix the DNS record and press Verify again.

Verified apexes — the wildcard pool

Verifying every hostname separately gets old. Instead, verify an apex once: add the one CNAME record and Verify on its group header (a synthetic group offers Verify apex to upgrade it in place). That issues a *.example.com wildcard certificate — and from then on, any subdomain (app.example.com, staging.example.com, …) attaches instantly, with no DNS step at all.

Your plan caps how many apexes you can hold in the pool; the count (N / M apex domains on Personal, a plain count on Team) sits at the top of the list. A verified apex group's header carries these actions:

• Setup — reveal the apex's CNAME recipe again.
• Move… — transfer the apex to another tenant you manage: your Personal account, or a team you own/manage. One-way (the destination must be under its own apex cap), and it takes the wildcard cert with it.
• Share — the chip (showing a tenant count, or "Share" when unshared) opens a panel to share the apex into other teams you administer, so a team gateway can reuse the wildcard without re-verifying. Many-to-many; each shared tenant sees the apex read-only. A shared apex shows on both the owner's and the sharee's tabs.
• Resync — push the apex's already-issued certs and routes out to the current relay set right now (including bridge-reachable edges). Useful after you add a relay or edge that should start serving the domain.
• Remove — release the apex. Blocked while subdomains still use its wildcard certificate; the warning lists which hostnames to detach first.

Subdomain rows — per hostname

Each group's rows are its attached hostnames, showing the gateway and service each points at plus, underneath, a chip per synced relay currently serving that hostname (an edge-kind relay is tagged as such — this is how you confirm the domain is riding your own edge rather than the shared fleet). Each row's readiness comes from its own certificate — a subdomain attached before its apex was verified keeps its per-host cert; a ready (via *.apex) badge is cosmetic, never a substitute for the row's own cert.

+ Add custom domain (page header) or + Add subdomain (on a group) asks for:

• Gateway — which gateway serves it (pre-filled when you open the dialog from a target row).
• Hostname — e.g. app.example.com.
• Service — the target name on that gateway.
• Certificate — if the hostname's apex is already in your wildcard pool, you can reuse the wildcard (instant, no DNS step) or issue a fresh per-host certificate (one DNS round-trip). The wildcard is the default when available.
• Relay — Auto serves the domain on every relay the gateway connects through; or pin it to one specific relay (say, your own edge relay so the traffic never touches the shared fleet).

If a certificate for the hostname was already issued, the domain is live immediately ("TLS already active ✓"); otherwise you get the CNAME recipe and a Verify button.

Detach removes a hostname — it stops serving immediately. The certificate is kept, so re-attaching the same hostname later (or moving it to another target) does not repeat the DNS dance.

Where domains attach

This page is the domain inventory; the binding lives on targets. Each target row on a gateway's detail page shows its attached domains and is where you assign, move, make public, or detach them — including the auto-assigned random *.burrowee.net names, which need no setup at all.