A WebRTC SFU in Rust: why it is the future of real time

Most video conferencing servers are written in Java, Go or C/C++. Each of those languages makes a trade: Java and Go have a garbage collector that can suspend execution at the wrong moment; C and C++ offer performance at the price of recurring memory bugs. Rust is the first language to remove both problems at once. And for a WebRTC SFU, that is a change of paradigm.

What an SFU is, and why the language matters

An SFU (Selective Forwarding Unit) is the heart of a modern video conferencing system. It receives every participant’s audio and video and redistributes them to the others, without decoding or re-encoding. It is a packet router specialised for real time.

An SFU’s work looks simple (receive, decide, send) but is extremely demanding in practice. Every audio packet has to be relayed within a few milliseconds. A 20 ms delay is noticeable. A 100 ms freeze is unacceptable. And the server has to hold that performance steadily, whether the meeting runs for five minutes or five hours, with ten participants or five hundred.

Under those constraints, the choice of language becomes decisive.

The SFU landscape in 2026

SFU	Language	WebRTC library	Model	Vendor
Jitsi Videobridge (JVB)	Java	Own implementation	SFU	8x8 (United States)
Kurento	C/C++	GStreamer / libnice	SFU plus MCU	Community (end of active life)
mediasoup	C++ (worker) plus Node.js (signalling)	libwebrtc	SFU	Open source community
Janus	C	libnice, libsrtp	SFU plus plugins	Meetecho (Italy)
LiveKit	Go	Pion	SFU	LiveKit Inc. (United States)
Vuisio	Rust	str0m	SFU	Geezot (France)

Each generation of SFU was dictated by the dominant language of its time. Kurento and Janus were born in the C/C++ era. JVB was written in Java because Jitsi came out of the Java SIP client world. LiveKit appeared with the rise of Go and Pion. Vuisio marks Rust’s entry into real-time WebRTC.

Why Rust changes things for real time

The garbage collector is the enemy of real time

Java, Go and JavaScript all use a garbage collector. The GC frees unused memory automatically, which makes the developer’s life easier. But it does so by periodically suspending the program.

In Go, GC pauses are short on average (sub-millisecond in simple cases) but can reach 10 to 50 ms under load, particularly with large heaps or long linked lists (golang/go #37116). An experienced Go developer reports that the default GOGC=100 caused 200 ms latency spikes under load (DEV Community). Go also forces a GC cycle every two minutes even with no allocations (golang/go #37116).

OpenAI, which uses Go for its real-time WebRTC infrastructure (the ChatGPT voice mode), had to fall back on pre-allocated buffers and minimal copying to avoid garbage collection and keep latency acceptable (OpenAI). That is a workaround, not a solution: the GC is still there, you simply avoid triggering it.

In Java (JVB) the situation is worse: JVM GC pauses can reach hundreds of milliseconds with large heaps, which is incompatible with relaying audio in real time.

Rust has no garbage collector. Memory is managed by the ownership system, checked at compile time. There is no pause, no unpredictable latency spike, no gradual degradation. Processing a packet takes the same time after five minutes as after five hours.

Memory safety without the cost of a GC

C and C++ have no GC either, but they open the door to memory bugs: buffer overflows, use-after-free, data races. For an SFU handling media streams continuously, those bugs are a security nightmare. V100.ai (AI video infrastructure in Rust) sums it up: buffer overflows in media pipelines are a security nightmare (V100.ai).

Rust removes those categories of bug at compile time, through its type system and its borrow checker. A Rust SFU cannot have a buffer overflow, a use-after-free or a data race, because the compiler refuses to produce a binary that contains one. That is a structural guarantee, not a quality objective.

mediasoup (a C++ worker plus Node.js signalling) illustrates the opposite trade: the C++ worker performs excellently, but the Node.js signalling layer brings in the characteristics of the V8 runtime (V100.ai).

Predictability under load

An SFU has to hold a sustained load without degrading. That is where Rust shines most.

Vuisio’s documentation sets out the techniques used (docs.vuis.io): a multi-threaded architecture with one UDP socket per thread, participants spread by hashing (room, client), bounded inter-thread queues with a time budget so a busy room cannot block the others, and batched system calls for network send and receive. Memory profiling work (perf, bytehound) eliminated all memory growth under sustained load.

The result: the media relay uses only a few per cent of the processor (docs.vuis.io), and the memory footprint stays flat. On a server with 6 vCPU, Vuisio carried 450 to 500 simultaneous participants in load testing.

str0m: the WebRTC library designed for Rust

Vuisio is built on str0m, an open source WebRTC library in Rust developed by Martin Algesten (Lookback) (str0m on GitHub). str0m adopts a Sans I/O architecture: the library makes no network calls itself. It is the application (Vuisio’s SFU) that controls the sockets, the threads and the scheduling.

That design has several advantages for an SFU.

Full control over concurrency. The application decides how many threads to use, how to spread connections, and when to send packets. str0m creates no thread, no async task and no internal lock (str0m on GitHub). That is what lets Vuisio implement its one-socket-per-thread model with hash-based distribution.

Integration with any runtime. str0m is entirely synchronous and works with Tokio, async-std, or a home-made event loop. No conflict between the library’s runtime and the application’s.

Resilience. If a WebRTC session hits a bug inside str0m, the Rtc instance can be dropped through catch_unwind without poisoning locks or corrupting other sessions (str0m on GitHub). Because there are no internal threads, cleanup is clean.

The same code for testing. Vuisio’s load-testing harness uses str0m for its replay bots: they are indistinguishable from real clients at the network level (DTLS-SRTP, ICE, SCTP, RTP) (docs.vuis.io). That is a major methodological advantage over SFUs tested with third-party tools.

The Rust movement in critical infrastructure

Vuisio is not an isolated case. In 2026, Rust is establishing itself wherever performance and safety are not negotiable.

The Linux kernel has carried Rust code since version 6.1 for new drivers. Android uses Rust for critical system components. Cloudflare rewrote its HTTP proxy in Rust (Pingora). AWS uses Rust for Firecracker (serverless virtualisation). And in WebRTC specifically, V100.ai builds 20 microservices in Rust with 0.01 ms of server-side processing and 220,000 requests per second (V100.ai / DEV Community).

The trend is clear: for real-time, network and security systems, Rust is becoming the default choice for new projects.

What that means in practice

For a systems administrator, a Rust SFU means less RAM, less CPU and predictable stability under load. The server does not degrade gradually because a GC is building up memory pressure.

For a security lead, a Rust SFU means an entire category of vulnerabilities removed at compile time (buffer overflow, use-after-free, data races). The attack surface is structurally smaller.

For a decision-maker, a Rust SFU means infrastructure costs divided (1 GB of RAM can be enough for ten participants), less maintenance (fewer components, atomic updates) and stronger sovereignty (Vuisio is French, and the code can be audited).

In summary

The choice of an SFU’s language is not an implementation detail. It is an architectural decision that determines latency, security, resource use and stability in production. Java and Go trade against the garbage collector. C and C++ trade against memory safety. Rust is the first language to do neither.

Vuisio is the first complete video conferencing product built on a Rust SFU. If you want to see what that changes in practice, try it free.