Forty people join a call. Your media server is not handling forty streams. It is handling 1,560.
That number is the whole of scaling video cost, and almost every capacity plan gets it wrong because it counts the wrong thing. Teams size their infrastructure on participants — a headcount, a seat number, something a sales forecast produces. A media server does not spend anything on participants. It spends on outbound streams, and outbound streams grow with the square of the room.
So the question is not how many people fit on one box. It is how much traffic leaves it.
The number everyone quotes — and the unit it's missing
If you have researched this before, you have seen the figure: a single media server handles roughly 40 to 70 participants. It gets repeated in vendor comparisons, capacity guides and architecture posts, usually without a qualifier.
The figure is real. It is also close to meaningless on its own, because it is a conclusion, not a specification — and the inputs it depends on almost never travel with it.
Here is where it comes from. The most rigorous public benchmark of open-source media servers is a comparative study by Andre, Roux and Gouaillard presented at IPTComm 2018, which loaded Jitsi, Janus, Medooze and Kurento on a 16-vCPU cloud instance with 2 Gbps of network, streaming 540x360 H.264 at 30 fps, arranged as rooms of seven.
The headline numbers need their conditions attached, which is the entire point of this section. Medooze was the strongest performer, holding 490 participants across seventy rooms and maintaining good image quality up to about 400. Jitsi also reached 490 — but with a 79% failure rate on the video check, meaning blank or frozen images, and sending bitrate collapsing from 530 kbps to 45 kbps. Janus stopped at 245 in that run, with round-trip time above 6.5 seconds at target load. Kurento/OpenVidu managed 140.
The Janus figure has since been superseded, and the correction matters. The same team's follow-up testing identified a bug in libnice that was throttling both Janus and Kurento. After a patch advised by the Janus team, Janus's results improved substantially and it reached roughly 500 users — at which point, in their words, "Janus seems to perform the best." Jitsi in that later round became unstable at exactly 240.
Two lessons sit in that correction. A participant count on its own can conceal a failed experiment — Jitsi's 490 is a number the process survived, not a number its users would have accepted. And a benchmark measures a build on a particular day rather than a project forever; the Janus result was a bug, and the bug was fixed.
Meanwhile mediasoup's own documentation states a different number entirely: one worker process, pinned to one CPU core, handles "over ~500 consumers." A consumer is one outbound stream to one receiver.
Those look like contradictory numbers. They are the same number in different units, and the unit is the entire argument.
Why scaling video cost is quadratic, not linear
In a room where everyone sees everyone, each participant receives a stream from every other participant. The server forwards N x (N-1) streams. Add one person to a call and you do not add one stream — you add roughly 2N of them.
Now the two benchmark figures reconcile. At roughly 500 consumers per core, one core saturates at about 23 people in a single all-see-all room. A 16-vCPU box has about 8,000 consumers of headroom, which lands between 70 and 90 participants in one room — or, split differently, seventy separate rooms of seven, which is 2,940 consumers and well within the same budget.
Neither 40–70 nor 500 is a property of the software. Both are the same egress budget, divided by a different room shape. A media server does not fail at a user count. It fails at a traffic number, and how you arrange your users decides how fast you reach it.
Which raises the practical question: what does that traffic number actually cost?
What actually breaks first
Three things can run out, and they run out in a predictable order.
CPU goes first in small, dense rooms. Forwarding is cheap per stream but not free — the server still terminates encryption, rewrites RTP headers and tracks state per consumer. This is the constraint the per-core consumer figure describes.
The network interface goes next, and in practice it goes sooner than teams expect. A 40-person room forwarding an average of 600 kbps per stream is pushing 936 Mbps — very close to a gigabit, out of one machine, for one meeting. The IPTComm rig had 2 Gbps, which is precisely why it capped where it did.
Quality goes last, and this is the counterintuitive part. The same benchmarking work found that bitrate and round-trip time both degrade well before users notice anything, and that perceived video quality held up until per-stream bandwidth fell below roughly 200 kbps. Your dashboards turn amber long before your users complain. That sounds like good news and it is not: it means the graph that would have warned you is the graph everyone has learned to ignore.
The instinct at this point is to add a second server. That helps less than it looks.
The second box doesn't halve the problem
Splitting one room across two servers does not split the traffic in half, because participants on server A still need the streams published on server B. The servers have to forward to each other, and that inter-server link carries real bandwidth.
Cascading is the standard answer and it is a good one — it is how every large deployment works, and it buys you geographic proximity as well as headroom. But it converts a capacity problem into a topology problem. You now own decisions about which participants land on which server, how many streams cross between them, and what happens when one of them fails mid-call. None of that is free, and none of it is a configuration flag.
The honest framing is that clustering does not reduce your scaling video cost. It makes the cost survivable and predictable, which is worth paying for — but the total traffic goes up, not down. The companion technical piece walks where the bottleneck moves as you add boxes.
So it is worth looking directly at the traffic bill, because it is the line item almost nobody models.
Where the scaling video cost actually lands
Total cost of ownership models for self-hosted video are common, and most of them are careful about the same four things: server instances, recording capacity, storage, and the engineering time to keep it all running. Those models are useful and they are usually right.
They also tend to leave out egress, which on some infrastructure is the largest number on the page.
Take the 40-person room. 1,560 outbound streams at an average 600 kbps is 936 Mbps sustained, which is about 421 GB of outbound traffic per hour of meeting. Priced against published cloud egress rates:
One 40-person all-hands costs roughly $38 an hour in bandwidth alone on major-cloud list pricing. The same meeting on a dedicated server with bundled transfer costs about forty-five cents.
That is not a rounding difference. It is roughly 90x, and it is larger than every other variable in the build-versus-buy decision combined.
For scale, a per-minute cloud video API at around $0.004 per participant-minute prices that same 40-person hour at about $9.60. Which means major-cloud egress alone runs roughly four times the cost of simply buying the service — while the identical software on dedicated hardware runs about a twentieth of it.
The conclusion is not that self-hosting is cheap or expensive. It is that "self-hosted" is not one cost model. The software is free either way; where you run it moves the bill by two orders of magnitude, and it is the single variable most TCO comparisons hold constant without saying so.
Build, buy, or deploy
Three routes, with the honest boundary on each.
Build on open source
mediasoup, Janus, Pion and LiveKit are all production-grade and genuinely free to license — choosing between them is its own decision. This route wins decisively when you have somewhere cheap to put the traffic — dedicated servers, a colocation contract, or committed bandwidth — and an engineer who owns the deployment. It goes wrong when teams take the same open-source stack and run it on metered public-cloud egress, which is where the free software quietly becomes the most expensive option on the table.
Buy a cloud video API
Per-minute providers absorb the bandwidth problem entirely, and at low or spiky volume that is excellent value — you pay nothing for the idle hours and nothing for the capacity planning. The economics invert at sustained scale, because the per-minute rate is linear in participants while your actual traffic is quadratic in room size. Large rooms are where per-minute pricing hurts most and where its value is least obvious upfront.
Deploy a commercial platform
The middle path is a platform you run on infrastructure you choose, so the egress lands on your contract rather than someone's margin. Samvyo is one such option: it is based on SFU architecture, ships embeddable SDKs, and lets you keep the media path, TURN and recording on infrastructure you control — which is exactly the set of decisions that determines the bandwidth bill above. It is resilient by design rather than something you assemble.
Where it does not fit: if your volume is genuinely low or highly irregular, a per-minute API will cost less and involve fewer decisions. And if you have deep in-house WebRTC expertise and an existing bare-metal footprint, building on open source is a reasonable and well-trodden path. The platform route earns its keep in the middle — meaningful scale, no dedicated video infrastructure team.
The Bottom Line
A media server does not cap at a number of users. It caps at a volume of outbound traffic, and that volume grows with the square of the room, not in step with the headcount. Size your infrastructure on streams, not seats.
And before comparing self-hosting to buying, price the egress. The software licence is the same either way; the bandwidth is where the decision is actually made, and on major-cloud list rates it can exceed the cost of the service you were trying to avoid.
What's Next
This post covered what scaling past a single media server costs. The companion technical deep-dive, SFU scaling: clustering, cascading, and where the bottleneck moves, walks the other half. If you are earlier in the decision, what an SFU is and why every video platform uses one is the place to start.
Frequently Asked Questions
How many participants can one media server handle?
Between roughly 40 and 70 in a single room where everyone sees everyone, on a 16-vCPU class machine at conferencing bitrates — but the figure is misleading on its own. The real limit is outbound streams, around 500 per CPU core. The same hardware that supports 70 people in one room supports several hundred spread across smaller rooms, because a room of seven generates 42 streams while a room of seventy generates 4,830.
Why does scaling video cost grow faster than the number of users?
Because in an all-see-all room every participant receives a stream from every other participant, so the server forwards N x (N-1) streams. Doubling a room from 20 to 40 people does not double the load — it roughly quadruples it, from 380 streams to 1,560.
Is self-hosting a media server cheaper than a per-minute video API?
It depends almost entirely on where you host it, not on the software. On dedicated servers with bundled bandwidth, self-hosting is dramatically cheaper. On metered public-cloud egress at around $0.09/GB, the bandwidth alone can cost several times what a per-minute API would charge for the same sessions. Price the egress before comparing anything else.
What is egress, and why is it missing from most TCO models?
Egress is outbound data transfer — the traffic leaving your server toward users. Most self-hosting cost models carefully account for compute, storage, recording and engineering time, all of which are visible as line items when you provision them. Egress is usage-based and arrives after the fact, so it tends to be estimated rather than modelled, and video is unusually egress-heavy.
Does clustering media servers reduce bandwidth costs?
No — it increases total traffic, because servers must forward streams to each other so participants split across boxes can still see everyone. Clustering solves capacity and geography, not cost. What it buys you is a system that keeps working past the point where one machine stops, which is usually worth the additional traffic.
Can I keep control of the media path without building on open source myself?
Yes. Some commercial platforms are deployed on infrastructure you choose rather than consumed as a metered cloud service, which keeps the media path, TURN and recording under your control and the bandwidth on your own contract. Samvyo works this way. The tradeoff is that you are still responsible for the hosting decision — which, as the numbers above show, is the decision that matters most.
What bitrate should I assume when estimating video bandwidth?
For planning, an average of 500–700 kbps per forwarded stream is a reasonable starting point for conferencing with simulcast enabled, since most participants in a grid view receive a lower layer rather than full-resolution video. Measure your own distribution before committing to a capacity plan — the average matters far more than the peak, because it is multiplied by N x (N-1).
