How the Moodle and BigBlueButton integration keeps class video in your infrastructure
The Moodle and BigBlueButton integration connects a Moodle course to a BigBlueButton server that your institution operates, so live classes and recordings stay on infrastructure you control. The connection is the BigBlueButton activity, which ships in Moodle core since Moodle 4.0, and it does not depend on a third-party video cloud. Moodle does not host the video itself. It creates sessions, decides who may join and lists recordings in the course, while the media runs through your BigBlueButton server. That split puts the server, the network path and the shared secret at the center of the work. Moodle is licensed under GPL-3.0 and BigBlueButton under LGPL-3.0. BigBlueButton is also embedded in other learning management systems, including Canvas, Sakai, D2L and Schoology, according to the project, so the server design does not have to be specific to Moodle.
Start with the server, because its size sets the hardware and disk plan for everything else. BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit, and the project does not support direct upgrades from 2.6, 2.7 or 3.0, so plan a clean installation. The install documentation lists at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance and 250 Mbit/s of symmetrical bandwidth. Disk depends on your recording policy: the documentation lists 500 GB for recordings and 50 GB without recording. Decide how long recordings must be kept, because that decision determines which disk figure applies. Size for the peak number of concurrent classes shown in your timetable, and confirm every figure against the documentation for the exact version you deploy. If peak load exceeds one server, ask whether a multi-server setup such as Scalelite fits your design and confirm its current support.
The network path is where first deployments most often fail. BigBlueButton needs TCP ports 80 and 443 and UDP ports 16384 to 32768 reachable, a valid hostname for SSL, and Docker for sandboxed LibreOffice document conversion. The documentation recommends a TURN server for users behind restrictive firewalls, which is common on campus and in hospital networks. Decide early who owns the public DNS record and the certificate, whether a reverse proxy sits in front of the server, and whether the UDP range can be opened on the firewalls your students actually use. Ask your network team for their approval lead time before the build plan is fixed, and test from a student network, not only from a staff laptop on the campus LAN.
The shared secret is the trust boundary between Moodle and the server. Every BigBlueButton API call carries a checksum computed from that secret, using SHA-256 by default, SHA-1 for legacy use, and SHA-384 or SHA-512 since version 2.5. The documentation warns never to embed the secret in a web page, so the value must stay in Moodle's server-side configuration and out of theme code, templates and course content. Decide who can read and change that setting, where Moodle database backups are stored and who can restore them. Plan how the secret is rotated after an administrator leaves. Confirm which checksum algorithm your Moodle release sends and that your BigBlueButton server accepts it before go-live.
What you need in place before connecting Moodle to BigBlueButton
Connecting Moodle to a self-hosted BigBlueButton server depends on six prerequisites: a Moodle release with the activity, matching PHP and database versions, a web root configured for Moodle 5.1 onward, a clean BigBlueButton 4.0 server, its hardware, and its network path. Confirm the Moodle and BigBlueButton version pairing in both vendors' documentation before you order hardware.
A Moodle release with the activity
Choose a Moodle release that includes the BigBlueButton activity in core, which has shipped since Moodle 4.0. Check the release's support window against your teaching calendar. Moodle 4.5 is a long-term support release with security support until 4 October 2027, and Moodle 5.3 is the next long-term support release. Confirm that the activity is available and enabled on the exact version you plan to install.
PHP and database versions
Each Moodle release sets its own minimum PHP and database versions, so read them for your chosen release before you build the Moodle server. Moodle 5.1 requires 64-bit PHP 8.2 or later, with 8.3 and 8.4 supported, and PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or Microsoft SQL Server 2017 or later. Moodle 5.3 requires 64-bit PHP 8.3 or later and PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019 or later.
Document root for Moodle 5.1 onward
From Moodle 5.1, the web server document root must point to the new /public directory inside the Moodle code. If it does not, the site may show directory listings or errors. Set this in the virtual host configuration before the first login test, and repeat the check after every upgrade and web server change. Ask the person who will own the web server to confirm the path in writing.
A clean BigBlueButton 4.0 server
BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit. Direct upgrades from 2.6, 2.7 or 3.0 are not supported, so build a new server rather than upgrading an existing one. Plan for Docker on the same server, because BigBlueButton uses it for sandboxed LibreOffice document conversion. Decide early whether Greenlight or LTI support will run on the same host, since the install script can add either. Confirm the steps against the current install documentation before you start.
Compute, memory and disk minimums
A BigBlueButton 4.0 server needs at least 16 GB of RAM with swap configured and 8 CPU cores with high single-thread performance. Disk needs are 500 GB if you record sessions and 50 GB if you do not. Recordings drive disk growth, so set the recording policy and retention period before ordering hardware. Ask the provider to state the CPU model and confirm its single-thread performance, since core count alone does not show that.
Network, ports and hostname
Open TCP 80 and 443 and UDP 16384 to 32768 so browsers and the media path can reach the server. The server needs a valid hostname for SSL, so reserve a DNS name before installation. Provision 250 Mbit/s symmetrical bandwidth for the server. A TURN server is recommended for users behind restrictive firewalls, so plan one if your students or staff use networks that block UDP. Confirm the firewall rules with your network team before the first class.
Configuration sequence for the Moodle BigBlueButton integration
This sequence takes a clean BigBlueButton 4.0 server from installation to a verified class session in a Moodle sandbox course, then connects the server to the Moodle activity with a protected shared secret. Each step closes with a check, so the team confirms one layer works before changing the next. The result is a documented configuration with a tested rollback path for every change.
Build a clean BigBlueButton 4.0 server
The systems team installs BigBlueButton 4.0 on a new Ubuntu 24.04 64-bit server. Direct upgrades from 2.6, 2.7 or 3.0 are not supported, so the build starts clean. Size the host against the install documentation, which lists at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk if recording is enabled (50 GB without) and 250 Mbit/s symmetrical bandwidth. Give the server a hostname that resolves from outside the network and issue a valid SSL certificate for it. Check: the hostname resolves publicly and the certificate chain validates in a browser and in an external SSL test.
Open required ports and test reachability
The network team allows inbound TCP 80 and 443 and UDP 16384 to 32768 through the host firewall, cloud security groups and any upstream load balancer. Media travels over the UDP range, so that range needs its own test. Test each port from a location outside your network, because a rule that works on the host can still be blocked upstream. Check: an external scan or a test call from outside your perimeter reaches the login page over HTTPS, and audio and video pass through the UDP range. Record each rule and its owner in the change log.
Install Docker and confirm document conversion
The systems team installs Docker on the BigBlueButton server, which the install documentation requires for sandboxed LibreOffice document conversion. In a test room, upload one PowerPoint file and one PDF, then confirm each displays as slides for the presenter and a second participant. If a file does not render, check the server logs before changing any setting. Check: both test files display correctly for every participant. Record the installed Docker version in the configuration notes so later upgrades can be compared with this baseline.
Decide on TURN and optional components
The team decides whether users behind restrictive firewalls need a TURN server, which the install documentation recommends for those networks. Test a session from such a network, such as a guest Wi-Fi or a corporate network with strict outbound rules, to see whether audio and video connect without TURN. The team also decides whether to add Greenlight or LTI support, which bbb-install.sh can install on the same server. Record every component that runs on the server with its version, so patching and backups cover all of them. Check: a session from the restricted network connects, and the component inventory matches what is installed.
Store the server URL and shared secret
The administrator records the server URL and the shared secret in the configuration notes. BigBlueButton computes a checksum on every API call from that secret, so anyone who holds it can make authenticated calls against the server. Store the secret in an approved secrets store with restricted read access and a named owner responsible for rotation. Keep it out of Moodle course content, activity descriptions, shared documents and any web page the browser loads. Check: a search of the course and the activity description finds no copy of the secret, and the secrets store lists who can read it.
Enable the activity and set server details
A Moodle administrator enables the BigBlueButton activity in the site administration area. The activity ships in Moodle core from version 4.0, so confirm the Moodle version your site runs before the change. Enter the server URL and the secret from the secrets store in the activity's server settings, and confirm the secret is not copied into any course-level field. Check: a test activity in a sandbox course opens a room without a server connection error.
Test a session with teacher and student accounts
The tester creates a test activity in a sandbox course, then joins it twice, once with a teacher account and once with a student account, each in a separate browser. Check audio in both directions, webcam video, slides with an annotation, and chat messages sent from each side. If a restricted network is in scope, repeat the join from that network as well. Check: every item works for both participants, and any failure is logged with the browser, network and time so the cause can be traced.
Confirm recordings and document the rollback path
The tester runs a session with recording enabled, then confirms the recording appears in the activity and that its files are written to the storage location the team chose. Check playback and watch disk usage on the server, since the install documentation lists 500 GB for recordings. The administrator documents each change, including the server configuration, the Moodle setting, the firewall rule and the secret location, with the rollback step beside it. Check: the recording plays back, its storage path appears in the configuration notes, and each rollback step has been tested on a non-production change.
How Moodle roles and course data map to BigBlueButton sessions
This table traces each Moodle data item through the BigBlueButton session it creates, from the user identity and role sent at join to the recordings and participation data returned afterward. Read each row left to right: the first column names the Moodle data, the middle column explains what BigBlueButton does with it, and the last column lists what your team should test on the release you run. The main takeaway is that role and meeting identity decide who can control a session and where its recordings appear, so both need explicit testing before classes depend on them.
| Moodle data | What BigBlueButton receives or does | What to verify |
|---|---|---|
| User identity (full name) | Moodle passes the user's display name when creating or joining a session, and BigBlueButton shows it to other participants. | Names display in the expected format for students and teachers, including users who sign in through SSO. |
| User role in the course | Moodle maps the user's course role to a moderator or viewer join role for each session, so the role is set at join time. | Teachers join as moderators and students as viewers. Test with one account of each role on your Moodle release. |
| Course and activity identifiers | Moodle derives a meeting identifier from the activity, so each BigBlueButton activity links to one meeting on the server. | Two activities in different courses never share a meeting. Confirm how the identifier is built in the Moodle release notes and API docs. |
| Shared secret and API calls | Every call from Moodle carries a checksum computed with the secret shared with the server, which BigBlueButton checks before acting. | The secret stays on the Moodle server and never appears in page source. Confirm the checksum algorithm your Moodle release uses against the API docs. |
| Session recordings | BigBlueButton stores each recording under its meeting identifier, and Moodle lists those recordings inside the matching activity. | Recordings appear in the correct activity after a test session. Plan disk capacity for recordings, since the install docs give different storage figures with and without recording. |
| Attendance and participation data | BigBlueButton produces participation data for each session, and Moodle reads back the fields that the release supports. | Confirm which fields return to Moodle in your release. Do not assume grading is fed automatically until a test session confirms it. |
| Grading and activity completion | Moodle records completion or grades only where the activity is configured to do so, based on the data Moodle has received. | Run one graded session and check the gradebook entry, completion status and attendance record match what happened in the room. |
Recordings, attendance and grading decisions for class video
The first decision is whether to record sessions at all, because it sets the disk budget for the BigBlueButton server. The BigBlueButton 4.0 install docs list 500 GB of disk for recordings, compared with 50 GB for a server without recording. Treat those figures as a starting point, not a forecast. Your actual need depends on how many recorded sessions run each term, how long they last and how long you keep them. Estimate recorded hours per term from your timetable, then multiply by your retention period. Confirm the disk figures against the BigBlueButton version you deploy, because the install guidance is versioned.
Next, decide who can start and stop recording and who can see the recordings in Moodle. Both choices run through the BigBlueButton activity settings and the roles held in the course context, including teacher, student and any custom role you create. Decide whether students may ever start a recording or whether only teachers can. Decide whether recordings appear to enrolled students only or to other users with access to the course. Confirm the exact capability names and defaults in your Moodle version, then test each decision with a teacher account, an enrolled student account and an account that is not enrolled. Record the results so the access model can be explained to an auditor.
Recordings contain voice, video, chat and participant names, so storage and deletion tie directly to privacy obligations and to your institution's data retention schedule. Set a retention period for recordings, state who approves deletion and confirm how deletion reaches every copy: the BigBlueButton server, Moodle's file storage and any backups or exports. Ask whether deleting a course removes its recordings, and whether course backups include them in your Moodle version. Pair this with the privacy tooling review in your compliance planning so the two documents match. Do not assume a deletion in Moodle has cleared the recording files on the video server.
Attendance and grading are data flows, and their reports are only as reliable as the joins and timestamps behind them. Reports combine BigBlueButton session events, Moodle user identities, course enrolments and time values. Clock drift between servers, time zone settings, sessions that run past their scheduled end and participants who leave and rejoin can all change the result. Run a set of live sessions with known joins, leaves and durations, then compare the attendance report and any grade pushed to the gradebook against what you recorded. Repeat the test after each upgrade. Confirm which fields each feature reads in your versions before you trust the output.
Security settings that keep class video inside your infrastructure
These settings cover the parts of the integration that could expose class video or let outsiders into meetings: the API secret, request checksums, host access and open ports, certificates, who can join and record, the media path and the release you patch. Each card names a decision to make and a check to run before classes start.
Shared secret and checksums
The BigBlueButton shared secret signs every API call, so anyone who holds it can act as your server. Keep it in server-side configuration and out of page templates, themes, JavaScript, course content and support tickets. Rotate it through a scheduled change: update the BigBlueButton server and Moodle together, then test a join and a recording lookup. SHA-256 is the default checksum algorithm, SHA-384 and SHA-512 are available since version 2.5, and SHA-1 should stay off unless a legacy client needs it. Confirm each client's algorithm before go-live.
Host access and exposed ports
Administrative access to the BigBlueButton host should come only from named management networks or a bastion you control, with key-based SSH and no password logins. Expose TCP 80 and 443 and the UDP range 16384 to 32768, and nothing else, to the networks that need them. Document the UDP range in firewall records and confirm that any upstream firewall, load balancer or cloud security group passes all of it. Keep databases and internal services off the public internet.
Valid SSL on the hostname
BigBlueButton needs a valid hostname for SSL, and browsers check that certificate for the join page and the Moodle activity. Use a fully qualified name in a domain you control and a certificate that your users' browsers trust. Test from student networks and from Moodle itself. Track certificate expiry in your monitoring, because an expired certificate blocks access before any audio or video starts.
Who joins, creates and records
Decide before the first class who can create meetings, who can record and how guests join. In Moodle, these are role permissions on the activity and course, so review teacher, non-editing teacher and any custom roles. The install guide specifies 500 GB of disk for recordings, and recordings hold class content, so set retention with your privacy team. If you use Greenlight v3, it supports external authentication through OpenID Connect, and its docs suggest Keycloak for other login methods. Confirm your identity choices before go-live.
TURN changes the media path
A TURN server is recommended for users behind restrictive firewalls, and it changes the path media takes. Relayed traffic passes through an extra host, which becomes one more component to patch, monitor and firewall. If a third party operates it, media leaves your network boundary, so confirm where it runs and who runs it. Decide its listening ports and allowed clients, log its use, and test from the networks your students actually use before you publish it to them.
Patch on your chosen release
Choose one BigBlueButton release line and write down how you will patch it. BigBlueButton 4.0.0 was released on October 14, 2026, and installs on Ubuntu 24.04 64-bit. The 3.0 branch still receives maintenance releases, such as 3.0.39 on October 2, 2026. Direct upgrades from 2.6, 2.7 or 3.0 to 4.0 are not supported, so plan a clean server. Test each patch on a staging host, and confirm the support window of the branch you picked before you commit to it.
Common failures when Moodle cannot reach BigBlueButton
This table lists the symptoms administrators most often report when a Moodle site cannot run BigBlueButton meetings, with the likely cause and fix for each. Work through the rows against the server first, since joins, audio, SSL and load problems usually start there. Most failures trace back to a secret or checksum mismatch, blocked ports, a missing hostname or certificate, or a server below the documented minimums.
| Symptom | Likely cause | Fix |
|---|---|---|
| Meetings fail to join with checksum or authentication errors | The shared secret in Moodle does not match the BigBlueButton server, or the checksum algorithm differs between them | Copy the secret from the server again, confirm the checksum algorithm setting on both sides, then retest a join |
| Users join but hear no audio or see no video | UDP ports 16384 to 32768 are blocked by a server or upstream firewall, or users sit behind a restrictive network with no TURN path | Open the UDP range end to end, then add a TURN server for users on restricted networks as the install docs recommend |
| SSL warnings or failed joins | The server has no valid hostname, or the certificate does not match the name Moodle uses to reach it | Give the server a public DNS name, issue a valid certificate for that name, and use the same address in Moodle |
| Slides fail to convert | Docker is missing or not running on the server, so sandboxed LibreOffice conversion cannot start | Install Docker as the install docs describe, confirm the service is running, then upload a test presentation |
| Upgrade attempts fail | Direct upgrades from 2.6, 2.7 or 3.0 are not supported for BigBlueButton 4.0 | Plan a clean server installation on the supported operating system, then reconnect Moodle and migrate recordings you need |
| Server slows or drops users under load | RAM, swap, CPU or bandwidth sit below the documented minimums for the expected number of concurrent users | Size the server to the install docs minimums, add swap, watch CPU and bandwidth during peak classes, and scale out if needed |
| Recordings are missing | Recording is disabled, disk space is full, or a retention rule removed the files | Check the recording setting in Moodle and on the server, confirm free disk against the recording guidance, and review retention rules |
| Secrets are exposed in a web page or shared document | The shared secret was embedded in page source, a template, a ticket or a shared file | Rotate the secret on the server and in Moodle, then review every place it was copied and remove those copies |
Sizing the BigBlueButton server for your class load
The documented BigBlueButton 4.0 server minimums are the floor for a single server, not the target for your classes. They call for at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB if recording is off) and 250 Mbit/s of symmetrical bandwidth. A server that meets these figures can still fail under a full timetable, so use them to rule out hardware that cannot run the software at all, then size from your own schedule.
Start by turning the timetable into load figures. For the busiest hour of a normal teaching week, count the number of sessions running at the same time, the number of participants in each session, and how many of those participants will turn on webcams and microphones. Then record which sessions will be recorded, because recording drives disk use and extra processing. Check whether breakout rooms, polling or screen sharing are common in your courses, and whether any exam, open day or term-start period creates a peak that is higher than a regular week. Ask your academic calendar owners for these numbers rather than guessing them.
Scalelite is an open-source project from Blindside Networks for distributing meetings across multiple BigBlueButton servers. It adds a layer that your team must install, configure, monitor and upgrade alongside the BigBlueButton servers it manages. Before choosing it, evaluate whether the number of concurrent sessions justifies more than one server, whether your operations team can run the extra components, how failed servers will be detected and drained, and whether the Scalelite release you plan to use supports the BigBlueButton version you deploy. Confirm all of these against the project's own documentation.
Verify the sizing with a load test built from the timetable, not from a generic benchmark. Simulate the peak hour with the same number of sessions, participants, recording settings and media use you counted. Measure CPU, memory, disk, bandwidth and audio or video quality during the test. Confirm the network path as well: TCP ports 80 and 443 and UDP ports 16384 to 32768 must be reachable, and a TURN server may be needed for users behind restrictive firewalls. Check the results against the BigBlueButton install documentation, review them with your operations team, and repeat the test after any hardware, network or version change.
Questions buyers ask about Moodle and BigBlueButton integration
How much does a self-hosted BigBlueButton integration with Moodle cost?
Cost depends on the written scope, and no single figure applies to every school, university or training provider. The main drivers are the server hardware or cloud instances you run, the bandwidth those servers need, the time to build and test the server, the storage for recordings, and the scope of identity and security work, such as how users sign in and how the server is locked down. One-time costs cover the server build, Moodle configuration and testing. Recurring costs cover hosting, bandwidth, recording storage that grows with use, and upgrades or support. If your own team does the work, the cost is staff time. If a partner does it, the cost is the fixed-scope quote. Ask for line items for the server build, each environment, the recording storage assumptions, the identity work, testing and any support retainer.
How long does a Moodle and BigBlueButton integration take to deliver?
Duration depends mainly on the number of environments, the load testing you need, and whether the scope includes a clean server build and a live test course. A production server alone takes less time than a production server with a staging copy, because each added environment needs its own build and verification. Load testing takes time because it must reflect the number of concurrent classes and participants you expect. BigBlueButton 4.0 installs on a clean server, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so an older server usually needs a fresh build. Ask for a schedule with milestones for the server build, the Moodle activity configuration, testing and handover, and confirm which of these are in scope before work starts.
What does our institution need to provide for a BigBlueButton integration?
Four roles are needed, and in a small team one person may hold more than one. A Moodle administrator manages the site, the BigBlueButton activity settings and course access. A network engineer opens the required ports, provides a valid hostname for SSL, and decides whether a TURN server is needed for users behind restrictive firewalls. A server owner controls where the BigBlueButton server runs, who pays for it and who is alerted when it fails. A named decision maker sets the recording policy, including whether recording is on by default, who may view recordings and how long they are kept. Without that decision, storage sizing and privacy review cannot be finished. Ask the provider to confirm who from your side attends each stage and who signs off each decision.
Can our own IT team integrate Moodle with BigBlueButton without a partner?
Yes, a team can do it alone if it has Linux administration, networking and Moodle administration skills and follows the official install documentation. The install steps, the Moodle activity settings and the port checks are documented and can be repeated in a test environment first. The work carries most of its risk in two places: sizing and security. Sizing decisions set the cost of hardware, bandwidth and storage, and an undersized server fails during peak class times. Security decisions include keeping the shared API secret on the server side, using a valid TLS certificate, controlling who can create rooms and setting recording access. An outside review of those two areas can catch problems before go-live. Whichever route you choose, record the sizing and security decisions in writing before the server carries live classes.
What server specification does BigBlueButton 4.0 need for Moodle classes?
The BigBlueButton 4.0 install documentation lists minimums for one server: at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk if recordings are kept (50 GB without recording), and 250 Mbit/s of symmetrical bandwidth. It installs on Ubuntu 24.04 64-bit. These are starting minimums, not a capacity plan. The load you must carry depends on how many classes run at the same time, how many participants each class has, how much video is shared, and how long recordings are retained. Those inputs decide whether one server is enough or whether you need several, and a multi-server setup needs its own design and testing. Confirm the expected peak load in writing and have the sizing reviewed before you buy hardware or provision cloud instances. Load testing is the most reliable check on the result.
Which firewall ports and TURN settings does BigBlueButton need?
BigBlueButton needs TCP ports 80 and 443 reachable for the web application and secure connections, and UDP ports 16384 to 32768 for live audio and video media. The server also needs a valid hostname for SSL that resolves to it. Docker is needed for sandboxed LibreOffice document conversion. Users on restrictive networks may not be able to reach the UDP range, so the install documentation recommends a TURN server, which relays media over a port those networks allow. Test from the networks your learners and staff actually use, including home connections and campus Wi-Fi, because a server can pass internal tests and still fail for students behind a firewall. Your network engineer should document each rule, its purpose and its owner.
How are BigBlueButton recordings stored and who decides how long they are kept?
Recording storage is part of server sizing, and the recording policy is a decision the institution makes before the server is sized. The install documentation lists 500 GB of disk with recording and 50 GB without, so the choice to record largely sets the disk you need. Storage grows with the number of classes and their length, so ask for an estimate based on expected recorded hours per term, a retention period set by policy, a deletion process and backup rules for recordings. Confirm who can view recordings in each course, whether students are told that sessions are recorded, and how deletion requests are handled under your privacy obligations. These answers belong to a named decision maker and should be written down before go-live.
How DeployOpen scopes, builds and supports the Moodle BigBlueButton integration
DeployOpen plans and builds the Moodle and BigBlueButton integration as a fixed-scope engagement, agreed in writing before work starts. The work covers the BigBlueButton server, the Moodle activity settings, and the controls around recordings, attendance and grading, all inside your own infrastructure. Ongoing support, upgrades and testing are available as a retainer.
How we scope
- A written scope listing the Moodle sites, courses and user groups that will use BigBlueButton
- Server sizing checked against the BigBlueButton 4.0 minimums for RAM, cores, disk and bandwidth
- Decisions on recording retention, storage size, and whether attendance and grades flow into the gradebook
How we build
- Clean Ubuntu 24.04 64-bit server installation, since direct upgrades from 2.6, 2.7 or 3.0 are not supported
- Firewall rules for TCP 80, 443 and UDP 16384 to 32768, plus a valid SSL hostname for the server
- Moodle activity configuration with the shared secret kept server-side and never embedded in a web page
How we hand over
- Written runbook covering the server build, Moodle settings, certificate renewal and recording storage
- Test plan run with teachers, covering joins, breakout rooms, recordings, attendance and grade sync
- Documented upgrade steps for the BigBlueButton release branch and the Moodle version in use
How we support
- Retainer options for patching, BigBlueButton maintenance releases and Moodle point upgrades
- Capacity review as class sizes and recording volume change, planned together with your team
- Changes to the Moodle activity or the server handled under a new written scope
