Does LiveKit support the same room with multiple server nodes?

Thanks for reaching out, Jasmeet. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

is there any way to use this with self hosted with ASG group?

Yes — you can run self‑hosted LiveKit nodes in an AWS Auto Scaling Group (ASG). Key points and what you need to configure: • Redis: Run a highly‑available Redis (e.g., ElastiCache/replica + failover). LiveKit uses Redis for cluster coordination and room metadata. • Graceful shutdown / draining: Ensure instances honor LiveKit’s SIGTERM/SIGINT draining behavior so existing rooms keep running while new joins are rejected. Use ASG lifecycle hooks (or Kubernetes pod termination settings) to allow draining time before instance termination. • Termination grace period: Set a long termination grace period (the Helm chart uses 5 hours as an example) or lifecycle hook timeout so nodes can finish draining. • Metrics & scaling signals: Scale based on CPU, custom metrics (e.g.,

livekit_egress_available

), or active rooms/participants. Expose LiveKit metrics to Prometheus/CloudWatch to drive ASG policies. • Network & ports: Open required UDP/TCP ports (WebRTC media, TURN) and ensure instances have appropriate public/private IPs and security groups. • Egress/Ingress autoscaling: If you use Egress/Ingress services, autoscale them (Kubernetes HPA or ASG) using available-instance metrics. • Avoid NAT/serverless pitfalls: Use instances or pods with predictable networking; public cloud serverless/private clusters can break WebRTC connectivity. If you’d like, I can: • Outline a concrete ASG lifecycle hook + termination sequence for graceful draining, or • Provide recommended CloudWatch/Prometheus metrics and an example ASG scaling policy, or • Show how this maps to the LiveKit Helm chart/pod settings for Kubernetes on AWS. Which of those would you like next? Sources: Self-hosting the Egress Service | LiveKit docs | Self-hosting the Ingress Service | LiveKit docs | Distributed Setup | LiveKit docs | Deploying LiveKit | LiveKit docs | Deploy to Kubernetes | LiveKit docs

I want single room with multiple nodes using ASG

Short answer: not with self‑hosted nodes. In a self‑hosted LiveKit cluster (including nodes launched by an ASG), each room is hosted entirely on one node — it cannot be split across multiple nodes. You can run many nodes behind an ASG and use Redis for cluster coordination, but a single room stays node‑bound. What you can do instead: • Use an ASG with lifecycle hooks so instances drain (LiveKit handles SIGTERM draining) before termination, keeping existing rooms alive while scaling. • Scale capacity by placing different rooms on different nodes and autoscaling based on metrics (CPU, active rooms/participants,

livekit_egress_available

). • If you need a single room distributed across many servers (global edge, massive scale, or cross‑region low latency), use LiveKit Cloud — rooms there are logical sessions spanning multiple servers/regions. Would you like: • a brief ASG lifecycle hook + draining sequence example, or • guidance on moving a workload to LiveKit Cloud for a distributed single-room setup?

What do you mean by node?

By “node” I mean an individual LiveKit server process/instance that can host rooms and participate in the cluster. Key points: • A node can be a VM, container, or Kubernetes pod running the LiveKit server binary. • Each node accepts client connections, manages the media for the rooms it hosts, and reports state/metrics to Redis (or the cluster message bus). • In self‑hosted deployments a single room runs entirely on one node — that node handles the room’s signaling and media routing. • Nodes coordinate via Redis so the cluster can discover available capacity, route new rooms to different nodes, and support features like Egress/Ingress placement. • In ASG/Kubernetes terms, a node = an instance/pod you scale up/down; when terminating, LiveKit nodes drain on SIGTERM to avoid disrupting active rooms. If you want, I can show how a node maps to an ASG instance or a Kubernetes pod in a sample deployment. Which environment are you using?