Why scaling self-hosted video conferencing to many concurrent meetings is a different design problem
Capacity is set by concurrent media load, not by how many people have accounts. A timetabled peak, an all-hands or a burst of parallel classes each puts a different load on the media servers, because every active participant sends and receives audio and video streams that the server must process. Jitsi and BigBlueButton scale in different ways. Jitsi scales by adding more Jitsi Videobridge media routers, which the Jitsi scalable setup guide describes as the default horizontal model. BigBlueButton scales by running several whole BigBlueButton servers and placing them behind Scalelite, an open-source load balancer that makes the pool look like one server and sends each new meeting to the least loaded node.
Your regulated and network constraints change this sizing. A bank or health system may need media to stay inside a segmented network, which limits where bridges can sit and how many can be added. Restrictive firewalls push more traffic through TURN relays, and the port plan (UDP ranges for media, TCP 443 for fallback) must be opened on every node in the pool. Those choices change how much headroom each server needs before you can add another.
The facts available to this page do not give a capacity figure per server for any particular meeting mix, and that figure varies with video on or off, screen sharing, recording and the number of participants per room. Treat it as something to measure. Run a load test with your own meeting profile on a server built the way you will deploy it, record CPU, memory, bandwidth and packet loss at the point where quality degrades, and ask any implementation partner to show the same test results for your scenario before you commit to a server count.
Which requirements drive capacity for a regulated organization
This table maps each regulatory and network requirement to the capacity it adds to a self-hosted meeting platform. Read each row as a sizing input: the requirement itself, what it asks for, and what it changes in servers, bandwidth, ports or storage. The main takeaway is that compliance obligations raise the load on media, logging and storage, so they belong in the capacity plan from the start.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| Peak concurrent meetings and classes | Your own count of simultaneous meetings or classes at the busiest hour, plus average participants per meeting | Sets the number of Jitsi videobridges or BigBlueButton servers. Confirm peak figures from your calendar and timetable data before requesting a quote. |
| HIPAA 164.312(e)(1), transmission security for ePHI | Technical measures that guard against unauthorized access to ePHI sent over a network | Encrypted media and signaling add CPU load per stream. Valid domain certificates are required, so plan certificate issuance and renewal for every media node. |
| HIPAA 164.312(b), audit controls | Mechanisms that record and examine activity in systems that hold ePHI | Session, join and access logs grow with concurrency. Size log storage, retention and the monitoring stack alongside the media servers. |
| SEC 17a-4(b)(4), records retention | Preservation of communications that are business records for at least three years | Where meeting recordings or chat transcripts are records, storage grows with the number of recorded sessions. Size archive capacity and backup copies, not only live disk. |
| Jitsi HTTPS certificate requirement | A proper domain certificate for working audio and video, since self-signed certificates cause problems | Each public entry point needs a trusted certificate. Internal CA use must be confirmed with clients, especially mobile users, before rollout. |
| BigBlueButton UDP 16384 to 32768 and TURN | Those UDP ports open to media, plus a TURN server recommended for users behind restrictive firewalls | Port range sets the firewall rules for each server. Users behind strict firewalls need TURN capacity sized separately, since relayed media consumes more bandwidth. |
| Bandwidth per BigBlueButton 4.0 server | 250 Mbit/s symmetrical bandwidth, per the BigBlueButton 4.0 install documentation | Use this as the minimum baseline per server. Confirm your provider's uplink and egress costs, since sustained concurrency drives total bandwidth. |
How Jitsi videobridges scale horizontally
A Jitsi Meet deployment is made of several cooperating services rather than one application. A web server (nginx or Apache) serves the web app that participants load in their browser. The Prosody XMPP server handles signaling and account and room state. Jicofo, the conference focus, decides which conferences exist and asks a bridge to host each one. Jitsi Videobridge (JVB) is the media router that carries the audio and video streams. Scaling is mostly a question of how many JVB instances you run, because the other services are shared control-plane components.
- Web server: serves the web app over HTTPS, so the certificate and domain must be right before any media testing.
- Prosody: manages XMPP signaling for rooms and authenticated users.
- Jicofo: selects a videobridge for each conference and is the component to study when you test distribution.
- Jitsi Videobridge: routes media between participants and is the unit you add when capacity runs short.
- Central server sizing: the handbook's scalable setup suggests a 4 CPU, 8 GB machine for the central services.
Before you size anything, map which of these services run on which hosts in your design and where each one listens.
Check that your planned hosts match the supported operating systems in the Jitsi scalable setup guide and the self-hosting handbook.
The Jitsi scalable setup guide states that videobridges scale horizontally by adding more of them, and it notes that the default install is already configured for horizontal scaling. The handbook suggests 4 or 8 CPU cores with 8 GB RAM for each videobridge. These are starting points from the vendor documentation, not a capacity guarantee, because real load depends on the number of participants per meeting, video quality settings, simulcast use and the codec mix on your clients.
- Starting size: plan each bridge at 4 or 8 CPU with 8 GB RAM, then measure before you settle on a number.
- Horizontal growth: add bridges as separate hosts when meetings or concurrent participants rise.
- Distribution logic: confirm with your own tests how Jicofo chooses a bridge for each new conference and whether it balances by load.
- Load testing: run scripted meetings at your expected peak with realistic video, then record CPU, bandwidth and packet loss per bridge.
- Documented defaults: do not assume the defaults match your topology until you have checked the configuration on your build.
Ask your implementation partner to show the distribution behavior in a test run before the design is signed off.
Each videobridge needs its media port reachable from participants. The Jitsi Debian and Ubuntu quick start requires 10000/UDP open for media, along with 80/TCP and 443/TCP for the web app. It also lists 5349/TCP for TCP fallback and 3478/UDP for STUN as optional. When you add bridges, every one of them needs its own reachable media path, which changes firewall rules, load balancer placement and public addressing for each host. Port planning is therefore a per-bridge task, not a one-time task.
- Media port: 10000/UDP must be open on every videobridge, so each bridge needs a routable address or a documented NAT mapping.
- Web ports: 80/TCP and 443/TCP serve the web app, and HTTPS needs a proper domain certificate.
- Fallback paths: 5349/TCP for TCP fallback and 3478/UDP for STUN are optional, but users behind restrictive firewalls may depend on them.
- Supported platforms: the quick start supports Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer, and requires OpenJDK 17.
- Bandwidth: the handbook does not give a per-bridge bandwidth figure in the supplied facts, so ask your partner to derive it from load tests.
Confirm each bridge's port reachability from the networks your users actually use, not only from the lab.
The official Docker setup separates the services into containers: web, prosody, jicofo, jvb, jigasi (the SIP gateway) and jibri (recording and streaming). Because jvb is its own container, you can run bridges on separate hosts and scale them independently of the web and control services. Since release stable-11146, the containers run rootless with read-only filesystems, which reduces the privileges each service needs. Configuration for the stack is kept in an .env file, so bridge settings must be kept consistent across hosts.
- Separate jvb container: each host running a bridge runs its own jvb container alongside its required networking.
- Rootless operation: containers run rootless with read-only filesystems from stable-11146 onward.
- Configuration file: the
.envfile holds the stack settings, so keep it under version control and review changes per host. - Optional services: jigasi and jibri are separate containers and add load of their own, so size them independently.
- Image pinning: pin the image tag you test and confirm how your registry mirror handles updates.
Confirm with your partner which containers run on which hosts and how the bridge containers are upgraded without interrupting active meetings.
Jitsi or BigBlueButton for high concurrency: which fits which load
Jitsi Meet and BigBlueButton scale in different ways, so the right choice depends on the shape of the load as much as its size. The cards below separate ad hoc meeting traffic from timetabled classes, and they flag the managed and public options that change the capacity math.
Jitsi Meet for many small conferences
Jitsi Meet fits a large number of short, unscheduled meetings where each room holds a modest number of participants. Its Jitsi Videobridge media routers scale horizontally, so capacity grows by adding bridges behind the same Prosody, Jicofo and web layer. The project's scalable setup guide suggests 4 or 8 CPU with 8 GB RAM for each bridge. Check how many concurrent conferences each bridge carries under your own load tests, and confirm that UDP 10000 is reachable on every bridge. Licensed under Apache-2.0.
BigBlueButton for scheduled classes
BigBlueButton is built for sessions that need polls, a multi-user whiteboard, shared notes, breakout rooms and recording in one room. Load comes in predictable bursts at class start times, so capacity is usually planned per server and pooled. Scalelite, an open-source load balancer, presents a pool of BigBlueButton servers as one endpoint and sends each meeting to the least loaded server. Licensed under LGPL-3.0. Confirm the sizing of each media server before the timetable peaks.
Running both platforms side by side
A mixed pattern keeps ad hoc collaboration on Jitsi and timetabled teaching on BigBlueButton, so each workload is sized on its own curve. The cost is two sets of servers, two upgrade cycles and two authentication configurations to keep aligned. Decide early which users are routed to which platform and whether one identity source serves both. Test failover paths for each stack, since an outage in one should not take down the other.
JaaS as a managed alternative
JaaS, the Jitsi as a Service offering from 8x8, runs the Jitsi stack for you, which shifts server, bridge and upgrade work to the vendor. Weigh it against self-hosting by asking where media is relayed and recorded, who holds the encryption and recording keys, and how capacity is guaranteed at peak. Self-hosting keeps those answers inside your own infrastructure, but it also keeps the operating burden. Confirm the data location and support terms in writing before you compare costs.
The public meet.jit.si instance
The free public instance at meet.jit.si is a shared service that the project runs for public use, and it is not a platform your organization controls. It offers no capacity commitment, no authentication you configure, and no record of who joined which room. Regulated teams should use it only for informal testing, never for internal or client meetings, and should confirm that their own deployment does not default to it. Load tests should target your own bridges, not the public service.
Greenlight and LMS session creation
Front ends such as Greenlight v3 and LTI connections from a learning management system create BigBlueButton sessions on demand, so a course start can trigger many create calls within seconds. Session creation rate, not only concurrent media load, often sets the peak your servers must absorb. Greenlight v3 supports external login through OpenID Connect, which adds an identity dependency to that path. Test the create-meeting rate from your LMS during a timetable simulation.
Rollout: from a measured baseline to a monitored pool
This sequence moves a deployment from measured demand to a sized, tested and monitored pool of Jitsi videobridges or BigBlueButton servers. Each phase ends with a named output that the operations team can review and reuse at the next capacity review.
Measure current and peak concurrency
DeployOpen's engineers work with your team to pull meeting history from existing logs, calendars, LMS timetables or a short pilot, then record peak concurrent meetings and peak concurrent participants by hour, day and term. The output is a sizing workbook with the raw counts, the peak windows and the assumptions behind them. You know this step is done when the workbook explains every peak with a source, and your team can point to the timetable or event that caused it.
Define the meeting profile
Next, agree on a meeting profile for each use: typical participant count, share of participants sending video, screen-share frequency, and the share of meetings that record or stream. Recording share matters because it adds storage and CPU load that does not appear in participant counts. The profile is recorded in the sizing workbook as separate rows for each meeting type, such as advisory calls, town halls and classes. The step closes when every meeting type has a profile signed off by the business owner.
Build the load test and rehearsal plan
Build a synthetic load test that replays the meeting profiles against a staging pool, using test clients that join, publish video and leave on a schedule. Include a rehearsal of the busiest window, with the same network paths and firewall rules as production. Confirm the test tooling with your vendor or implementation partner before use, and agree a stop condition in writing. The output is a rehearsal plan with pass criteria and a list of the metrics captured during each run.
Size the first pool and network path
Size the first pool from the profile and the load test results, then document the network path. For Jitsi, this covers the videobridge count, the central server and the UDP media path. For BigBlueButton, it covers the server count, the Scalelite front end and each server's CPU, memory, disk and bandwidth. Produce a tested port map that lists the TCP and UDP ports for each component, including the TURN path for users behind restrictive firewalls, and confirm it with the network team. The step closes when the port map has been tested from outside the network, not only inside it.
Put monitoring and alert thresholds in place
Deploy metrics collection on every media server, the signaling or front-end layer and the recording storage, then set alert thresholds for CPU, memory, bandwidth, concurrent meetings per server and failed joins. Thresholds are written as numbers in the runbook, based on the load test pass criteria rather than defaults. The alerts should route to a named on-call group that knows the escalation path. The output is a dashboard, the alert threshold table and a tested alert that reaches the on-call group.
Run a staged cutover
Move meetings to the new pool in stages, starting with low-risk groups such as internal team meetings, then extending to larger or external meetings once the dashboard stays within thresholds. Keep the previous setup available until the cutover is accepted, and record each stage in the runbook with the date, the groups moved and any incidents. A stage is complete only when the monitored metrics stay within threshold through a full peak window. Confirm with the business owner before the next stage starts.
Set the capacity review cadence
Finish by setting a recurring capacity review that compares actual peaks, alert history and recording growth against the sizing workbook. Agree the review interval and the trigger conditions for an unscheduled review, such as a new client group or a new term timetable, with the owners. Update the runbook and the sizing workbook after each review, and keep upgrade windows out of known peak periods. The output is a dated review record and an updated workbook that shows whether to add capacity.
Evidence that capacity and monitoring controls exist
This table lists the records an assessor or internal reviewer would ask for to show that video capacity was planned, watched and changed under control. Each row names the evidence, what it demonstrates and the component that produces it. DeployOpen prepares this evidence, but independent auditors and certification bodies draw the conclusions.
| Evidence item | What it shows | Which component produces it |
|---|---|---|
| Load test reports per pool | Concurrent meeting counts each Jitsi videobridge pool or BigBlueButton server group handled, with CPU, memory and bandwidth at the point of failure | Load test harness run against the production-like pool before go-live and after each capacity change |
| Monitoring dashboards and alert history | Utilization trends for videobridges and BigBlueButton servers, and the dates alerts fired for threshold breaches | Metrics collection and dashboard tooling on the media hosts, with alert logs retained outside the hosts |
| Audit logs under HIPAA 164.312(b) | Who accessed systems holding ePHI in meeting or recording storage, and when, where a healthcare deployment applies | Host and application logging for the video stack, forwarded to a central log store with access controls |
| Recording storage capacity records tied to SEC 17a-4 retention | Storage allocated for recordings, growth against the 500 GB per BigBlueButton server recording guidance, and retention settings applied (where broker-dealer communications are recorded) | Storage monitoring and retention configuration on recording volumes, plus the documented retention policy |
| Change records for scaling and upgrades | Each added videobridge or BigBlueButton node, version changes (for example, moving to BigBlueButton 4.0.0), approver and the rollback plan | Change tickets in the client's change management system, linked to deployment logs and configuration management history |
| Firewall and port configuration records | Open TCP 80, 443 and UDP 10000 for Jitsi or UDP 16384 to 32768 for BigBlueButton, plus TURN paths, matched to the approved design | Firewall rule exports, infrastructure-as-code definitions and periodic port scan results from the test environment |
Common questions about scaling self-hosted video conferencing
What drives the cost of scaling self-hosted video conferencing?
Cost is driven by the number of concurrent meetings or classes at peak, the media servers needed to carry them, and the bandwidth those servers use. The one-time costs are the design, the initial build, load balancer and monitoring setup, and any hardening or integration work. The recurring costs are the servers and bandwidth you keep paying for, patching and upgrades, monitoring, and support. Ask any partner for a quote that separates these items, states the peak concurrency it was sized for, lists the server counts and specifications for each role, and names who pays for hosting, licenses and support. Recording storage is a separate line that grows with usage and retention. A quote should also state whether recording and TURN servers are included.
How long does a video conferencing scaling project take?
The duration depends on how many media servers you need, how much of the network and firewall work is already done, whether you need recording or TURN servers, and how many authentication and integration points are involved. Timelines should be stated in the written scope, not assumed from a generic estimate. Ask for the phases, the dependencies you must provide (network changes, certificates, DNS and firewall approvals), the test and load-test window, and the cutover plan around scheduled classes or meetings. Because BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0 and recommends a clean installation, a migration from an older release typically adds planning time that the quote should show explicitly.
What does the client need to provide for a scaling project?
Most of the work depends on access and data from your side. Plan to provide network access to the target hosts, firewall changes that allow the required ports, a valid hostname and certificate for each public endpoint, and a representative record of peak usage. For Jitsi the core ports are 80/TCP, 443/TCP and 10000/UDP, with 5349/TCP for TCP fallback and 3478/UDP for STUN optional. For BigBlueButton, ports 80 and 443 over TCP and UDP 16384 to 32768 must be reachable. You also need change approvals, a maintenance window, and decisions on recording retention and authentication. Ask the partner to list every request in writing before work starts.
Can our internal team scale Jitsi or BigBlueButton without a partner?
Yes, many teams with Linux, networking and container experience can run these platforms, and the official guides are detailed. The question is whether your team can carry the load on an ongoing basis. Scaling needs capacity planning, load testing, firewall and UDP port management, certificate renewal, upgrade planning, and on-call response when a media server fails during a class. Before deciding, check whether your team has the skills for each role, can staff a test environment that matches production, and has time for upgrades on a schedule that avoids timetabled peaks. A partner can take on any part of that scope in writing, such as design, implementation, hardening, testing or a retainer for ongoing support.
How does Scalelite choose a BigBlueButton server for a meeting?
Scalelite is an open-source load balancer that makes a pool of BigBlueButton servers appear as one, and it sends each new meeting to the least loaded server. Operators therefore need to check how load is measured, how servers are added to and removed from the pool, and how the system behaves when a server is down. Ask the partner to show the server registration and health checks, to demonstrate how a meeting is placed during a load test, and to explain how recordings and playback are routed across servers. Confirm that every BigBlueButton server in the pool meets the 4.0.0 requirements, including 16 GB of RAM with swap and 8 CPU cores with high single-thread performance.
How do you know when to add video conferencing capacity?
You know it is time to add capacity when peak load approaches what the current servers can carry with headroom, and when quality problems appear at busy times. Watch CPU and memory on each Jitsi videobridge, the number of active meetings and participants, bandwidth in and out on each media server, and the failure rate of joins and media connections. For Jitsi, the scalable setup guide says videobridges scale horizontally by adding more, and the default install is already configured for that. For BigBlueButton, track server load against the sizing in the install documentation. Set alert thresholds in the design phase, and run a load test before every timetabled peak to confirm the thresholds still hold.
How do you estimate bandwidth for many concurrent meetings?
Bandwidth depends on the number of participants per meeting, the video quality you allow, whether participants send video or only receive it, and whether screen sharing, recording or streaming is active. Estimate it per server and per site, then add headroom for peaks. Your data should include real peak concurrency and participant counts from your calendar or LMS. For BigBlueButton 4.0, the install documentation lists 250 Mbit/s symmetrical bandwidth per server as a minimum, which is a baseline, not a sizing result for your load. Ask the partner for the assumptions behind any estimate, the traffic model used for each media server, and a load test that confirms the numbers in your network before go-live.
What to ask an implementation partner before sizing a pool
Ask the partner first how they measure peak concurrency before they propose any hardware. A credible answer names the meeting profile they assume: participants per meeting, share of video versus audio-only, screen sharing, and how many classes or meetings start in the same five-minute window. Ask whether they will model timetabled peaks such as the top of the hour, and whether they will validate the profile against your calendar or LMS data. For BigBlueButton, ask how they map that profile to the 8 CPU core, 16 GB RAM server baseline in the BigBlueButton install documentation, and whether they will load test that baseline before it is accepted. For Jitsi, ask how many videobridges they start with, what the test plan is for a single bridge at target load, and how they confirm the 4 or 8 CPU, 8 GB sizing from the Jitsi scalable setup guidance holds for your media mix.
Ask how load balancing is configured and what happens when a node fails. For BigBlueButton pools, ask whether Scalelite is set up with a documented path to add and drain servers, how the least-loaded placement is monitored, and what happens to meetings already in progress when a server is removed. For Jitsi, ask how Jicofo distributes conferences across bridges, how a failed bridge is detected, and who owns the health checks. Ask about the firewall plan in concrete terms: UDP 10000 for each Jitsi videobridge, the UDP 16384 to 32768 range for BigBlueButton media, TCP 443 and the TURN path for users behind restrictive networks, and whether the partner will confirm these ports against your firewall policy before go-live. Finally, ask how recording storage scales: where recordings land, how capacity is projected per term or per month, how storage is monitored, and whether recording runs on the media nodes or on separate storage. Last, ask how upgrades are scheduled around classes and meetings, including the rule that BigBlueButton 4.0 requires a clean installation and does not support direct upgrades from earlier branches, and what the rollback plan is.
