Thanks — I’m responding to your question about scaling a VM-based self-hosted LiveKit server. Below are practical, actionable approaches you can use to scale reliably. 1) Horizontal scaling (recommended) • Run multiple LiveKit server instances on separate VMs and connect them to the same message bus (Redis or NATS). Servers coordinate via the message bus so participants and room state are synchronized across nodes. • Add more VMs as load grows to distribute rooms and participants across the cluster. 2) Place a load balancer in front of nodes • Use NGINX, HAProxy, or your cloud provider’s load balancer to terminate TLS and route incoming WebSocket (wss://) connections to backend LiveKit nodes. • Configure the LB for long‑lived WebSocket connections and proper health checks so traffic isn’t sent to unhealthy nodes. 3) Message bus and state synchronization • Use a single Redis or NATS instance (prefer clustered/HA mode for production). All LiveKit nodes must point to that same backend so signaling and room state work across the cluster. 4) Ports and network considerations • Ensure these ports are reachable as needed: ◦ TCP 443 — client WebSocket signaling (wss) ◦ TCP 7881 — health checks / metrics ◦ UDP 7882 — WebRTC media (TURN / media traffic) ◦ TCP 7880/other ports only if you use SIP or other features • Use TURN servers for NAT traversal when P2P isn’t possible. • For global user bases, deploy regional LiveKit nodes to reduce latency and keep users near a node. 5) Monitoring and autoscaling • Monitor CPU, memory, connection count, and media throughput on each node (LiveKit exposes metrics you can scrape). • Use Prometheus + Grafana for metrics and alerts. • Implement autoscaling (e.g., Autoscaling Groups, VM scale sets, or your orchestration tooling) to add/remove VMs based on metrics like active connections or CPU. 6) High availability for Redis/NATS and TURN • Run Redis/NATS in HA/clustered mode so the message bus isn’t a single point of failure. • Ensure TURN infrastructure is resilient (multiple TURN servers, ideally in each region you serve). 7) Troubleshooting tips • Verify LB health checks and WebSocket sticky settings if clients lose connections or get unevenly distributed. • Check LiveKit metrics and node logs when you add nodes to confirm they’re registering with the message bus and handling participants. • Confirm required ports (especially UDP for media) are open between clients and nodes/turn servers. If you want, I can help with next steps specific to your environment: • Recommend load balancer config snippets (NGINX or HAProxy) for wss and sticky sessions. • Walk through sample LiveKit server configuration that points to a shared Redis/NATS. • Suggest monitoring metrics and thresholds to trigger autoscaling. Which of those would you like to start with, and can you share whether you use Redis or NATS and which load balancer (or cloud provider) you’re using? Sources: How much can LiveKit scale? | LiveKit | Running LiveKit on AWS | Running LiveKit on AWS | How We Built a Globally Distributed WebRTC Mesh Network