Deployment

PulseBeam is one binary with no external dependencies, so production deployment is mostly about two things: terminating TLS in front of it, and — once you scale past one node — routing each participant to the node that holds their room. This page covers both.

Legacy example, not current SDK onboarding

The pulsebeam-v0.4.6 image below does not provide the endpoints used by the current React SDK. For current local onboarding, use the React quickstart with a published Docker/Podman image. Building from source is only needed for server development. The React SDK requires a compatible signaling endpoint.

--dev uses publicly known development credentials and is for local testing only. Do not expose it through Caddy, a public hostname, or a public network. TLS does not make development credentials safe.

A production service needs a compatible server, your own signing keys, and restricted token issuance. The legacy example and port table below are not a verified production configuration for the current SDK.

Deployment Architectures

1. Single Node (Legacy Example)

This historical example illustrates TLS termination and proxy layout. It is not a supported setup for the current React SDK, and its development server must not be exposed as a public service.

version: "3.8"
services:
  pulsebeam:
    image: ghcr.io/pulsebeamdev/pulsebeam:pulsebeam-v0.4.6
    restart: unless-stopped
    network_mode: "host"
    command:
      - --dev # this sets rtc port to 3478

  caddy:
    image: caddy:2
    restart: unless-stopped
    network_mode: "host"
    volumes:
      - caddy_data:/data
    command:
      - caddy
      - reverse-proxy
      - --from
      - api.example.com # <-- replace this with your domain
      - --to
      - localhost:3000

volumes:
  caddy_data:

2. Multi-Node (Production/High Availability)

For production environments requiring high availability, we recommend replacing Caddy with HAProxy. The reverse proxy must be configured with consistent hashing to ensure each participant connects to the correct node.

In the future, we will remove this limitation by allowing a single room to be handled by multiple nodes.

Port & Firewall Requirements

Port	Protocol	Traffic	Scope	Purpose
443	UDP	Inbound	Public	ICE over UDP
443	TCP	Inbound	Public	ICE over TCP fallback
3000	TCP	Inbound	Internal	Proxied HTTP signaling
6060	TCP	Inbound	Private	Metrics, health checks, and pprof

Note on Networking: network_mode: "host" is required to eliminate the overhead of Container’s network virtualization. For high-throughput real-time traffic, removing NAT indirection is critical for performance and ensures the SFU can correctly discover its public IP for ICE candidate gathering.