How to Install Scalelite for a BigBlueButton Cluster

01

Choose the supported integration path

Scalelite is an API-compatible load balancer, not a media proxy. It selects a healthy backend for a new meeting while the browser continues to exchange media with that BigBlueButton node.

• At least two compatible BBB nodes with unique hostnames.
• PostgreSQL, Redis and shared NFS storage sized and backed up.
• A public Scalelite hostname with HTTPS and monitoring.

02

Prepare BigBlueButton and credentials

Use a production BigBlueButton endpoint with a trusted TLS certificate. Keep the API shared secret or LTI secret on the server side: it is equivalent to an application credential and must never be placed in browser code, a public repository or a screenshot.

1. 1

   Confirm the BigBlueButton server is healthy and that its public hostname resolves correctly.

2. 2

   Retrieve the API URL and shared secret with sudo bbb-conf --secret, or create a dedicated LTI key and secret where the integration uses LTI.

3. 3

   Record the platform version, connector version, owner and rollback point before making the change.

docker compose ps
# In the Scalelite container, list registered servers:
bundle exec rake servers

03

Configure Scalelite

Make the first connection in a staging course, workspace or tenant. Use a dedicated test teacher and test learner so role mapping can be observed rather than inferred from an administrator account.

1. 1

   Deploy the released Scalelite container stack and set LOADBALANCER_SECRET, DATABASE_URL, REDIS_URL and shared storage paths.

2. 2

   Mount the same recordings spool and published directories expected by the recording importer.

3. 3

   Use the rake command documented by Scalelite to add each BBB URL and secret.

4. 4

   Enable nodes one at a time and confirm their load and online state before exposing the endpoint.

04

Run an end-to-end acceptance test

A green “connection successful” message proves only that one API request worked. The useful test follows the complete classroom lifecycle from creation through recording publication.

1. 1

   Point API Mate or a staging frontend at Scalelite and create several uniquely named meetings.

2. 2

   Confirm meetings spread across enabled nodes and each running meeting remains pinned to its node.

3. 3

   Record on more than one backend and confirm playback becomes available through the load balancer.

4. 4

   Disable one idle node, then prove no new meeting is assigned to it.

05

Common problems and practical fixes

Start with timestamps, browser developer tools and the logs on both sides. Repeatedly replacing secrets rarely fixes a hostname, TLS, role or callback problem and makes the evidence harder to follow.

• An online node with stale load data may have broken polling or network reachability.
• Recordings missing from Scalelite usually indicate NFS permissions, mismatched paths or importer failure.
• Never clone a BBB node without regenerating identity, hostname and API credentials.

06

Production hardening and upgrades

Restrict who can create rooms, define recording retention, test accessibility and document the integration owner. Pin or approve connector updates, subscribe to upstream releases and repeat the acceptance test after changes to the LMS, connector, BigBlueButton or reverse proxy.

• Do not expose the BigBlueButton shared secret to course authors or client-side JavaScript.
• Use least-privilege teacher roles and test guest, suspended and unenrolled users.
• Monitor API errors, failed joins, recording processing and disk growth.
• Keep a short rollback runbook: previous package, configuration backup and maintenance window.