BigBlueButton Server Requirements: A Practical Sizing Guide for 500 Concurrent Users

Example scenario: Imagine a fictional community college that expects 500 people online at once across five classes of about 100 participants each. This is a planning example, not a benchmark, customer story, or test result. The key design choice is to size for multiple meetings spread across several servers; one very large 500-person meeting has a different risk profile.

What does BigBlueButton officially require?

The current BigBlueButton installation guide lists production minimums for a dedicated server: Ubuntu 22.04 64-bit, 8 CPU cores with high single-thread performance, 16 GB memory with swap enabled, and 250 Mbit/s or more symmetrical bandwidth. It calls for at least 500 GB of free disk space when recordings are retained, or 50 GB if recording is disabled. The guide also requires public TCP ports 80 and 443, UDP ports 16384–32768, a hostname and valid SSL certificate, and IPv4 and IPv6 support. These are minimum installation requirements for a server; they do not promise capacity for a particular meeting mix. Check the installation page for the release you plan to deploy, because operating-system and package requirements can change.

The project FAQ has historically described roughly 200 simultaneous users as a rule of thumb for a server meeting minimum requirements. That is a rough planning reference, not a service-level guarantee or a universal per-node limit. BigBlueButton itself warns that server CPU, memory, bandwidth, webcam and screen-sharing use, configuration, and software version change the result. Treat the 200-user figure as an initial hypothesis that your own workload must validate.

A practical starting point for 500 concurrent users

For the fictional college, a reasonable initial architecture to evaluate is a four-node BigBlueButton cluster, with each media node meeting or exceeding the current production minimum and using dedicated, high-frequency CPU. At 500 participants distributed evenly, that is an average of 125 participants per node. The fourth node adds room for uneven meeting placement and maintenance planning; it is not automatic protection for a meeting already running on a failed server.

The four-node recommendation is an engineering starting point inferred from the official minimum configuration and the older 200-user rule of thumb. BigBlueButton does not publish a universal specification that certifies four particular servers for every 500-user workload. For example, if one server is unavailable, the other three would average about 167 of the 500 users only if meetings can be reassigned or users reconnect and the remaining servers stay within their tested limits. An active meeting on a lost node does not transparently migrate to another node. If uptime during node failure is mandatory, test the recovery procedure and consider additional capacity beyond this simple model.

Why five 100-person classes differ from one 500-person meeting

BigBlueButton clusters distribute meetings among servers. They do not combine several nodes into one shared media processor for a single meeting. Five classes of 100 can be placed as whole meetings across four servers, but a single class of 500 would still run on one BigBlueButton server. The project's versioned FAQ advises against treating a single 200-plus-user meeting like ordinary supported use. If the requirement is one audience of 500, validate that exact design with the BigBlueButton team or a qualified provider; consider whether the event can be divided into smaller interactive rooms or delivered as a separate broadcast with limited participant interaction.

The fictional class mix also matters. If most students listen to audio and watch slides while only instructors share webcams, the media load can be much lower than a meeting where many participants publish cameras and screen shares. In its FAQ, BigBlueButton provides illustrative webcam bitrates by resolution and a way to estimate server ingress and egress from the number of publishing webcams and viewers. Use that model to create a first bandwidth estimate, but include audio, signaling, screen sharing, retransmissions, and protocol overhead. Do not multiply 500 by one guessed bitrate and call the result a capacity plan.

Network, rooms, and recordings to include in the design

Give media traffic a direct path

Use a network design that permits browser clients to reach each assigned media node over the required TCP and UDP ports. BigBlueButton's cluster-proxy documentation explains that media streams and WebSocket connections are exchanged directly with the server hosting the conference; the common proxy mainly relays the client interface and related web assets. A reverse proxy that accidentally funnels all media through one small gateway can become the bottleneck. Confirm firewall rules, public addressing, DNS, certificates, and bandwidth in both directions before the load test.

Size recording storage from retention, not attendee count

For the example college, estimate the number and length of recorded classes per day, then measure the size of representative recordings from the actual release and settings. Multiply expected daily output by retention days and add operational margin. The installation guide's 500 GB free-space recommendation is a starting minimum, not a guarantee that a particular retention policy fits. Monitor free space and recording-processing queues, and move archived files only through a tested workflow.

How to validate the estimate before launch

1. Describe the workload. Record expected concurrent users, meetings, users per meeting, webcam publishers and viewers, screen shares, audio usage, recording policy, session duration, and join bursts. Use the five-classes example only if it resembles your real pattern.
2. Choose production-equivalent nodes. Match CPU generation and clock behavior, memory, operating system, network path, storage, and BigBlueButton release. Shared or CPU-throttled instances can behave differently from dedicated compute.
3. Test stepped loads. Begin with a small group, then raise simultaneous attendance in stages while using realistic cameras, audio, slides, screen shares, and recordings. Include a synchronized join period rather than only a steady-state meeting.
4. Watch user-visible signals and server metrics together. Track CPU saturation and run queue, memory pressure and swap, network throughput and packet loss, disk space and I/O, service restarts, and meeting symptoms such as delayed or broken audio, frozen video, failed shares, or reconnect loops.
5. Repeat the peak and recovery tests. Hold the expected peak long enough to expose thermal or memory pressure, then test what happens when a node becomes unavailable. Verify that new meetings route to healthy nodes and document how affected users rejoin.
6. Set a safe operating ceiling. Base the published concurrent-user limit on repeatable tests with spare capacity, not on the first successful run. Re-test after software upgrades, changes to webcam policy, recording configuration, or hosting hardware.

Bottom line for a 500-user deployment

For 500 simultaneous participants across several ordinary meetings, begin evaluation with four dedicated BigBlueButton media nodes, each meeting the official production minimum, and a robust meeting-aware cluster arrangement. Budget network capacity generously, plan recording storage from measured retention needs, and test the exact mix of rooms and media. This design is a sizing hypothesis, not proof that any given cloud instance can sustain 500 users. A single 500-person room is a different workload and should not be inferred from the cluster total.

Official references

• BigBlueButton installation requirements
• BigBlueButton 2.5 FAQ: concurrency guidance and workload variables
• BigBlueButton 4.0 FAQ: bandwidth guidance and webcam bandwidth examples (4.0 is marked in development in the documentation)
• BigBlueButton cluster proxy configuration