Burrowee Docs

Appearance

Custom domains ​

The Custom domains page (labelled ACM — automated certificate management) is where your own hostnames meet your gateways. Two sections: a Verified domains wildcard pool at the top, and the per-hostname Custom domains list below. Custom domains require a paid plan; wildcard domains 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.

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 domains — the wildcard pool ​

Verifying every hostname separately gets old. Instead, verify an apex once: + Add domain, enter example.com, add the one CNAME record, Verify. 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. Remove releases an apex — but is blocked while subdomains still use its wildcard certificate; the row lists which hostnames to remove first.

Custom domains — per hostname ​

The lower section lists every attached hostname, with the gateway and service it points at. + Add domain 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.

Remove detaches 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.