Self-hosting a media server is genuinely free to license. mediasoup, Janus, Pion and LiveKit cost nothing, run in production at serious scale, and are maintained by people who know what they are doing.
Then you deploy one, and discover it does not work for about one user in five.
Those users are behind symmetric NATs or corporate firewalls that will not allow a direct media path. Reaching them requires a relay — a TURN server — which is a second fleet of machines nobody put in the spreadsheet, carrying traffic that gets paid for twice. It is the clearest example of why free software is not a free system, and it is almost always missing from the model.
What TURN is, and why you cannot skip it
WebRTC tries to connect two endpoints directly. When both sides are behind ordinary home routers, a technique called STUN lets each discover its public address and punch a hole through. This works most of the time and costs almost nothing, because no media flows through your infrastructure at all.
It fails when a network refuses to cooperate — symmetric NAT that assigns a different port per destination, corporate firewalls that block UDP outright, restrictive mobile carrier networks. For those users the only option is to give up on a direct path and relay the media through a server that both sides can reach. That server is TURN, and unlike STUN it carries every byte.
You cannot treat this as an edge case to skip, because the users it affects are disproportionately the ones you care about. Corporate networks are exactly where enterprise buyers sit. "Works on my laptop, fails in the customer's office" is the single most common WebRTC deployment story, and TURN is the fix.
How often does it actually happen?
This is where the honest answer matters more than a confident one.
The only substantial public measurement comes from callstats.io, reported on webrtcHacks, which observed billions of minutes across more than a hundred WebRTC services and found that 22% of conferences required some kind of TURN relay, with 9% needing TCP transport specifically. The same dataset found 12% of sessions failed to establish at all, and that 85% of those failures were NAT or firewall traversal.
That data is from January 2015 to February 2016. No comparable public dataset has been published since, which means every current-sounding percentage in circulation — the commonly quoted 8–20% range included — traces back to a decade-old measurement. Ten years of IPv6 rollout, carrier-grade NAT expansion and enterprise firewall change sit in between, pushing in different directions.
So treat it as an order of magnitude rather than a figure: roughly one session in five, possibly fewer, possibly more on an enterprise-heavy user base. Plan capacity for it, measure your own rate once you are live, and do not put someone else's 2016 percentage in a business case without saying where it came from.
Even at the low end of that range, the arithmetic is not what most models assume.
Why a relayed session doubles your self-hosted video cost
A TURN server is a pure relay. Media arrives, and the identical media leaves. Every byte it handles is a byte of outbound traffic on your bill — and that traffic is a second copy of something your media server already sent.
Trace one relayed viewer. The media server forwards their streams out to TURN. TURN forwards those same streams out to the viewer. Two outbound hops, same content, both metered. The viewer's traffic now costs twice what the media server's own egress bill predicted.
Applied to a concrete room, using 600 kbps as the average forwarded stream and standard cloud egress at $0.09/GB:
A useful rule of thumb: add about 20% to whatever your media server egress model says, and you will be roughly right. Add nothing, and you will be roughly 20% wrong in the direction that matters.
And the relay load does not fall evenly across your users.
Who actually generates relay traffic
TURN traffic follows the same asymmetry as everything else on a media server: it scales with viewers rather than publishers. A relayed participant publishing one stream costs you one stream of relay. The same participant receiving thirty-nine streams costs you thirty-nine.
Two consequences follow. A single relayed viewer in a large room is far more expensive than a relayed publisher, so the cost concentrates in exactly the sessions you would least like to degrade. And a broadcast or webinar workload — one publisher, many viewers — has its entire relay exposure on the audience side, which is the side that grows.
This is also why TURN capacity planning cannot be done in sessions. It has to be done in relayed streams, the same unit as everything else.
The self-hosted video cost model, line by line
Cost models for outgrowing self-hosted WebRTC are usually careful about compute, storage, recording capacity and engineering time, and those models are right as far as they go. The gap is consistent, and it is everything that is usage-based rather than provisioned:
None of these are large individually. Together they are the difference between a self-hosting business case that holds and one that quietly does not, and they share a property: they are all consequences of running the system rather than licensing the software. That is the honest version of "open source is not free" — not that the licence has a catch, but that the licence was never the expensive part.
What skipping TURN costs instead
The tempting response is to run STUN only, or to lean on a free public STUN server, and accept that some calls fail.
That has a price too, and the same dataset puts a number on it: 12% of sessions failing to establish, with 85% of those attributable to NAT and firewall traversal. Those are not degraded calls. They are calls that never start, on the networks where your enterprise users sit, presenting to the user as a product that does not work.
Weighed against roughly a 20% bandwidth increase, a materially lower connection-failure rate is almost always the better trade. The point is not that TURN is expensive — it is that it is a real line item, and pretending otherwise means discovering it in production rather than in the spreadsheet.
Which leaves the question of who should be running it at all.
Build, Buy, or Deploy
Three routes, with the honest boundary on each.
Build on open source
coturn is the standard open-source TURN server and it is solid, well understood and free. Running it yourself is entirely reasonable — and it means operating a geographically distributed fleet, issuing short-lived credentials, keeping TLS on 443 for the strictest firewalls, and sizing for bursty relay demand you do not control. That is a separate operational surface from choosing a media server, and it is the part most teams have not costed when they decide to self-host.
Buy a cloud video API
Per-minute providers include TURN in the price, which is genuinely one of the better arguments for them — the relay problem disappears entirely and you never think about it again. The limits are the usual ones: you cannot place relays where your users actually are if the provider has not, and you generally cannot see what share of your sessions are relaying, which is the number you would want in order to reason about any of this.
Deploy a commercial platform
The middle path runs a commercial platform on infrastructure you choose. Samvyo is one such option: based on SFU architecture, shipping embeddable SDKs, with the media path, TURN and recording kept on infrastructure you control. TURN sitting in that list is the relevant part here — the relay is yours to place and yours to meter, rather than an invisible line inside someone else's per-minute rate. It is resilient by design rather than something you assemble.
Where it does not fit: if your volume is low or irregular, a per-minute API bundles TURN and costs less overall. And if your users are entirely on networks you control — a closed corporate deployment, or a surveillance estate on your own VLANs — your relay rate may be near zero and none of this arithmetic applies to you.
The Bottom Line
The licence is free. The relay is not. Roughly one session in five cannot take a direct path and has to go through TURN, and because TURN is a pure relay, that traffic is paid for twice — once leaving the media server, once leaving the relay.
Budget about 20% on top of your media server egress model, size TURN in relayed streams rather than sessions, and measure your own relay rate once you are live rather than inheriting a percentage from 2016. Open source is not free; it is unpriced, which is a different thing and a more expensive one to discover late.
What's Next
The media server side of the same bill is in what scaling past a single media server costs, which prices egress against different hosting venues. And why the bill follows viewers, not publishers explains the asymmetry that governs relay load as much as it governs forwarding.
Frequently Asked Questions
What is a TURN server and why does WebRTC need one?
A TURN server relays media between two endpoints that cannot establish a direct connection. WebRTC tries a direct path first, assisted by STUN. When a symmetric NAT, a corporate firewall or a restrictive mobile network blocks that, TURN carries the media instead. Unlike STUN, every byte passes through it, which is why it costs real money.
What percentage of WebRTC calls use TURN?
The only substantial public measurement — callstats.io, across billions of minutes between January 2015 and February 2016 — found 22% of conferences required a relay. No comparable dataset has been published since, so treat roughly one in five as an order of magnitude rather than a current figure, and measure your own rate once you are live.
Does TURN double bandwidth costs?
For relayed sessions, effectively yes. TURN is a pure relay, so media arrives and the same media leaves, and that outbound traffic is a second copy of what the media server already sent. At a 20% relay rate, total egress runs about 20% above what a media-server-only model predicts.
How much does self-hosted video actually cost beyond the servers?
The consistently missing items are usage-based rather than provisioned: media server egress, a separate TURN fleet, TURN egress, capacity headroom for bursty relay demand, and credential and certificate rotation. Compute, storage and engineering time are usually modelled correctly; these are not.
Can I use a free public STUN server instead of running TURN?
For the users who can connect directly, yes — public STUN is fine and costs nothing. It does nothing for the users who cannot, which is the whole problem. Running STUN only means accepting a connection-failure rate; the same dataset above found 12% of sessions failed to establish, with 85% of those caused by NAT or firewall traversal.
Is TURN included with commercial video platforms?
Usually, though how much control you get varies. Per-minute cloud APIs bundle it and hide it entirely. Platforms deployed on your own infrastructure, including Samvyo, keep TURN under your control alongside the media path and recording — so you choose where relays sit and can see what they cost.
How do I size a TURN deployment?
In relayed streams, not sessions. A relayed viewer in a large room consumes one relayed stream for every publisher they are subscribed to, so a single relayed participant in a 40-person call is dramatically more expensive than one in a two-person call. Size on peak concurrent relayed streams and place relays near your users, since the relay adds a network hop to the latency budget.
