How to scale Jitsi Meet to hundreds of participants

One Jitsi server handles a lot of small meetings. When it stops being enough, the answer is almost never “a bigger server”. It is more videobridges.

What actually runs out

Jitsi has two very different kinds of work:

• Signalling (web, Prosody, Jicofo): logins, room state, who is in which room. Light, and one set serves many bridges.
• Media (Jitsi Videobridge): forwarding everyone’s audio and video. Heavy on network, moderate on CPU.

When meetings get choppy, it is the media side. So you keep one signalling server and add bridges.

Adding a videobridge

A second bridge runs only the JVB container on another server and registers with the same Prosody over XMPP (port 5222). On the Docker setup that means:

1. On the main server, publish Prosody’s 5222 and allow it in the firewall only from your bridge servers.
2. On the new server, run the jvb service with the same JVB_AUTH_PASSWORD and the internal XMPP settings pointing at the main server.
3. Open 10000/udp on the new bridge to the internet, and make sure it advertises its own public IP.

Jicofo sees the new bridge join and starts placing conferences on it.

How Jicofo balances

Jicofo picks a bridge for each new conference, preferring the least loaded, and can take the region of the participants into account when bridges are labeled by region. Conferences already running stay where they are, so a new bridge fills up gradually rather than instantly.

Very large single meetings

A single conference can span several bridges, with the bridges relaying streams between each other. This lets one big meeting use more capacity than one server has, and lets participants in different regions each connect to a nearby bridge. It adds some complexity and latency between bridges, so use it for large or geographically spread meetings rather than by default.

Autoscaling

The standard pattern:

1. Put bridges in an autoscaling group (for example an AWS Auto Scaling Group) built from an image that starts JVB on boot.
2. Scale out on outbound network or stress metrics, not only CPU.
3. Scale in gently: stop sending new conferences to a bridge and wait until its meetings end before terminating it. Killing a busy bridge drops everyone on it.

What to monitor

• Outbound bandwidth per bridge. The first real limit.
• Packet loss and jitter reported by clients, a sign of overloaded networks.
• CPU, especially on burstable instances where credit exhaustion looks like sudden lag.
• Conferences and participants per bridge, to check Jicofo is spreading load.

Recent JVB releases expose statistics over a local HTTP endpoint, which Prometheus exporters can scrape and Grafana can graph.

Before you scale, check these

Many “we need to scale” problems are configuration problems:

• 10000/udp blocked for some users, pushing them onto slower fallback paths.
• A burstable instance out of CPU credits.
• Everyone forced into HD with no resolution cap.
• A single region serving users on another continent.

Get help

Scaling is where a few hours of expert review saves weeks. Our scaling service covers load testing, multi-bridge setup, autoscaling and monitoring.