Integrate BigBlueButton with Moodle: Step by Step

01

Choose the supported integration path

Moodle 4.0 and later include the certified BigBlueButton activity. Configure its server URL and secret at site level, then add activities inside courses; do not install an unrelated duplicate plugin unless your supported Moodle release requires it.

• Supported Moodle release and site-administrator access.
• BBB or Scalelite API URL and shared secret.
• Cron running reliably so background work is not silently delayed.

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
sudo bbb-conf --secret

03

Configure Moodle

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

   Open Site administration → Plugins → Activity modules → BigBlueButton and replace test credentials with your endpoint.

2. 2

   Set recording, participant and default-role policies conservatively.

3. 3

   In a staging course, enable editing and add a BigBlueButton activity.

4. 4

   Assign moderator and viewer roles deliberately, then save and display.

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

   Join once as teacher and once as student; confirm names and roles.

2. 2

   Verify waiting-room, presentation and end-session permissions.

3. 3

   Record, end, wait for processing and confirm course-scoped playback.

4. 4

   Remove the student from the course and confirm access follows enrolment policy.

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.

• “Invalid secret” can be a missing /bigbluebutton/ path as easily as a wrong secret.
• If the activity is absent, check module enablement and role capabilities.
• Recording visibility depends on processing completion and activity settings.

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.