On most platforms, shipping WebRTC to production is a research project. You provision and operate a TURN server, manage UDP port pools, wire up STUN, mint ICE credentials, and hope the whole arrangement survives its first load test. None of that is your product — it’s just the toll you pay before your product can make a call.
Since launch, Watasu has shipped real-time support in early access. As of today that label is gone — it’s open to every account, and the entire setup is a process suffix:
web: bundle exec puma # signaling server
sfu-rtc: node sfu/server.js # the SFU
worker: bundle exec sidekiqName a process *-rtc, push, and Watasu provisions everything WebRTC needs around it.
What you get per *-rtc process
- a dedicated TURN gateway — yours alone, not shared with other tenants
- a public TURN hostname and a public UDP port from a managed pool
- a stable public hostname for every replica (
<route-token>-01.watasuhost.com,-02, …), so your signaling layer can route a session to a specific replica when affinity matters TURN_*env vars injected into the container — URL, host, port, realm, and a shared secret for minting ephemeral per-session credentials, the standard pattern browsers expect
Scale it like any other process — watasu pods:scale sfu-rtc=4 — and every new replica arrives with its own stable hostname, while your TURN capacity scales with it.
Why a dedicated TURN gateway matters
A shared TURN server is a shared bottleneck and a shared failure domain: when another tenant’s call volume saturates it, your users’ calls degrade too, and there’s nothing you can do about it. With a gateway per process, your traffic competes with nobody, your failure domain is your own, and scaling your RTC process scales your relay capacity at the same moment. It’s the difference between an evening that survives a viral launch and one that doesn’t.
Bring your own SFU — any of them
Watasu provides the ICE/TURN infrastructure; the media server is your choice. mediasoup, Pion, Janus, Jitsi Videobridge, LiveKit Server — anything that speaks WebRTC and fits in a container works. Build it, name the process *-rtc, deploy.
This makes Watasu a natural home for voice agents and real-time AI: call-handling backends get production-grade ICE without an external TURN provider sitting in the latency budget, and the signaling app, workers, and databases all live next door in the same app.
What it doesn’t do — honestly
*-rtc doesn’t ship an SFU for you, doesn’t handle signaling (that’s a regular web process), and doesn’t replace your authentication or session logic. It removes the infrastructure layer between your WebRTC code and the public internet — the part that was never your product to begin with.
Get started
The Real-Time and WebRTC guide has the full environment-variable reference and the ephemeral-credentials pattern. Add an *-rtc line to a Procfile, push, and make a call — then tell us what you’re building: info@watasu.io.