Self-hosting overview

Self-hosting Beamd is one binary on one server. You point a domain at it, hand out tokens, and your team's tunnels live on your domain — no third party in the data path, no per-seat pricing (Apache-2.0).

What you need

Two things only you can provide:

1. A domain you control (the base_domain, e.g. beam.example.com) — a dedicated domain or a subdomain of one you already run.
2. A DNS provider API token with write access. Beamd uses it for both writing records and issuing wildcard certificates over DNS-01. Cloudflare is the supported provider today — see DNS providers.

Plus a small Linux VM (~$5/month) and ~30–60 minutes the first time, mostly waiting on DNS.

The shape of a deployment

your domain ──DNS──▶ [ VM, public IP ]
                       beamd serve  :443  (TLS + ALPN-demuxed client control)
                          │
                          ▼  one connection per developer
                       developers' laptops

One beamd serve process owns :443, terminates TLS with Let's Encrypt certs, and routes <name>.base_domain to whichever developer registered that name.

Hosting constraint: Beamd terminates its own TLS and shares :443 between public traffic and client control connections, so it needs a raw TCP :443 on a public IP. Any VM works (Hetzner, DigitalOcean, Linode, Vultr, EC2…), as does Fly.io with a dedicated IP. It cannot run behind a TLS-terminating PaaS (Render, Railway, Heroku, Cloud Run, Cloudflare Workers). More in Production.

One edge or two

For personal or trusted-team use, one flat edge is all you need — tunnels live at <name>.base_domain. If you're sharing an edge with developers who shouldn't collide on names, give each a slug so their tunnels are namespaced under <name>.<slug>.base_domain. It's opt-in — see Onboarding developers.

Next

• Setup walkthrough — zero to a working tunnel, step by step.
• Configuration — every beamd.yaml field.
• Production — Docker, systemd, and operating it.