Networking and ports

Port reference

Only the panel and the Core API need to be reachable from a browser. Everything else can stay on the internal network.

What actually has to be open

Self-hosting with ip_port routing: forward the ports in PORT_RANGE that your servers use, plus whatever you expose the panel and API on. Each Minecraft server takes one port.

Bring your own node: nothing. The node dials outward over an encrypted tunnel and never accepts an inbound connection. That is the entire point of it.

Publish the Beam LAN port if you can

25523 is the direct client-to-node fast path for file transfers. Publish it on your local network and Beam uses it, so transfers run at LAN speed.

Leave it unpublished and Beam takes the next transport it has: on a self-hosted install that is a pinned connection to the node's own address, and with the managed edge it is the relay. Both work; both are slower than the LAN path. Nothing breaks either way.

It is not enough for the port to be documented: it has to be in the environment: block of your compose file to reach the container. See Configuration.

DNS

A single-IP install needs very little: one record for the panel, one for the API.

With the managed edge you point a CNAME at the address the panel gives you, and that is the whole setup. No SRV record, no port in the address, always :25565.

Watch out for wildcards. A *.example.com record absorbs specific names you later need, so create the specific records explicitly rather than relying on the wildcard to cover them.

Nothing in a self-hosted install writes DNS for you, and nothing needs to. Nodes take no record at all - the panel hands the Beam app the node's addresses directly, with a pinned certificate, so there is no name to resolve. The panel and the API are yours to point wherever your reverse proxy listens.

The records that are written automatically belong to the gateway: the regional edge wildcards and the beam relay address. Those are written by the gateway Hub, which holds the provider credential and reconciles the records against the edges and relays that are actually online. Running the platform alongside it, you configure all of that under Settings -> Gateway in the panel and never open the Hub's own interface, which is off by default: the panel forwards the form and stores nothing, so there is still one credential in one place. It supports thirteen DNS providers through libdns - Cloudflare, Hetzner, deSEC, Porkbun, Route 53 and the rest - and refuses to touch any name outside the zones you list, so the credential's blast radius is something you set rather than something you hope for.

Certificates

Two of them, and only one is yours to think about.

The panel and the API are terminated by your reverse proxy, so their certificate is whatever that proxy already does - Traefik, Caddy and Nginx Proxy Manager all get one from Let's Encrypt without being asked. See Reverse proxy and TLS.

The beam relay is the exception, and only exists if you run the gateway. Its client port is a raw TLS stream on its own port rather than HTTPS on 443, so no reverse proxy is in front of it, and the Beam desktop app verifies its certificate chain and hostname like a browser would. It therefore needs a real, CA-issued certificate for the name clients dial.

You have four ways to get one, and the first is the one to use:

1. Let the gateway do it. If your DNS provider is one of the thirteen it supports, switch Certificates on: it obtains the certificate over the DNS-01 challenge with the same credential it already writes records with, renews it, and hands it to every relay. Nothing to mount, nothing to restart.

   Running the platform alongside the gateway, that switch is in the panel under Settings -> Gateway, together with the provider token. Running the gateway on its own, it is on the Hub's own DNS page.

2. Mount the one your proxy already has. If Traefik or Nginx Proxy Manager holds a certificate covering the name, point TLS_CERT_PATH and TLS_KEY_PATH at the files. This always wins over the Hub.

3. Run certbot on the relay host and mount the result the same way. This is the HTTP-01 route, and it is the answer when your DNS provider is not supported.

4. Run no gateway at all, in which case there is no relay, no name, and nothing to certify. The panel hands the Beam app the node's address directly.

Only DNS-01 is offered by the Hub itself, and that is forced by the deployment rather than chosen: several relays in a region deliberately share one name, so an HTTP-01 challenge for it would land on whichever relay DNS happened to pick.

A relay with no certificate yet still starts and still serves - on a self-signed one, which the Beam app will refuse until the real one arrives. It never blocks its own boot waiting.

Server-Sent Events

Console output, status and stats arrive as Server-Sent Events. A proxy that buffers responses makes the panel look frozen while everything behind it is fine. See Reverse proxy for the settings.