BigBlueButton and Moodle integration

Start with the number of sessions that will run at the same time, not the number of students or courses. A single BigBlueButton server is the simpler choice when your peak concurrent load fits on one machine with headroom left for the spikes that come with a class start time. A Scalelite pool is worth its added components when one server cannot carry peak load, when you want a second server to take over if the first is down, or when you need to add capacity without changing the Moodle configuration. Scalelite is an open-source load balancer that presents the pool to Moodle as one server and sends each new meeting to the least loaded server behind it.

The added components are real. Scalelite uses a PostgreSQL database, a Redis cache and an NFS shared volume where recordings are written so that every node can serve them. Each of these needs its own installation, backups, patching and monitoring. The shared volume also becomes a single point of failure for recordings unless you design its storage and recovery deliberately. Ask your implementation partner to show how a failed BigBlueButton node is removed from the pool and how in-progress meetings are handled, and confirm both behaviors in your own test environment before you rely on them.

Four drivers should decide the topology. The first is peak concurrent sessions, measured in attendees and in simultaneous meetings. The second is recording volume: if teachers record most sessions, the disk and NFS sizing matters more than the CPU. The third is availability expectations. If a class can wait a few minutes for a restart, one server may be acceptable, but if exams or office hours run on fixed schedules, a pool with spare capacity is easier to defend. The fourth is operations skills in-house. A pool adds a database, a cache, shared storage and load balancer configuration to the team's workload, so a team without experience in those areas should price that effort into the decision.

Size from your own class schedule rather than from a generic figure. Pull the last term's timetable from your LMS or student information system, count the sessions that start within the same window, and multiply by the expected attendees per session. Add the breakout rooms and the recording volume you expect from those sessions. Repeat the exercise for your heaviest week, such as the first week of term or exam preparation. Vendor minimums and community examples are useful for checking hardware, but they do not describe when your classes overlap. Ask your partner to base the sizing on this schedule and to state the assumptions in writing so they can be revisited each term.

Plan the decision as a checkpoint, not a one-time purchase. Document the peak load you measured, the failure you are designing for, and the team member who will operate the pool. Revisit the decision when enrollment grows, when a new course format adds long recorded sessions, or when the team changes. Confirm the current BigBlueButton release and its hardware requirements with the project documentation before you order servers, because requirements change between major versions.

Recordings, chat messages, poll results, shared notes and participant details from a BigBlueButton session started through Moodle are education records under FERPA when an institution maintains them for a student, and personal data under the GDPR when the individual is in the EU. Children under 13 add a third regime, COPPA. Which of these apply depends on jurisdiction, the age of participants and who holds the data. Decide this before go-live, then map where each artifact is stored: the BigBlueButton server disk, the NFS volume used by Scalelite for recordings if you run a pool, the PostgreSQL and Redis services, and the course storage in Moodle where published recordings are linked.

For US institutions, the key FERPA question is whether anyone outside the institution can see the data. Under 34 CFR 99.31(a)(1), a contractor may act as a school official only if it performs a service staff would otherwise do, stays under the institution's direct control for the use and maintenance of the records, and honors redisclosure limits. Hosting BigBlueButton, Scalelite and Moodle in infrastructure you control keeps that direct control clear. You must also limit administrator and support accounts to people with a legitimate educational interest (34 CFR 99.31(a)(1)(ii)). Under 34 CFR 99.32, each disclosure of personally identifiable information must be recorded, with the parties and their interests, for as long as the records are kept. Confirm whether the Moodle and BigBlueButton logs capture this, or whether you need a separate audit trail.

For EU data subjects, the GDPR (Regulation (EU) 2016/679) governs how recordings and chat data are collected, used and kept, and it applies wherever the data is physically processed. Your legal or compliance team should confirm the lawful basis for recording, how participants are told a session is recorded, and how access and erasure requests will be handled for recordings that are spread across a server, a pool and an LMS. If children under 13 are in the classes, COPPA's rule on written retention, 16 CFR 312.10, requires a written data retention policy with a deletion timeframe, and the operator may keep children's personal information only as long as reasonably necessary for the purpose collected. Written security program and risk assessment duties in 16 CFR 312.2 and 312.8 also apply.

Legal or compliance review should confirm which regimes apply to each course, cohort and jurisdiction before the server design is final. You decide the retention periods, the deletion timeframes and who approves a deletion. The engineering team can then build the controls that enforce those decisions: recording retention jobs, deletion procedures for the server and NFS storage, restricted administrator roles, protected storage of the shared secret used for API calls, and logs that show who accessed what. For Title IV institutions, the Safeguards Rule (16 CFR Part 314) also requires multi-factor authentication for anyone who accesses an information system, so confirm how that applies to the BigBlueButton and Moodle administrator accounts. Ask for these items in writing as part of the scope.

A pre-launch test plan should prove three things: the Moodle activity reaches your own BigBlueButton server or Scalelite pool, each role sees the right controls and recordings, and the shared secret never reaches a student's browser or a log file. Run the plan in a staging course that mirrors your production settings before any student is enrolled. Write each test as a scripted case with a named owner, the expected result, and the evidence you keep, such as a screenshot, a log extract or a recording link. Vague sign-off on a call is not enough for an audit trail.

Start with joins. Test a join from a desktop browser and from a mobile device, since audio, camera and screen-sharing behavior often differs between the two. Then test a student on a restrictive network, such as a campus or corporate firewall that blocks UDP. BigBlueButton needs TCP 80 and 443 and UDP 16384 to 32768, and the install documentation recommends a TURN server for users behind strict firewalls. Confirm with your network team which path a blocked student takes, whether media falls back through TURN, and what happens if it cannot connect. Record the result for each network you expect students to use.

Next, test a teacher-moderator session end to end. Confirm that the moderator can start the session from the course, create breakout rooms, launch a poll, and end the meeting, while a student joined as a viewer cannot do those things. Check that breakout room participants return to the main room correctly and that poll results display for the moderator as intended. Also confirm the role mapping that Moodle passes to BigBlueButton, because a mismatch there is the most common cause of students gaining moderator controls.

Create a recording during a test session, then play it back from inside the course. Check how long the recording takes to appear, and confirm where it is stored. On a single server, recordings use local disk, and the install documentation's 500 GB recording figure is the planning guide for that. In a Scalelite pool, the shared NFS volume holds them, so confirm that every node can write to and read from it. Then test visibility: an enrolled student should see the recording, while a user from another course, a guest and a logged-out visitor should not. Ask your vendor to confirm how recording links behave if they are shared outside the course.

Size concurrency to the expected peak, using your timetable to estimate how many sessions run at once, then load test at that level. Watch CPU, memory, swap and bandwidth against the install minimums (16 GB of RAM with swap, 8 cores and 250 Mbit/s symmetrical bandwidth for a 4.0 server). If you use a pool, stop one server during a test session and restart it, then confirm how active meetings end and whether new meetings land on the remaining servers. Finally, search the Moodle logs, web server logs, proxy logs and BigBlueButton logs for the shared secret string, and inspect page source for the activity launch. Any hit is a failed test, and the fix is part of the go-live gate.