LiveKit vs Jitsi in 2026: Architecture, Scaling and What Each Actually Costs

Both are Apache-2.0 WebRTC selective forwarding units, both are genuinely open source, and both will run a video call for free on a server you own. They are still not interchangeable. Jitsi is a finished conferencing product you can strip down; LiveKit is a media server you build on top of. That difference decides the answer far more reliably than any feature matrix, and the hosted pricing of the two is not even denominated in the same unit. Here is what actually separates them, checked against both projects’ own documentation and pricing pages on 14 September 2026.

The Two Architectures

The row that matters most is the second-to-last one. Jitsi Meet is a working video conferencing application: deploy it and you have a product, then spend your effort removing what you do not want and re-skinning what is left. LiveKit gives you a media server and client SDKs and no interface at all, so you spend your effort building one. Neither is the easier path in general — it depends entirely on whether the app you want looks like a meeting.

The component count differs for the same reason. A production Jitsi install is four or five processes that have to agree with each other: the bridge, Jicofo, Prosody for XMPP signalling, plus jigasi and jibri if you want SIP and recording. LiveKit is one binary, with SIP, ingress and egress as separate services you add only if you need them. Fewer moving parts is real, but so is the fact that Jitsi’s parts have already been assembled for you.

How Each One Scales

Both scale the same way, and the way is less impressive than either project’s marketing suggests: you add servers, and each conference lives on one of them.

The LiveKit documentation is blunt about it. In a distributed deployment “Redis is required as shared data store and message bus”, nodes report their load to Redis so the cluster can route, and “when a new room is created, the node that received this request is able to choose an available node from the cluster to host the room” — with the limit stated plainly: “there are limits to the number of participants in a room since, for now, a room must fit on a single node”. Clients that connect to a different instance are proxied to the right one by a signalling bridge.

Jitsi works to the same shape. “When a new conference starts, Jicofo picks a videobridge and schedules the conference on it”, and “It is easy to scale the video bridges horizontally by adding as many as needed”. The Videobridge README puts the capacity of one bridge at “up to hundreds of conferences per server”.

Bandwidth Is the Engineering Problem in Both

An SFU forwards streams rather than mixing them, so downstream traffic grows with the square of the room: five people each receive four streams, ten people each receive nine. That is the bill and the bottleneck, not CPU.

Both projects attack it the same way. LiveKit’s README lists simulcast and “SVC codecs (VP9, AV1)”, so a participant on a weak connection is sent a lower layer instead of the full stream. Jitsi has simulcast on by default — the config option is disableSimulcast, defaulting to false — and adds channelLastN, which caps how many video streams a client receives at all rather than sending every participant every stream — the option that keeps a large Jitsi room usable.

Neither of these is automatic in the sense that you can ignore it. Whichever you choose, the layout you build — grid of everyone, or one speaker plus thumbnails — decides your bandwidth bill, and you will spend real time tuning it.

Hosted Pricing: Two Incompatible Meters

This is where the comparison stops being about engineering. LiveKit Cloud bills usage. Jitsi as a Service, run by 8x8, bills people. Neither figure converts into the other.

JaaS charges $0.99 per monthly active user over your plan, and meters the extras separately: recording and RTMP streaming at $0.01 a minute, SIP in and out at $0.06 a minute, transcription at $0.06 a minute, outbound PSTN at 1 MAU plus $0.03 a minute. Self-hosting either project costs nothing in licence terms — LiveKit states plainly that the media server and the Agents framework “are both completely open source”, and Jitsi Meet and Videobridge are Apache 2.0.

What That Looks Like on a Real Product

Take a thousand monthly active users and change nothing but how much they meet. Assume 1.5 Mbps per received video stream and no layer downgrade at all, which is the pessimistic end — simulcast and last-N will both pull the real figure down, and how far is the thing you should measure rather than model.

Same thousand people, same platforms, and the cheaper option swaps. That is the whole point: JaaS is flat in usage and steps with headcount, LiveKit Cloud is flat in headcount and climbs with usage. So the question is not which is cheaper — it is which of your two numbers is the one that grows. A product where many people each have one short call a month prices better on LiveKit. A product where a few people live in long calls prices better on JaaS. And in both models the bandwidth term is what eventually forces the self-hosting conversation.

If You Are Building a Voice AI Agent

Then this comparison is already over, and LiveKit wins it by default rather than on merit: LiveKit Agents is an open-source framework for real-time voice and multimodal agents with a meter on LiveKit Cloud, and Jitsi has no equivalent. Jitsi is a conferencing product for humans talking to humans, and nothing in it is aimed at putting a model on the call.

That does not make LiveKit the automatic choice for a voice agent either — managed platforms exist that hide the media layer entirely. We put the two approaches side by side, with current pricing, in VAPI vs LiveKit for AI voice agents, and the architecture of a low-latency agent built on LiveKit in Building Real-Time AI Voice Agents.

Which to Choose

• Jitsi if what you are shipping is a meeting. You get a finished, battle-tested conferencing app, an iframe embed, SIP dial-in and recording that already work, and a hosted tier priced per person. The cost is living with its architecture and its XMPP signalling layer.
• LiveKit if the call is a feature inside something else — a marketplace, a telehealth flow, a classroom, a support console. You are building the interface anyway, so a media server with good SDKs is worth more than an app you have to dismantle.
• LiveKit, without argument, for AI voice agents. It is the only one of the two with a framework for them.
• Neither, if you need a bare routing library rather than a platform. mediasoup (ISC-licensed) is the usual answer there — more control, and correspondingly more of the work is yours.

Is LiveKit better than Jitsi?

Not as a general statement. LiveKit is the better base for embedding real-time audio and video into an application you are designing yourself, and the only one of the two with an AI agent framework. Jitsi is the better choice if you want a working conferencing product on day one rather than a media server and an empty page. Both are Apache 2.0 and both scale by adding servers.

Is Jitsi cheaper than LiveKit?

Self-hosted, both cost the same in licence fees: nothing. Hosted, they are billed on different meters and the answer flips with usage. Jitsi as a Service charges per monthly active user, from $99 for 300 users up to $999 for 3,000. LiveKit Cloud charges for participant minutes and downstream bandwidth, from $50 a month. At a thousand users who each meet briefly once a month, LiveKit Cloud is roughly a fifth of the price; at the same thousand users meeting four times as often in larger rooms, JaaS is cheaper.

Can a single Jitsi or LiveKit conference span multiple servers?

Not in the deployment each project documents as standard. LiveKit states that “for now, a room must fit on a single node” — its own wording, and worth noting that it reads as a current limit rather than a permanent one — and assigns each new room to one node in the cluster; Jicofo likewise “picks a videobridge and schedules the conference on it”. Both scale by running many conferences across many servers, which is the normal requirement. A single room larger than one machine can serve is a specialist problem and needs a specialist answer.

Which is easier to self-host?

LiveKit has fewer processes to keep in step — one media server binary, with SIP, ingress and egress added only if needed — against Jitsi’s bridge, Jicofo, Prosody, and jigasi and jibri for SIP and recording. But Jitsi’s install is the more travelled path, with packages and a large operational community behind it, and it gives you a finished application at the end of it. Fewer components is not the same thing as less work.