Wildcard Domain & DNS
Every tunnel URL is a name under your Broch hostname, such as my-app-abcdef.broch.{your-domain}, so Broch needs a wildcard DNS record, *.broch.{your-domain}, pointing at your server.
You need to own a domain and be able to create DNS records on it.
Choosing a Hostname
Section titled “Choosing a Hostname”Pick a subdomain of a domain you control: {subdomain}.{your-domain}, with every tunnel under *.{subdomain}.{your-domain}. These docs use broch, the default the deployment templates suggest. tunnels or dev-broch work just as well.
Set it as API__WILDCARDHOSTNAME (BROCH_WILDCARD_HOSTNAME in a Docker Compose .env):
API__WILDCARDHOSTNAME=broch.{your-domain}Choose it before you activate your license: the hostname is bound into your license token at activation. See Licensing & Billing.
DNS Records
Section titled “DNS Records”Create two records in your DNS provider, both pointing at your server: one for the hostname itself (broch.{your-domain} — the dashboard, API, and health endpoints) and one wildcard (*.broch.{your-domain} — the tunnel URLs). A wildcard record does not cover its own bare name.
| Record type | Name | Value |
|---|---|---|
| A | broch.{your-domain} and *.broch.{your-domain} |
Your server’s IP address |
| CNAME | broch.{your-domain} and *.broch.{your-domain} |
Your server’s DNS name (e.g., ALB hostname on AWS) |
Use CNAMEs when the server’s IP address can change (e.g., an AWS ALB). Use A records when the IP is stable (e.g., a reserved IP on DigitalOcean, a static IP on a VM, or a Container Apps environment’s static IP).
These records are for resolution, not the certificate. They only make broch.{your-domain} and name.broch.{your-domain} resolve to your server. The TLS certificate is separate — with the recommended Caddy DNS-01 setup it’s issued and renewed automatically and you create no certificate records by hand (see TLS Certificates). You need a fixed set of records, never one per tunnel.
On Cloudflare, keep these records DNS-only (grey cloud), not proxied (orange cloud) — the proxy breaks Caddy’s TLS and the DNS-01 challenge and masks client IPs.
Per-platform DNS setup
Section titled “Per-platform DNS setup”Docker Compose (any Linux host)
Create both A records pointing at your server’s public IP:
broch.{your-domain} → <public-ip>*.broch.{your-domain} → <public-ip>Or let the bundled Caddy create both records and keep them pointed at the host’s public IP, with the DNS credential it already uses for the certificate. It’s off by default: in your variant’s dynamic-dns.caddy, uncomment the dynamic_dns block, set its provider to the one in tls.caddy and its zone and names to yours (Route 53 wants the zone with a trailing dot), then run docker compose restart caddy if the stack is already up. Leave it off when a load balancer or NAT sits in front of the host, because clients must resolve to that address instead. with-postgres-byo-cert has no DNS credential, so its records are always yours to create.
Check that both names resolve to your IP (test stands in for any tunnel name):
nslookup broch.{your-domain}nslookup test.broch.{your-domain}DigitalOcean (Terraform)
After terraform apply, the output shows the reserved IP. Create both A records:
broch.{your-domain} → <reserved-ip> (from the output)*.broch.{your-domain} → <reserved-ip>Azure Container Apps (beta)
After terraform apply, create an A record to the environment’s static IP, a TXT record that proves ownership, and a wildcard record for tunnel subdomains:
broch.{your-domain} A <environment static IP, what the container_app_fqdn output resolves to>asuid.broch.{your-domain} TXT <container_app_verification_id output>*.broch.{your-domain} A or CNAME whatever serves your wildcard cert (the environment, Front Door, or Application Gateway)The Azure Container Apps guide has the commands that look up both values and bind the domain.
AWS ECS Fargate (beta)
The Terraform module creates Route 53 alias records for the hostname and its wildcard, pointing at the ALB, in your hosted zone. Nothing to create by hand.
Propagation
Section titled “Propagation”DNS changes take time to propagate — typically minutes, but up to 48 hours depending on your provider and TTL settings. Use a low TTL (300 seconds) while setting up and testing, then raise it once confirmed working.
Next: TLS Certificates, step 3 of the self-managed checklist.