How to Install Greenlight v3 with BigBlueButton

01

Choose the supported integration path

The supported colocated path uses the official bbb-install script with the -g option. It is convenient for one BigBlueButton node; choose the isolated architecture below when the frontend needs its own lifecycle or will sit in front of Scalelite.

• Clean supported Ubuntu host and production-ready BigBlueButton prerequisites.
• Public DNS name, ports 80/443 and a trusted certificate path.
• SMTP details and an account-registration policy decided before launch.

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.

sudo bbb-conf --check
# Use the current command from the official bbb-install release and include:
# -g

03

Configure Greenlight

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

   Run the current bbb-install command from the official release branch and include -g.

2. 2

   Open the Greenlight URL, then create an administrator with the documented rake task.

3. 3

   Set SMTP and registration behaviour in the generated environment configuration; restart the containers.

4. 4

   Create one room and restrict registration before publishing the hostname.

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

   Create a room as an administrator and join in a private browser as a guest.

2. 2

   Test microphone, camera, screen share, presentation upload and clean meeting end.

3. 3

   Record a short session and wait for it to publish in the room.

4. 4

   Send an invitation or password-reset email through the configured SMTP relay.

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.

• A 502 response usually means the Greenlight container or reverse-proxy target is unavailable.
• If login email never arrives, inspect SMTP authentication, sender policy and container logs.
• If rooms open but joins fail, compare the configured BBB endpoint with sudo bbb-conf --secret.

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.