Cloud Vs Self Host And Scaling

Operator wants the cheapest 30-participant beta with minimal ops; later expects to scale to 5000-room production.

LiveKit Cloud provides the SFU + edge mesh + SIP + egress as a managed service with regions; self-host gives full control on infrastructure cost but requires k8s, Redis, egress workers, TURN/TLS, observability, and capacity planning. Recommend Cloud for the beta and revisit only if cost or data-res…

Operator runs livekit-server on two nodes behind a load balancer with no shared state. Participants on different nodes can't see each other.

Multi-node self-host requires Redis (or compatible) for room/participant coordination so signaling on any node sees the global room state. Configure redis: {address, password} in the server config on every node. Single-node deployments can skip Redis but cap at the node's capacity.

Self-host: operator runs livekit-server but skips egress worker deployment, then triggers StartRoomCompositeEgress.

Egress runs in a separate worker process (livekit-egress) that consumes egress jobs from Redis. Without an egress worker running, egress requests queue but never execute. Deploy livekit-egress alongside the server and scale it independently — it is CPU/GPU heavy (browser + encoder).