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
- MIT (Pion) asks almost nothing of you.
- ISC (mediasoup) is functionally equivalent to MIT.
- Apache-2.0 (LiveKit, Jitsi, Kurento) adds an explicit patent grant, which is why companies prefer it to MIT.
- GPL-3.0 (Janus) is fine when you run the server yourself for your own users, which is what most people do. It becomes a real question the moment you distribute it inside a product, and it is a question for your lawyer rather than for a comparison page.
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:
- The reconnect chain. ICE restart first, full rejoin as a fallback, with backoff and an epoch counter so a stale socket cannot re-attach to a live session. The three-tier recovery ladder is the long version.
- Freeze detection. A tile can report a healthy ICE state while showing a still frame. Frames, not connection state, are the signal, and nothing in any of the six projects will tell you that for free.
- Slow-joiner handling. A viewer that joins late waits for a keyframe it cannot ask for unless you request one upstream with the publisher's SSRC.
- Fan-out correctness. One negotiation per viewer, RTCP relayed upstream, batched offers rather than one per track. The five details the single-viewer demo hides.
- A diagnostics surface. Six getStats numbers, in the order that narrows the failure. Which six.
- A relay that is actually reachable. TURN, authentication and the realm mistake that produces endless 401s. The coturn guide.
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 ->