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 wants SIP telephony but only deployed livekit-server.

SIP is a separate worker (livekit-sip) that registers with the server and handles SIP signaling/media to carriers. Deploy with the SIP listener exposed to the trunk provider over a stable IP/UDP. Do not expose SIP directly from the SFU node — separate concerns and security boundaries.