Jitsi high availability and scaling

The Jitsi scalable setup guide gives a starting point for each role: a 4 CPU, 8 GB machine for the central server, and 4 or 8 CPU with 8 GB RAM for each videobridge. Treat these figures as a baseline for a first build, not as a capacity commitment. The guide recommends adding more videobridges to scale horizontally, so the decision you actually face is how many bridges to run and how large each one should be. Settle the per-bridge size only after you have measured how your own meetings load it.

Bridge load does not follow from the machine specification alone. It depends on how many participants share a bridge, the video quality that participants send and receive, whether simulcast is in use, how often screen sharing runs (screen content is heavier to encode and route than camera video), and the network bandwidth each bridge carries in and out. Two bridges of the same size can behave very differently if one hosts large all-hands meetings with screen sharing and the other hosts small team calls. Build your load test around the meeting pattern you expect in production, with a realistic mix of participant counts, video on and off, and sharing, rather than a single synthetic test of maximum participants.

During a pilot, measure CPU, memory and network bandwidth on each videobridge while meetings run, and record them alongside the participant count per bridge. Look at peak values during the busiest meetings, not averages across a quiet day. Use those measurements to set a per-bridge participant ceiling with headroom, so that the scheduler or your operating procedure moves new meetings to another bridge before the current one is saturated. Confirm the bridge's network allocation and any cloud bandwidth limits with your provider, because a bridge can run out of bandwidth before it runs out of CPU.

Keep Jibri out of this sizing exercise. The Jibri README states that a Jibri instance should run on its own machine or VM, because it runs Chrome in a virtual framebuffer and encodes with ffmpeg. Its load is a different profile from a videobridge, so do not count a Jibri host toward bridge capacity or place it on a bridge host. Recording needs are covered in the Jibri section of this page, but plan the machine for it separately from the bridge pool.

A videobridge failure and a central server failure have different effects, so plan for each one separately. When a videobridge crashes or is taken out of service during a meeting, media stops for the participants homed on that bridge. Meetings on other bridges keep running. The central server runs Prosody and Jicofo, and its failure affects the whole deployment. New conferences cannot be created, and signaling for meetings already in progress is interrupted. Your design should treat the central server as a single point of failure unless you add redundancy to it, and your implementer should document how it is restored and how long that takes in your environment.

Spreading active meetings across bridges is the first control. Jicofo places participants on bridges, so the blast radius of one failure depends on how many meetings and participants share each bridge. More, smaller bridges mean a single failure touches a smaller share of meetings, but they also mean more machines to patch, monitor and pay for. Decide the per-bridge load you are willing to accept using the CPU, RAM and bandwidth figures from your sizing work. Then run a test meeting set and record which bridge each participant landed on, so you can confirm that placement matches your intent before go-live.

Draining a bridge before maintenance is the second control. A drain means no new conferences are placed on the bridge, existing meetings end or move on their own schedule, and only then is the host patched or restarted. Confirm with your Jitsi version whether the videobridge offers a graceful shutdown or drain mode, and how Jicofo responds to it. Schedule maintenance outside peak hours, announce the window to users, and check that the remaining bridges can carry the expected load during the window. Write the drain steps into a runbook and rehearse them in staging.

Deciding how many spare bridges to keep is a sizing decision that no general rule settles. The inputs are your peak concurrent participants, the largest number of participants you can accept losing in one failure, the time your team needs to replace or restart a bridge, and whether maintenance drains must run while the system still meets peak demand. Ask your implementer to model these inputs against your own usage data and to load test the chosen count. Revisit the number after each quarter of usage data, because growth in meeting size or recording use changes the answer.

Client behavior during a bridge loss must be confirmed in a pilot against the Jitsi version you run. The pilot should answer whether browsers and mobile apps reconnect automatically, whether users must rejoin by hand, how long recovery takes, and whether the participant lands on a healthy bridge. Kill a bridge during a scripted test meeting and record what each client shows. Then publish a clear rejoin path to users before cutover: the room link stays the same, the steps to take if the video freezes, and the contact who handles problems during a meeting.

Scaling a Jitsi Meet deployment is only proven when the team has tested the failure cases as well as the happy path. Before go-live, define the pass criteria for each test in writing, run the tests against the production-like topology (signaling server, Prosody, Jicofo and every Jitsi Videobridge in the planned regions), and record the results as the baseline that the operations runbook will reference. Without a recorded baseline, the first real bridge failure becomes the first time anyone learns how the system behaves.

Start with test conferences that force participants onto each bridge. Jicofo chooses a bridge for each conference, so the team needs a way to make a test client land on a specific videobridge, for example by controlling which bridges are available during the test window or by running clients from the network segment closest to each bridge. Confirm the exact method with your platform engineers against your deployed version. For each bridge, verify that audio, video and screen sharing flow in both directions, that the bridge shows up as active in monitoring, and that the participants' media is encrypted in transit as designed.

Next, run load tests that step up concurrent participants in defined increments until one bridge reaches its measured ceiling. The ceiling must come from your own measurements on the chosen instance size, not from a vendor figure. The Jitsi scalable setup guide suggests a starting machine profile for videobridges, but it does not give a participant limit, so treat any number you read elsewhere as unverified. Record CPU, memory, network throughput and packet loss at each step, and define in advance the level at which the bridge counts as full, so that new meetings are moved to another bridge before quality degrades.

Then stop one bridge on purpose during a live test meeting and observe three things: what the connected participants see and how quickly their clients recover, whether new meetings are routed to the remaining bridges, and whether the monitoring and alerting detect the outage. Repeat with the central server restarted, because the signaling components (Prosody and Jicofo) sit in front of every bridge. Record which conferences survive, which must be rejoined, and how long participants wait. Agree with the business owner whether a mid-meeting drop is acceptable for a bridge loss and whether it is acceptable for a central restart, since these outcomes differ and should be documented as separate pass criteria.

Finish with certificate and port checks from restricted networks, such as guest Wi-Fi, a branch office behind a strict proxy and a mobile network. Confirm that the certificate chain is trusted by each client type, that 443/TCP and 10000/UDP are reachable where your design expects them, and that the fallback path works where UDP is blocked. Store the results, the test versions and the exact configuration in version control so that a later upgrade or scaling change can be retested against the same criteria.