Ports & Access

What a beacon exposes, how players and admins reach it, and how to open the firewall safely.

A beacon makes a deliberate split between what's public (the Minecraft game port, for players) and what's private (the operator dashboard, for you). Understanding this split is the key to running a beacon safely.

What's exposed, and to whom

Service	Port	Published to the host?	Who reaches it
Minecraft	`25565` (`MC_HOST_PORT`)	Yes — public	Players, over the internet
Voice chat	`24454/udp` (`MC_VOICE_HOST_PORT`)	Yes — public	Players, when voice is on
Dashboard (web)	`3000` internally	No	You, through the ingress proxy
Admin RPC	`8080` internally	No	The web app only, on the Compose network
RCON	`25575` internally	No	The admin RPC only

Only the Minecraft port is ever bound to the host. The dashboard is reached through an ingress proxy — either Tailscale or Caddy — so the privileged internals (admin-rpc, RCON, the Docker socket) are never exposed to the network.

Never publish admin-rpc, RCON, or the web port directly

These carry privileged control of your server. The CLI deliberately keeps them on the internal Compose network. Reach the dashboard through the ingress proxy, not by publishing port 3000.

Choose how you reach the dashboard

The Mode step in beacon onboarding picks your ingress. Both are first-class; pick based on who needs in.

Tailscale — private, zero open ports

The dashboard is served on your private tailnet at https://mc.<tailnet>.ts.net. Nothing extra is opened on the host firewall, and there's no TLS to manage. Best for a dashboard only you and trusted admins use. → Set up Tailscale

Custom domain — public HTTPS

A bundled Caddy reverse proxy serves the dashboard at https://your.domain with an automatic Let's Encrypt certificate. Requires inbound TCP 80 and 443. Best when admins need browser access without installing Tailscale. → Set up a custom domain

Opening the firewall

The CLI prints (and can apply) the exact rules for your deployment:

Print the plan, then apply it

beacon firewall              # print the ufw + cloud-firewall plan
beacon firewall --apply --yes  # allow SSH first, then apply via ufw

beacon firewall always includes the game port (TCP) and the voice port (UDP) — and, for a custom-domain deployment, the dashboard's 80/443. The voice port is opened up front so proximity voice chat works the moment you toggle it on, with no second firewall step. It's a benign closed port until then.

To do it by hand on a typical VPS with ufw:

Tailscale mode — game + voice are public

sudo ufw allow OpenSSH
sudo ufw allow 25565/tcp        # Minecraft players
sudo ufw allow 24454/udp        # Simple Voice Chat
sudo ufw enable

Custom-domain mode — also open the dashboard ports

sudo ufw allow 80/tcp           # ACME challenge + HTTP→HTTPS redirect
sudo ufw allow 443/tcp          # dashboard over HTTPS

Most cloud providers also have a separate firewall (security groups / network rules) in their console. Apply the same rules there — both layers must allow the traffic.

Voice needs the UDP port — separately

Voice chat runs over UDP, not the TCP game port. A player who can join the server but can't hear anyone almost always has a closed 24454/udp — open it on both the host firewall and the cloud security group (and any home router).

Docker can bypass host firewalls

Published ports are added to Docker's own iptables chains and can sidestep ufw on some setups. The safe default is to publish only the Minecraft port (which the CLI does) and reach the dashboard over Tailscale, so there's nothing else exposed to scan for.

Giving players a friendly address

Players can always connect to host-ip:25565. To hand them play.example.com instead, point a DNS record at the host — see Custom domain → the game server. For a non-default Minecraft port, an SRV record lets players omit the port entirely.

Multiple beacons on one host

Each beacon created in its own directory gets a unique Minecraft host port (auto-assigned from 25565 upward) and its own ingress. Tailscale mode is the zero-config path here — each beacon gets its own tailnet hostname. With custom domains, only one Caddy stack can own host ports 80/443, so additional public beacons need distinct ports or a single shared front proxy.