Video servers are sized wrong in a predictable direction: too much CPU, too little thought about bandwidth. A Jitsi videobridge does not transcode, so it needs far less CPU than people expect, but it forwards every stream to every participant, so its network throughput is the real limit. This post follows a DevOps engineer sizing a Jitsi Meet server for an online school on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, where the node's resources follow the timetable.
The school is an online language academy we will call Linden Language School: about 40 simultaneous classes of one teacher and up to 15 students between 09:00 and 13:00, a handful in the afternoon, none at night. The Jitsi Video Conferencing package gives the engineer a complete Jitsi server on a dedicated node with a public IP to start from.
How a videobridge uses resources
In a Jitsi meeting each participant sends one stream to the videobridge, and the bridge forwards the streams the participant needs to see. It is a selective forwarding unit: it does not decode or re-encode video, so the CPU cost per stream is small, mostly encryption and packet handling. What grows is outbound bandwidth. In a class of 16 where everyone shows video in a tiled layout, each participant receives up to 15 streams, and at 15 participants receiving even a lowered-quality tile each, the bridge is sending a meaningful multiple of what it receives. Jitsi mitigates this with simulcast (participants send several quality layers and the bridge forwards the lowest that fits each viewer's layout) and by sending only the visible tiles.
The arithmetic for 40 classrooms
The engineer's planning assumptions, deliberately conservative: a teacher's stream forwarded at higher quality to every student, students forwarded to each other at thumbnail quality in a tiled layout, audio for everyone.
| Per class of 16 | Inbound to bridge | Outbound from bridge |
|---|---|---|
| Teacher video (one stream, forwarded to 15 at ~1.5 Mbps) | ~2 Mbps (simulcast layers) | ~22 Mbps |
| Student thumbnails (15 streams, each forwarded to 15 others at ~0.2 Mbps) | ~4 Mbps | ~45 Mbps |
| Audio (16 streams at ~50 kbps, forwarded to 15) | ~0.8 Mbps | ~12 Mbps |
| Total per class | ~7 Mbps | ~80 Mbps |
| 40 classes at 09:00 | ~280 Mbps | ~3.2 Gbps |
The realistic figure is lower, because not every student shows video and Jitsi's layout logic limits what is forwarded, but 3 Gbps outbound at peak is the number to design against, and it is well beyond what one videobridge node should carry. The plan is therefore two or three videobridges at peak, not one, with the engineer verifying the real numbers in the platform's per-minute network statistics during the first week and adjusting.
Sizing the node in cloudlets
CPU and RAM are the smaller problem. A videobridge handling a few hundred streams needs a handful of cores and a couple of gigabytes; Prosody and Jicofo are light; the web front end is static files. The engineer sets the Jitsi node's cloudlet limit at 32 (a cloudlet is 128 MiB of RAM plus 400 MHz of CPU) and lets the platform's vertical scaling allocate what the process actually uses by the hour: perhaps 20 to 28 cloudlets during the morning block, 4 to 6 in the afternoon, 2 at night. Billing follows that curve, so the server costs a fraction at night of what it costs at 09:30. A load alert at 85% CPU for 10 minutes tells him if the ceiling is too low during a real morning.
The platform's network statistics per node record inbound and outbound traffic per minute and show the provider's external bandwidth limit for the node. That graph, not a guess, is what the engineer uses after week one to decide how many bridges the morning needs.
Adding videobridges
Jitsi is designed to run several videobridges behind one signalling server: each bridge registers with Jicofo, which assigns new conferences to bridges by load. On the platform the engineer adds additional videobridge nodes as separate containers in the same environment, each with its own public IP (media needs a directly reachable address and UDP 10000 open in the container firewall) and configured with the Prosody server's internal hostname. Because the school's peak is predictable, he runs three bridges from 08:30 to 13:30 and stops two of them in the afternoon with the Start/Stop Scheduler add-on's per-node scheduling; a stopped container is billed for disk only. Jicofo notices bridges joining and leaving and routes new classes to whichever are up.
This is the decision that matters most: scale the bridges by count and by schedule, not the whole server by size. The signalling node is never the bottleneck at this scale; the bridges' network throughput is.
Quality settings that reduce the bill
Two Jitsi configuration choices halved the projected outbound traffic in the first week. First, the default video constraint for students was lowered so a student's stream is sent at a modest resolution, which is all a thumbnail needs; the teacher's remains higher. Second, the tiled layout was capped at a fixed number of visible tiles, so a class of 16 forwards at most that many student streams to each viewer, and audio-only participants cost almost nothing. These are Jitsi settings in the web front end's configuration file, editable through the platform's config editor, and they took an hour.
What the school pays
One signalling-plus-bridge node averaging about 12 cloudlets across the day, two additional bridges running five hours a day at around 16 cloudlets each, three public IPs (two of them attached only while their bridges run, since a stopped node still holds its IP, the engineer detaches and reattaches them by schedule to save the hourly charge), and outbound traffic. The compute lands around $40 to $50 a month at MassiveGRID's published $0.003372 per cloudlet-hour before discounts; traffic is the larger line and is what the quality settings above are for. For 600 students in daily live classes, the school's previous per-host video licences cost more each month than this does in a quarter.
Frequently Asked Questions
Does Jitsi need a TURN server on the platform?
Most participants connect directly to the videobridge's public IP over UDP 10000. Participants behind very restrictive firewalls that block UDP need a TURN server on TCP 443 as a fallback; Jitsi's deployment includes coturn for this, and it can run on the same node or a separate one with its own public IP. Test from a corporate network before deciding you do not need it.
Can the platform's horizontal auto-scaling add videobridges automatically?
Horizontal scaling triggers add containers to a layer on CPU, memory or network thresholds, and a videobridge layer can be scaled that way with a network trigger. Each new bridge needs its own public IP and registration with Jicofo, which the deployment's configuration handles at start. For a predictable timetable, scheduled start and stop is simpler and cheaper; triggers suit unpredictable load.
How do I see what the bridges are really using?
The platform's statistics per node show network in and out, CPU and RAM per minute for the last hour and hourly afterwards. Jitsi Videobridge also exposes its own statistics endpoint with stream counts and bitrates, which you can scrape with Prometheus if you want a dashboard.
Size for the timetable, not for the year
Deploy Jitsi Meet on MassiveGRID PaaS with a public IP, scale the node by the hour and add videobridges on schedule. Per-cloudlet-hour billing, 100% uptime SLA, four regions. Free 14-day trial, no credit card.
Jitsi Meet on MassiveGRID PaaS