Scalable BigBlueButton Hosting Explained: From Single Server to Intelligent Clusters

A deep dive into video conferencing infrastructure: Understanding the shift from monolithic servers to self-healing, high-availability clusters.


BigBlueButton has established itself as the premier open-source solution for virtual classrooms and conferences. However, as organizations grow, they inevitably hit a "performance wall." The question shifts from "How do I install it?" to "How do I host 2,000 concurrent users stably?"

Scaling BigBlueButton is not just about adding more CPU power to one machine (Vertical Scaling); it requires a fundamental change in architecture (Horizontal Scaling). Below, we explain the three stages of hosting evolution.

01

The Single-Server Setup

In a standard "monolithic" installation, every component resides on a single physical or virtual machine. This includes the HTML5 client, the Kurento/MediaSoup media server, Redis, and the whiteboard database.

The Analogy: A Small Café

Think of a single server like a neighborhood café with one barista. It works perfectly for 50 to 200 customers. Service is fast and direct. But if 500 people try to enter at once, the line goes out the door, orders get mixed up, and the system slows to a crawl.

Technical Bottleneck: Node.js, which powers the BigBlueButton HTML5 client, is single-threaded. Even if you have a 64-core server, a single meeting with too many users can saturate the main thread, causing lag for everyone. Usually, the practical limit is 200-300 concurrent users per server.
02

The Open-Source Cluster: Scalelite

To bypass the single-server limit, the community developed "Scalelite." Scalelite is a load balancer that sits between your frontend (Moodle/Greenlight) and a pool of BigBlueButton servers.

How Scalelite Works

Scalelite relies on a complex stack involving a PostgreSQL database to track meetings and Redis for caching. It periodically polls the registered servers to check their CPU load and user count. When a new meeting request comes in, Scalelite directs it to the least busy server.

  • Horizontal Scaling: You can theoretically add an infinite number of servers to the pool.
  • The Recording Nightmare: A major headache with Scalelite is recording management. Because meetings are scattered across different servers, you must set up complex shared storage systems (NFS or S3) to aggregate recordings. If a server fails before the recording is transferred, the data is often lost.
The Analogy: The Hotel Receptionist

Scalelite acts like a hotel receptionist. Guests arrive at the front desk, and the receptionist assigns them a room (server). However, keeping track of "lost & found" items (recordings) from hundreds of different rooms becomes a logistical struggle.

The Limitation: Scalelite modifies API requests before passing them to the servers. This often breaks compatibility with specific 3rd party integrations that expect a direct connection to a standard BigBlueButton API.
03
Recommended Solution

The Next Level: bbbserver Intelligent Balancing

At bbbserver, we recognized the limitations of standard Scalelite setups. We built a proprietary load balancing architecture designed for maximum stability, hygiene, and transparency.

Solved: Recording Collection

We have completely eliminated the "missing recording" issue found in standard clusters. Our system automatically harvests, processes, and centralizes recordings from all nodes without requiring fragile NFS mounts. You get a single, reliable repository for all your data.

The 24-Hour Reinstall Cycle

BigBlueButton servers accumulate "digital dust"—temp files and memory leaks—over time. Our unique "Fresh Start" protocol automatically drains servers and completely reinstalls the software every 24 hours. You are essentially getting a brand new server every single day.

100% API Compatibility

Unlike Scalelite, which can mask API functions, our intelligent balancer offers 100% pass-through compatibility. Whether you use a custom Moodle plugin, a corporate LMS, or a specialized script, it will work exactly as if connected to a single server.

Self-Healing Infrastructure

If a node reports a Kurento error or audio lag, our system instantly isolates it, moves it to maintenance mode, and spins up a replacement within minutes. No manual intervention required.

The Analogy: The Self-Cleaning Luxury Resort

Imagine a resort where, after every guest leaves, the room isn't just cleaned—it is completely renovated. The concierge (our Load Balancer) also ensures all guest luggage (recordings) is automatically transported to the main lobby, so nothing is ever left behind in the rooms.

Frequently Asked Questions on Scaling

A reboot clears memory (RAM), but it does not fix configuration drifts, corrupted temp files, or updated package dependencies. A full reinstall ensures the software stack is identical to our "Golden Image," eliminating 99% of "random" bugs.

No. Unlike self-hosted Scalelite setups where you need to manage NFS mounts and transfer scripts, bbbserver handles the entire lifecycle. We collect the raw data, process the recording, and serve it to you seamlessly.

Absolutely. Since our system is 100% API compatible, migration is usually as simple as changing the "Base URL" and "Secret" in your LMS or frontend application.

Experience the Stability of a "Fresh" Server

Stop worrying about load balancing configurations, database syncing, and API conflicts. Switch to bbbserver for a managed, self-healing cluster environment.

View Plans & Pricing