WebRTC at Scale: Transitioning from Jitsi to LiveKit on Kubernetes

Real-time video communication today relies almost exclusively on WebRTC. However, WebRTC is not a finished product but a set of protocols. How this set is implemented determines whether a platform struggles with 100 concurrent participants or processes thousands of streams simultaneously with stability.

Many providers start with Jitsi. It is open source, well-known, and offers a ready-made interface. However, those who want to operate a video platform as a scalable product—and not just as an internal meeting room—often encounter architectural limits with Jitsi. The transition to LiveKit marks the shift from an application perspective to a true Cloud-Native infrastructure.

Jitsi vs. LiveKit: The Architecture Dilemma

Why Jitsi is Often the First Choice (and the First Dead End)

Jitsi is fantastic for “out-of-the-box” meetings. It comes with everything: video bridge, conference logic, and UI. But this comprehensiveness is precisely the problem when scaling:

• Monolithic Tendencies: The Jitsi Videobridge (JVB) is very resource-intensive. A single conference room is often tied to a specific bridge.
• Complex Orchestration: Scaling Jitsi on Kubernetes is complex because the components are tightly interwoven, and the signal routing was not primarily developed for dynamic pod environments.
• Limited Flexibility: Jitsi aims to be a meeting tool. However, those who want to deeply integrate video features into their own application (e.g., for in-app shopping or complex dashboards) constantly struggle against the predefined design.

Why LiveKit Wins for Platform Operators

LiveKit was developed with a “Cloud-Native lens.” It strictly separates the signaling layer from media transmission and is radically optimized for horizontal scalability.

• True SFU Architecture: As a Selective Forwarding Unit (SFU), LiveKit intelligently forwards video data without recalculating it (as old Multipoint Control Units did). This massively saves CPU.
• Kubernetes-Native: LiveKit servers are stateless pods. When the load increases, Kubernetes simply adds ten more pods. The system automatically distributes participants across the entire cluster.
• Simulcast & Dynacast: LiveKit perfectly juggles bandwidths. A participant in an ICE tunnel automatically receives a stream with a lower bitrate, while the colleague in a fiber-optic office receives 4K—without the server having to re-encode for each participant.

The Strategic Advantage: Decoupling Content and Distribution

By switching to LiveKit on Kubernetes, a hosting provider gains a new level of freedom:

1. Session Isolation: Each customer can work in their own logical area (namespace). A large event from one customer can no longer “consume” the WebRTC resources of another customer.
2. Hybrid Scenarios: LiveKit allows a WebRTC stream (for low latency with speakers) to be seamlessly transitioned into an HLS stream (for thousands of passive viewers). This is the basis for modern “one-to-many” events.
3. Developer Focus: Since LiveKit offers excellent SDKs for all modern frameworks, the customer’s team can focus on the user experience instead of dealing with the intricacies of UDP routing.

Conclusion: Infrastructure That Grows with You

The transition from Jitsi to LiveKit is more than just a software update. It is the decision for an infrastructure component that seamlessly integrates into a modern DevOps ecosystem. Those who view video as a scalable business need tools built for the cloud. LiveKit on Kubernetes offers exactly that: the necessary performance for real-time interaction combined with the infinite scalability of the cluster.

FAQ

Is Jitsi now “worse” than LiveKit? No, it depends on the use case. For a company that simply wants to host its own Zoom alternative, Jitsi is great. For someone building their own video platform for 120 different corporate clients, LiveKit is the better choice due to its scalability and API-first structure.

How complex is the migration from Jitsi to LiveKit? Since LiveKit uses a different API and architecture, frontend integrations need to be adjusted. On the infrastructure side, operating LiveKit under Kubernetes is significantly less maintenance-intensive than a highly available Jitsi setup.

Does LiveKit also support recordings? Yes, via so-called “egress services.” These run as separate pods in the cluster, tap into the stream, and save it as MP4 or send it directly to a CDN. Here, too, the egress service scales independently of the video engine.

Can I operate LiveKit on my own hardware? Absolutely. This is one of the main advantages for digital sovereignty. You operate LiveKit on your own Kubernetes cluster in a European data center and retain full control over all video data.