mediasoup: a C++ SFU you drive from Node.js or Rust

What mediasoup actually is, and who ends up using it

mediasoup is a Selective Forwarding Unit. In a group call, an SFU receives each participant's stream once and forwards selected streams to the other participants, rather than mixing audio or connecting everyone peer to peer. The README lists the design goals plainly: be an SFU, support WebRTC and plain RTP input and output, be a Node.js module or Rust crate on the server side, be minimalist, and be signaling agnostic.

The intended audience is not a product team looking for a video conference app. It is engineers building one. The README lists group video chat, one-to-many or few-to-many real-time broadcasting, and RTP streaming as use cases, and describes the API as "super low level" with no constraint or assumption about the scenario. That means rooms, invitations, authentication, recording and the signaling protocol are all yours to design. mediasoup handles the media layer and stops there.

The repository is not archived. The last push was on 2026-09-21, and the recent releases include 3.27.1 and rust-0.28.1 on 2026-09-16. The project ships both an npm package and a Rust crate from the same repository, which is unusual and worth noting: the Cargo workspace lists the rust, rust/types and worker members.

The C++ worker and the JavaScript API in front of it

The architecture is a two-layer split. Media work happens in a C++ worker, described in the README as a media worker thread or subprocess coded in C++ on top of libuv. The API you call from your application is ECMAScript 6 or idiomatic Rust. The package.json points main at node/lib/index.js with types at node/lib/index.d.ts, and the published files include the worker sources, worker/meson.build and worker/subprojects, so the worker is built from source or from a prebuilt binary rather than being a separate service you install.

The feature list explains what the worker gives you once it is running: multi-stream, meaning several audio and video streams over a single ICE and DTLS transport; ICE, DTLS, RTP and RTCP over UDP and TCP; simulcast and SVC support; congestion control; sender and receiver bandwidth estimation with a spatial and temporal layer distribution algorithm; and data message exchange through WebRTC DataChannels, SCTP over plain UDP, and direct termination in Node.js or Rust. IPv6 is listed as ready.

The practical consequence is that a single transport carries many streams, and the layer selection logic is inside the worker. Your application decides which producers and consumers exist and connects them; it does not touch RTP packets. That is a clean boundary, and it is also the reason mediasoup cannot help you with anything above it.

Installing mediasoup and creating your first worker

The package is published on npm as mediasoup and on crates.io as mediasoup, and the README points to mediasoup.org for documentation. The package.json declares an engines field of node >= 22, so check your runtime before anything else. The install pulls in the worker build path, which is the part most likely to fail on a fresh machine, so install before you write application code.

npm install mediasoup

The package.json declares the entry point as node/lib/index.js and the type definitions as node/lib/index.d.ts. The first real step in any mediasoup application is creating a worker, because the worker is the process that will own routers and transports. The README does not include a code sample for this, and it does not reproduce the full option list; mediasoup.org is where the parameter names and defaults live, so read them there rather than guessing at keys.

For the Rust side, the repository is a Cargo workspace with members rust, rust/types and worker, and the crate is published as mediasoup on crates.io. The README does not include a Rust code sample either, so treat the crate documentation as the starting point instead of copying a snippet from the repository front page.

Where mediasoup stops and your application has to start

The signaling-agnostic design is the project's biggest strength and its biggest cost. mediasoup does not mandate a signaling protocol, so you must build one: how clients announce themselves, how SDP and ICE parameters travel between browser and server, how a client learns that a new producer appeared, and how failures are reported. None of that is in the media layer.

Room semantics are also absent. There is no concept of a room in the design goals. You create routers and connect transports, and the mapping from your application's rooms to routers is an architectural decision you own. Get it wrong and you either create too many routers or serialize unrelated traffic through one.

A second limitation is operational. The worker is a C++ process, and the README describes it as a thread or subprocess. Distributing load across CPU cores is your problem, not the library's. The documentation does not describe an automatic scaling or orchestration layer, and the README does not document rollback or migration behaviour for a running worker. If you need a system that manages its own capacity, mediasoup is the wrong tool.

The third limitation is scope. Because the API is deliberately low level, common product features such as recording, transcription, active speaker detection and moderation are not part of it. The README lists integration with well known multimedia libraries and tools as a goal, which is a statement about extensibility, not about features being included.

mediasoup compared with LiveKit and Janus

The most useful comparison is with LiveKit, which appears in the related searches as mediasoup vs livekit. LiveKit is a full media stack with its own signaling, room model and client SDKs, so a team can stand up a conferencing service without designing a protocol. mediasoup gives you the media layer and expects you to build the rest. The difference is not quality, it is where the boundary sits. Choose mediasoup when the boundary matters to you, for example when the signaling protocol must match an existing system or when the product is not a conference call at all.

Janus is the other common comparison, appearing as mediasoup vs janus. Janus is a general purpose WebRTC server built around plugins, so its functionality is extended by writing or enabling a plugin inside the server. mediasoup's extension point is the application around it, in Node.js or Rust, not a plugin inside the media process. That distinction affects how you deploy: a Janus plugin is compiled into the server, while a mediasoup application is ordinary application code that talks to a worker.

Pion, also in the search data as mediasoup vs pion, takes a third route: a WebRTC implementation in Go, where the SFU logic is written in the same language as the rest of the server. mediasoup keeps the media path in C++ and exposes it through Node.js or Rust. If your team is a Go team and wants one language end to end, that difference alone decides it.

Licence, releases and what upgrading costs

mediasoup is released under the ISC licence, confirmed both in the README and in the licence field of package.json. ISC is a permissive licence, similar in effect to MIT, and it does not impose copyleft obligations on your application. This is not legal advice; if your organisation has a licence review process, the ISC text in the repository's LICENSE file is what that process should read. The README also links an OpenCollective page for sponsorship, which is funding, not licensing.

Upgrade cost is real here because the API is low level. A change to transport, producer or consumer semantics reaches your application directly, since there is no higher level framework insulating you. The repository keeps a CHANGELOG.md at the top level, and the release history shows a steady cadence: 3.27.0 on 2026-09-14, then 3.27.1 and rust-0.28.1 on 2026-09-16. Two version lines, npm and Rust, are released from the same repository, and their version numbers do not move in lockstep, so a Rust deployment should track the rust-* tags rather than the plain numeric ones.

The worker is compiled C++ with vendored dependencies listed under worker/deps and worker/subprojects. That means a build from source depends on a working C++ toolchain, and the README does not document a supported compiler matrix. Budget time for the first build on each platform you target.

Editorial conclusion

Adopt mediasoup when you need media routing under your own control and can write the signaling, room and authorization layer yourself; the README states the API is deliberately low level and signaling agnostic, so nothing above the media layer comes with it. Skip it if you want a conferencing product with rooms, recording and a REST API out of the box. Before committing, check the mediasoup.org documentation for the exact Node.js and Rust setup path, confirm the worker builds on your target platforms, and decide how you will distribute workers across CPU cores.

Frequently asked questions

Official sources

1. License: ISC
2. Project website
3. README
4. Releases
5. versatica/mediasoup on GitHub