Install Greenlight v3 on an Isolated Server

01

Choose the supported integration path

Use the official standalone Greenlight installer. Its -s option defines the Greenlight hostname; -b receives the BigBlueButton hostname and secret. For a cluster, supply the Scalelite API endpoint and load-balancer secret instead of a backend node.

• Separate Linux host with Docker, DNS and HTTPS.
• Reachable BigBlueButton or Scalelite API endpoint.
• Backups planned for Greenlight data and environment secrets.

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 --secret
# On the Greenlight host, use the current official gl-install command:
# gl-install.sh -s rooms.example.org -e admin@example.org -b bbb.example.org:SECRET

03

Configure Greenlight isolated

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

   Retrieve the target API endpoint and secret, then run the official gl-install script with -s, -e and -b.

2. 2

   Create the initial administrator using the rake task inside greenlight-v3.

3. 3

   Configure SMTP and, if required, OpenID Connect in /root/greenlight-v3/.env.

4. 4

   Back up the environment file and database, then document restore ownership.

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

   From Greenlight, create and join a room on the target BBB service.

2. 2

   Confirm the browser connects directly to the assigned media node when Scalelite is used.

3. 3

   Publish a recording and verify it returns to the Greenlight room.

4. 4

   Reboot only the Greenlight host and verify BBB meetings remain unaffected.

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.

• Incorrect -b formatting causes API connection failures; use hostname:secret without publishing it in shell history where practical.
• TLS name mismatches between the configured endpoint and certificate cause misleading connection errors.
• An isolated frontend is not highly available until its database, storage and proxy are designed accordingly.

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.