The WebRTC SFU landscape in 2026: six projects and what each one actually is

"SFU" gets used for four different kinds of thing, which is why comparing them directly produces an argument instead of a decision. The licenses below were read from each project's own repository on 2026-10-16; check them yourself before you commit, because they change and because a license table is not legal advice.

The table

Project License Written in What it actually is Rough time to a working app
LiveKit Apache-2.0 Go A platform: server, SDKs for most languages, recording and egress, managed cloud Days
Jitsi Meet Apache-2.0 Java + JS A finished conferencing product you rebrand Hours, then you fight its opinions
mediasoup ISC C++ core An SFU library. You write all the signaling Weeks
Janus GPL-3.0 C A plugin gateway, mature, one plugin per use case Weeks
Kurento Apache-2.0 C++ A media server with a pipeline API Weeks
Pion MIT Go A WebRTC library. No SFU is included; you build it Months
Low-Latency Kit Commercial source license Go + Pion A starting application: signaling, SFU, browser clients, reconnect, diagnostics Hours

The four categories, which is the part that matters

The license column decides what you can ship. This column decides your schedule.

1. A library (Pion, mediasoup). You get the media plane and nothing else. Signaling, room state, negotiation, reconnection, TURN wiring, keyframe requests for late joiners and a diagnostics surface are all yours. This is the correct choice when the media plane is the product, and it is the most common way teams accidentally spend two quarters before their first demo.

2. A gateway or server platform (Janus, Kurento, LiveKit). You get a running server and a way to extend it. The work moves from "write an SFU" to "deploy, configure and operate one", which is a different skill and a real one. LiveKit is the strongest current member of this group; Janus is the most battle-worn.

3. A product (Jitsi Meet). You get an application. It is surprisingly good and it has opinions about authentication, rooms, and how the UI works. Forking it is the actual project.

4. A starting application. You get a small, working, complete thing - one publisher to N browser viewers, with the reconnect chain and the diagnostics panel already answered - and you spend your time on your feature instead. The trade is scope: no recording, no egress, no native SDKs, one process.

If you cannot yet say which column your requirements put you in, that is the decision to make first. Everything else is downstream of it.

The license column, and the one that surprises people

This is also why the kit is sold under a commercial source license instead of a copyleft one: it exists to be read, changed and shipped inside closed-source products.

What none of them hand you

Whichever of the six you pick, these are the parts you will still be writing or debugging, and they are the parts that decide whether your product feels finished:

No open-source default answers that list. That gap is the product here: $199 / $499 / $999, one-time, source included, and a seven-day refund so the answer costs you nothing if it is wrong.

Verify before you commit

Each project's license was read from its own repository on 2026-10-16, and the activity and maintenance status of all six changes continuously. Two minutes on the project's repository is worth more than any comparison table, including this one.

Low-Latency Kit is the source package behind the guides on this site: a Go signaling server and Pion SFU, a browser publisher and viewer, the reconnect chain and a diagnostics panel, in one binary with no Redis and no database. Source package and pricing ->

Previous: Managed video APIs vs self-hosting: the break-even, computed -> All comparisons Next: LiveKit vs a single-binary Pion SFU: an honest comparison ->