Broadcast Box

Last reviewed Sep 13, 2026 · 759 words

An HLS stream from Owncast or Twitch arrives 5 to 30 seconds after it happens. A Broadcast Box stream arrives in well under 1 second, usually 200 to 500 ms, because it never touches HLS: OBS pushes WebRTC to the server over WHIP and every viewer pulls WebRTC back over WHEP. That is the entire product, a 2,307-star Go binary from the Glimesh project, and it is excellent at it. It also has no chat, no recording, no VOD library, no user accounts, and a bandwidth model where every viewer costs you the full stream bitrate. Know that going in and it will not disappoint.

OBS speaks WHIP natively now

WHIP is the standardised way to push a WebRTC stream to a server, and OBS has shipped it as a built-in output since version 30. In OBS, set the service to WHIP, the server to https://stream.example.com/api/whip, and the bearer token to whatever stream key you invent; Broadcast Box treats the key as the stream's name, so family-movie-night becomes the path viewers open. Codec choice matters more than usual: H.264 works everywhere, AV1 and VP9 give better quality per bit but only on browsers and hardware that decode them, and there is no server-side transcoding to paper over a mismatch.

Viewers open https://stream.example.com/family-movie-night and the built-in page plays via WHEP. Nothing to install on their side beyond a current browser.

Networking is the part that fails

WebRTC wants UDP, and that is where every failed Broadcast Box install I have looked at went wrong. The server multiplexes all media on a single UDP port, 8080 by default, and needs to advertise a reachable public IP:

docker run -d --name broadcast-box \
  --network host \
  -e HTTP_ADDRESS=:8080 \
  -e UDP_MUX_PORT=8080 \
  -e NAT_1_TO_1_IP=203.0.113.10 \
  -e INCLUDE_PUBLIC_IP_IN_NAT_1_TO_1_IP=true \
  --restart unless-stopped \
  seaduboi/broadcast-box

Host networking sidesteps Docker's UDP port mapping problems. Forward UDP 8080 on your router, put the HTTP side behind a reverse proxy for TLS (browsers require HTTPS for WebRTC media, so this is not optional), and leave the UDP port pointing straight at the box. Behind CGNAT or a VPS with a NAT, NAT_1_TO_1_IP is what makes the ICE candidates valid; without it, connections negotiate and then silently produce no video. Memory sits around 100 to 250 MB regardless of viewer count; CPU is minimal because nothing is transcoded.

Bandwidth is the real cost

There is no CDN and no HLS segment caching, so the server forwards the full bitrate to each viewer individually. A 6 Mbps stream with 20 viewers is 120 Mbps of upstream from wherever the server lives. On a home connection with 40 Mbps up, that caps you at about 6 viewers before quality collapses; on a cheap VPS with a 1 Gbps port, 100 viewers is comfortable. Simulcast is supported, so OBS can send 3 quality layers and viewers can pick one, which helps the client side but multiplies the ingest.

This is why it fits watch parties, remote camera monitoring, low-latency game night, and internal company broadcasts, and why it does not fit a public channel with an unknown audience.

Owncast and MediaMTX cover what it leaves out

Owncast is the full self-hosted Twitch replacement: RTMP ingest, HLS with an adaptive ladder, chat with moderation, a customisable page, and Fediverse integration, at the cost of that 5-plus-second delay. MediaMTX is the swiss army knife: it speaks RTMP, RTSP, SRT, HLS, and WHIP and WHEP all at once, records to disk, and will happily do the Broadcast Box job plus everything else, with a config file that reflects that breadth. Broadcast Box wins on being the simplest possible path to sub-second browser playback; the rest of the media server category covers the recorded-video side that none of these three handles.

Broadcast Box is independent of Owncast, and the two are alternatives rather than components of each other.

What I'd do

Run Broadcast Box on a VPS with a real public IP and host networking, H.264 from OBS, one stream key per event, behind Caddy for TLS. Use it for anything where latency matters more than reach. For a public stream with chat and a landing page, run Owncast instead, and if you need both recording and low latency from the same box, MediaMTX is the one that does it, with more config to write.