# How to scale Jitsi Meet to hundreds of participants > Scale Jitsi by adding more Jitsi Videobridge (JVB) servers, not by making one server bigger. Every extra bridge connects to the same Prosody and Jicofo, and Jicofo spreads conferences across them. Very large single meetings can span several bridges. Watch outbound bandwidth per bridge first, CPU second, and drain a bridge before removing it. Source: https://jitsi.help/guides/jitsi-scaling-videobridge/ Updated: September 26, 2026 Publisher: Jitsi Help (https://jitsi.help/) 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](/services/jitsi-scaling/) covers load testing, multi-bridge setup, autoscaling and monitoring. ## Frequently asked questions ### How many users can Jitsi support? A single well-connected videobridge commonly serves a few hundred concurrent participants, depending on how many people are on camera and the layout they use. Large deployments run many bridges behind one signalling server and host thousands of concurrent users. ### What is the maximum size of one Jitsi meeting? The web client handles meetings of a few hundred participants when most people have cameras off and only a few speak. For very large audiences, stream the meeting to a live platform or use a webinar layout where most attendees are viewers. ### Do I need Kubernetes to scale Jitsi? No. Plain virtual machines running the JVB container, managed by an autoscaling group or a script, are simpler and are what most deployments use. Kubernetes works but UDP media and per-node public IPs make it harder than for typical web apps. --- Jitsi Help is an independent service. It is not affiliated with, endorsed by or sponsored by 8x8, Inc. or the Jitsi project. Jitsi and Jitsi Meet are trademarks of 8x8, Inc., used here only to describe the software we host and support.