← Back to Blog

Why We Built Yet Another WebRTC SFU

Lukas Herman•December 11, 2025

The first time I got WebRTC working, it was insanely magic: peer-to-peer video and data, straight between devices. No servers, no middlemen—just raw, real-time connection.

I was immediately hooked, living in the rabbit hole. Spending embarrassingly countless hours: building P2P file transfers, a DIY security camera, and a bunch of other "look ma, no backend!" side projects.

But then reality hit me like a ton of bricks.

Making P2P actually work in the wild, kills the "serverless" dream. You need a signaling server just so peers can say hello. Then you need a TURN server because corporate firewalls are basically video game mini-bosses. (I know you'll say.. you can use QRCode like for signaling, or hope that every device has a routable public IPv6, but this is not practical for many use cases)

And if you want groups? Congrats, you’ve unlocked a new level: P2P Mesh Mode. Your poor client now manages a connection for every single participant. AND connection retries, IP leaks, and your laptop fan spinning loud enough for takeoff.

My "cute little WebRTC side projects" slowly morphed into an accidental distributed system problem living wholly on the client. P2P's complexity becoming a questionable life choice. Quality assurance? lol, better hope and pray.

this is fine

Making Peace with the Server (The SFU)

I've been incredibly lucky. All that "banging my head against the wall" with early side projects opened doors. I’ve worked on the full spectrum of WebRTC technology—from driving a car remotely, squeezing WebRTC onto tiny, bare-metal chips without an OS (RTOS), to working on massive, cloud-scale WebRTC SFU infrastructure.

WebRTC is useful for many applications (I promise it's much more than just another Zoom clone).

Having a server in the middle (SFU) just makes life easier. It abstracts away the chaos of mesh networking and makes the system more predictable. My SFU wishlist became clear:

  • Approachable: Not too low-level or lost in abstractions.
  • Flexible: Works for robotics, data streaming, and video alike.
  • Performant & Scalable: Handles vertical and horizontal scaling natively, while CPU efficient.
  • Open: Transparent, hackable, and community-driven.

Enter PulseBeam

I see the active open-source industry today as: LiveKit, Mediasoup, Janus, Jitsi, and Galene. They are all fantastic projects that I’ve learned a ton from.

I couldn't find the sweet spot. Existing projects were either too bare-metal (forcing me to implement the signaling and logic), or too heavy (requiring orchestration, auxiliary services, or deep configuration to work).

I wanted a middle ground: the simplicity of a single binary, with the power of a modern distributed system.

PulseBeam is currently written in Rust (using Tokio and str0m) and designed as a self-contained single binary. It was born to have:

  • Support for all WebRTC clients (no playing favorites).
  • Simple architecture (but not too simple).
  • Vertical and horizontal scalability without headache.
  • SDKs there to help you, not lock you in.
  • Short and sweet config files.

The server, the SDKs, and the docs are all open source. We are still in the early days—which means things will break, things will change, and I’d love your help fixing them.

Is it ambitious? Absolutely. Is it a little crazy to build a new SFU in 2025? Probably.

If you want to nerd out about video codecs, complain about NAT traversal, or just say hi, come hang out in our Discord.