Capacity engineering
How to size a BigBlueButton server
BigBlueButton sizing is workload modelling, not a users-per-core formula. Start with the classes that overlap, translate their media behaviour into a test profile, then choose hardware with measured headroom.
Executive brief
What matters
- 01
Use peak concurrent participants and published media—not enrolment or monthly active users.
- 02
The official “about 200 concurrent users” rule of thumb is a starting point on compliant hardware, never a guarantee.
- 03
Scale out before normal peaks consume the headroom needed for bursts, maintenance or a failed node.
01
Create a workload table
List each class type with simultaneous rooms, participants per room, webcams normally published, screen sharing, duration and recording. A 150-person lecture with one presenter is not equivalent to six seminars where many people publish webcams. Add a peak overlap window and a growth assumption.
02
Start from the official floor
For BigBlueButton 3.0, current production guidance calls for a clean dedicated Ubuntu 22.04 64-bit host, 8 CPU cores with strong single-thread performance, 16 GB RAM, 250 Mbps symmetric bandwidth and sufficient storage. Recording deployments need substantially more local disk. Cloud instances should use dedicated CPU resources.
03
Test the behaviour that matters
Reproduce the mix of rooms rather than filling one giant room. Include audio joins, webcam publication, screen share, polls, breakout creation and recording processing. Watch CPU saturation, audio quality, packet loss, network throughput, disk space and the delay before recordings become available.
04
Turn results into a scaling threshold
Set a conservative admission threshold below the point where quality degrades. If peaks or availability targets exceed one node, use a pool such as Scalelite and keep spare capacity for a node outage. Revisit the model after version changes, media-policy changes and each academic term.
Evidence base
Sources and further reading
We prefer project documentation and first-party product guidance. Community links are included where they reveal recurring operational questions rather than establish product guarantees.
- BigBlueButton installation requirements docs.bigbluebutton.org ↗ (opens in a new tab)
- BigBlueButton capacity FAQ docs.bigbluebutton.org ↗ (opens in a new tab)
- BigBlueButton monitoring guide docs.bigbluebutton.org ↗ (opens in a new tab)
- Community discussion: recording processing load groups.google.com ↗ (opens in a new tab)
Practical answers
Questions teams ask
How many users can one BigBlueButton server handle?+
Official guidance gives roughly 200 concurrent users as a rule of thumb on a compliant server, but meeting size and media behaviour materially change the result. Validate your own profile.
Does more RAM always increase capacity?+
No. CPU single-thread performance, aggregate CPU, network, disk and meeting behaviour can become the limiting resource first.
Should recording processing run during classes?+
It may overlap in production and can consume resources. Include it in testing, monitor its impact and schedule or architect around predictable peaks.
Continue the research
Related guides and infrastructure
Planning for concurrent BigBlueButton meetings
Plan simultaneous BigBlueButton classes, translate timetables into concurrency, and decide when to add Scalelite nodes.
Read next → Planning & architectureRequirements for a production virtual classroom
Define functional, technical, accessibility, privacy and operational requirements for a production virtual classroom.
Read next → Technical guideHow many users per BigBlueButton server?
Estimate concurrent BigBlueButton users responsibly by accounting for meetings, webcams, screen sharing, recording, CPU and bandwidth.
Read next →