Independent, self-managed infrastructure Read the production requirements

Cluster architecture

Scalelite architecture and operations

Scalelite makes several BigBlueButton servers look like one API endpoint. It is a control plane and recording index—not magic redundancy for meetings already in progress.

01 LMS / Greenlight One standard BBB API endpoint
02 Scalelite + Redis/PostgreSQL Placement, health and recording index
03 BBB node pool Live meetings stay on assigned nodes
04 Shared recording storage Cross-node playback and lifecycle
State and media have different homes in a Scalelite deployment.

Executive brief

What matters

  1. 01

    Scalelite assigns new meetings to a backend; it does not migrate a live meeting after node failure.

  2. 02

    PostgreSQL, Redis and shared recording storage are production dependencies that need their own backup and monitoring.

  3. 03

    Drain nodes before maintenance and keep pool headroom for the lost capacity.

01

Understand placement

Scalelite polls registered BigBlueButton servers, tracks load and directs creation of a new meeting to an available backend. Clients continue through the standard BigBlueButton API contract. Once created, the meeting belongs to that backend for its lifetime.

02

Design the stateful layer

The reference architecture includes PostgreSQL, Redis and a shared NFS-compatible recording volume. Decide who operates each service, where backups live, how restore is tested and what latency or mount failure does to recording import. Keep API secrets and node registration controlled.

03

Standardise node lifecycle

Build identical BBB nodes through documented automation. Register, health-check and load-test a new node before admitting meetings. To patch or retire it, stop new placement, wait for meetings to finish, reconcile recordings, then remove it. Capacity planning must assume a drained or failed node.

04

Monitor outcomes, not only processes

Alert on stale backend polling, API errors, placement imbalance, PostgreSQL and Redis health, shared-volume capacity, recording import delay and frontend join failures. Correlate meeting IDs across Scalelite and BBB logs. A healthy web endpoint is not evidence that recordings or media are healthy.

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.

  1. Scalelite project and architecture (opens in a new tab)
  2. Scalelite issue tracker (opens in a new tab)
  3. BigBlueButton API reference (opens in a new tab)
  4. BigBlueButton monitoring (opens in a new tab)

Practical answers

Questions teams ask

Does Scalelite provide high availability for live meetings?

It improves placement and pool operations, but a meeting on a failed BBB node is interrupted; it is not live-migrated.

Is shared storage optional?

The documented architecture uses shared recording storage so recordings from several nodes can be consolidated. Design and test that layer carefully.

Can Moodle connect to Scalelite?

Yes. Scalelite presents the standard BigBlueButton API, so the frontend can use it as the backend endpoint.