Replacing Blackboard Collaborate with self-hosted BigBlueButton
For most institutions replacing Blackboard Collaborate, BigBlueButton is the main open-source virtual classroom, and it is usually paired with Moodle so that sessions, attendance and recordings stay inside the course. BigBlueButton is licensed under the LGPL-3.0 and maintained by BigBlueButton Inc. It covers audio, video, slides with annotations, chat, screen sharing, polling, a multi-user whiteboard, shared notes and breakout rooms. Those are the functions most online teaching sessions depend on, but parity with Collaborate should be verified feature by feature in a pilot, especially for moderator controls, reporting and any integration your current course design relies on.
The project states that BigBlueButton is embedded in Canvas, Moodle Cloud, Sakai, Jenzabar, D2L and Schoology, and that these platforms represent over 75% of the worldwide LMS market. Read that figure carefully: it describes the LMS platforms that embed BigBlueButton, not the number of institutions running it. For a Moodle deployment, the practical question is how the integration is wired on your own servers, which is a decision to confirm with your team and your implementation partner rather than assume from the project's statement.
Plan the hosting before you commit. The install documentation for BigBlueButton 4.0 lists Ubuntu 24.04 64-bit, at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. It also requires TCP ports 80 and 443, UDP ports 16384 to 32768, a valid hostname for SSL and Docker for document conversion, and a TURN server is recommended for users behind restrictive firewalls. Direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a clean server installation and confirm the current release and its maintenance schedule in the project's BigBlueButton releases page.
Which Collaborate capabilities BigBlueButton covers
This table maps the core Blackboard Collaborate session features to what BigBlueButton provides out of the box and what depends on the Moodle integration. Use the coverage notes to decide which features need a pilot, and check any Collaborate feature not listed against your own session records before you commit.
| Capability | BigBlueButton coverage | Notes for your review |
|---|---|---|
| Audio and video | Yes | Audio, webcam video and presenter controls are part of the core product. Test with your own bandwidth, since the install guidance calls for 250 Mbit/s symmetrical. |
| Slides with annotation | Yes | Presentations are shown with annotation tools. Document conversion uses Docker-sandboxed LibreOffice, so confirm the file types your faculty upload. |
| Chat | Yes | Public and private chat are included. Confirm moderator and chat-export settings against your policy. |
| Screen sharing | Yes | Participants and presenters can share screens within the session. Confirm browser support for your learners. |
| Polling | Yes | Polling is included in the core session. Confirm how poll results are captured for your records. |
| Multi-user whiteboard | Yes | A shared whiteboard is included for all participants. Test with the largest class sizes you plan to run. |
| Breakout rooms | Yes | Breakout rooms are included. Confirm how moderators assign and return participants in your course setup. |
| Shared notes | Yes | Shared notes are included as part of the session toolset. Confirm whether notes are kept with the recording. |
| Recordings | Yes | Recordings are stored on the server, so storage planning matters. The install guidance lists 500 GB of disk for recordings. |
| Attendance in the course | No | Attendance records are not a core BigBlueButton feature. Depends on the Moodle integration and should be tested before go-live. |
| Grade sync and recording access in the course | No | Linking sessions to gradebook items and course-level recording access depends on the LMS integration. Confirm the configuration with your Moodle administrator. |
Self-hosted options for virtual classrooms in Moodle
BigBlueButton can run beside Moodle in three ways, and each one changes who builds the login flow, where sessions are recorded and who patches the server. Choose the path first, then size the media servers that carry the load.
BigBlueButton standalone
Run BigBlueButton as its own server with its own user accounts and join links, and link to it from Moodle as a plain URL. This fits a small pilot or an office hours room where course data does not need to flow in. The trade-off is that attendance and recordings stay on the BigBlueButton server, so staff must copy or reconcile them by hand. Confirm that the install script's host requirements, including the 16 GB RAM and 8 CPU core minimum, match your planned hardware before you commit.
Greenlight v3 front end
Greenlight v3 adds a room and user interface on top of BigBlueButton, so instructors create rooms and share join links without touching the API. Use it when the institution wants a simple booking-style interface for staff and students. Login can be tied to your identity provider through OpenID Connect, and the docs suggest Keycloak for Google, Microsoft or SAML sign-in. Plan for a separate identity component to run and maintain, and confirm that your staff can operate it without reaching the BigBlueButton command line.
BigBlueButton with LTI
LTI connects BigBlueButton to the LMS so launches carry the course context and user role from Moodle. The bbb-install.sh script can install LTI support on the same server as BigBlueButton, which keeps the number of hosts down for a small deployment. Teachers launch the room from the course page, but you still need to confirm which LTI version your Moodle release supports and how recordings are linked back. Test the launch path with a student account and a teacher account before the first class.
Embedded BigBlueButton in Moodle
Moodle's built-in BigBlueButton activity lets teachers add a session to a course and keeps sessions, attendance and recordings in the course context. This is the option most aligned with the goal of keeping teaching data inside the LMS. The trade-off is that your Moodle version, the BigBlueButton version and the server address must be compatible, so an upgrade on one side can break the other. Ask your Moodle administrator to test a session after every upgrade on either platform.
Scalelite for multi-server scaling
Scalelite is an open-source load balancer that spreads meetings across several BigBlueButton media servers and keeps a single entry point for Moodle. Add it when concurrent classes outgrow one server, or when you need to take a server out of service for maintenance without stopping the others. It adds its own host to patch and monitor, and the media servers still need the network ports and TURN planning described in the install docs. Ask for a load test that matches your peak class count before you size the pool.
What a BigBlueButton 4.0 server needs before you commit
A BigBlueButton 4.0 server is a single media-heavy host, so the baseline numbers in the install documentation are minimums for one server, not a capacity plan. The install docs list at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, and 250 Mbit/s of symmetrical bandwidth. Bandwidth and CPU are what usually limit the number of simultaneous users, and both depend on how many people speak, share video and share screens at once.
- Memory: 16 GB of RAM is the stated minimum, and swap must be configured in addition to it.
- CPU: 8 cores with high single-thread performance, not simply a high core count.
- Bandwidth: 250 Mbit/s symmetrical, so upload and download must both be sized, not only the link speed quoted by the provider.
- Scaling: when concurrent sessions grow, plan for more than one server rather than assuming one host will absorb the load.
Ask your infrastructure team to model peak concurrent sessions, webcam use and screen sharing before the hardware is ordered, and confirm the numbers with your BigBlueButton partner or the project's documentation.
Storage is the requirement most often underestimated, because recordings accumulate silently. The install docs recommend 500 GB of disk when recording is enabled and 50 GB when it is not. The difference is driven almost entirely by how many sessions are recorded and how long recordings are kept, so the disk figure is a starting point rather than a retention policy.
- With recording: plan for 500 GB of disk, which is the figure the documentation gives for recording-enabled servers.
- Without recording: 50 GB is the documented figure, which suits servers used only for live sessions.
- Retention: decide how long recordings must stay available, since storage grows with every recorded session.
- Backups: recordings and course-linked data need backup and restore planning, which adds storage outside the server.
- Growth: a recording-enabled server should have a plan for expanding or archiving disk before it fills.
If your course policy requires recordings for a set period, confirm the retention period with your registrar or compliance lead before you size the disk.
BigBlueButton needs specific inbound paths to work for participants, and most installation problems trace back to a blocked port or a missing hostname. The documentation requires TCP ports 80 and 443 and UDP ports 16384 to 32768 to be reachable, a valid hostname for SSL, and Docker for sandboxed LibreOffice document conversion. Those requirements must be checked against your campus or corporate firewall, not only the server's own firewall.
- TCP 80 and 443: web and secure access must be reachable, and the server needs a valid hostname for SSL.
- UDP 16384 to 32768: media traffic for audio and video must be allowed through.
- Docker: required for document conversion in a sandbox.
- TURN server: the documentation recommends one for users behind restrictive firewalls, which is common in schools, hospitals and regulated offices.
- Perimeter review: have the network team confirm that UDP media ports are not blocked or rate-limited at the edge.
Test from the networks your learners and staff actually use, including guest and remote networks, before go-live.
BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit. The install docs state that direct upgrades from 2.6, 2.7 or 3.0 are not supported, and a clean server installation is recommended. For an organization already running an older BigBlueButton release, this means a new server, a data migration plan and a cutover, not an in-place upgrade. The 3.0 branch continues to receive maintenance releases, so existing servers remain supported for now, but moving to 4.0 is a rebuild.
- Operating system: Ubuntu 24.04 64-bit is the stated platform for 4.0.
- No direct upgrade: installs from 2.6, 2.7 or 3.0 cannot be upgraded in place.
- Clean server: the recommended path is a fresh host, built from the install documentation.
- Install script: the bbb-install.sh script can add Greenlight or LTI support on the same server.
- Cutover: plan how existing rooms, recordings and integrations move to the new host.
Before you commit, confirm the OS image your hosting provider or data center will supply and check the current install guide for any changes.
The hardware, storage and bandwidth figures are minimums from the install documentation, and they do not account for your own usage pattern. An institution with a few hundred staff using occasional sessions has a very different load from a school district running daily recorded classes. Sizing should start from concurrent session counts, the number of participants per session, and how many sessions will be recorded.
- Concurrent sessions: the most important input, measured at peak, not as a daily average.
- Participants per session: more participants with webcams and screen sharing increase CPU and bandwidth.
- Recording share: the percentage of sessions recorded drives disk growth.
- Redundancy: decide whether a single server is acceptable or whether a second server is needed for failover or load.
- Test environment: build and load-test a staging server before production.
Before you commit, confirm sizing with your concurrent session data, your network team's firewall review and your BigBlueButton implementation partner.
How access, secrets and recordings stay inside your control
Every BigBlueButton API call is signed with a checksum computed from the request and a secret shared with the server, so the secret is the control point for who can create or join meetings. The checksum uses SHA-256 by default, SHA-1 remains available for legacy integrations, and SHA-384 or SHA-512 have been supported since version 2.5. Confirm which algorithm your Moodle BigBlueButton integration and any custom scripts use, and plan to move legacy callers off SHA-1. The shared secret must stay server-side: it belongs in the Moodle site configuration or the server's own settings, never in a page, template or JavaScript file a learner's browser can read. Treat rotation as a runbook item, and record who holds the secret and where it is stored.
Greenlight v3 handles user login separately from the meeting API. It supports external authentication through OpenID Connect, configured with environment variables, so accounts can come from your identity provider rather than local passwords. The BigBlueButton documentation suggests Keycloak as a broker when you need Google, Microsoft, SAML or other login methods on top of that. Decide which identity source is authoritative for staff and students, how roles map to moderator and viewer rights, and what happens when someone leaves. Within Moodle, the decision is similar: confirm which authentication plugin your institution will use, since Moodle core includes LDAP, LTI, OAuth 2 and Shibboleth, and the SAML2 plugin is available from the Moodle marketplace.
Recordings are written to the BigBlueButton server's disk, so your organization, not a vendor, decides where they sit and how long they persist. The install guidance recommends 500 GB of disk for recordings, against 50 GB without recording, so storage size is a planning input. Retention is set by your own scripts, cron jobs and Moodle settings, so the records policy must name who may view a recording, how long it is kept, how deletion is logged and how backups of recording storage are handled. Document these decisions in the institution's records retention schedule before the first live session. Ask your legal and records teams which categories of session, such as assessed oral exams or disability accommodation sessions, need separate handling.
Moving Collaborate sessions, recordings and attendance into Moodle
This sequence moves live class sessions, recordings and attendance records from Blackboard Collaborate into a clean BigBlueButton server that runs inside Moodle, so teaching continues without losing the records the institution must keep. Each step ends with a check that tells you whether it can move on.
Inventory sessions and retention requirements
Ask the Collaborate administrator and the registrar's office to list every recurring session, its course, its owner and the recordings and attendance records that must be kept, and to record how long each category must be retained. Confirm with Blackboard which export tools and formats are available for session history, attendance and recordings, since this tooling must be verified with the vendor before the contract ends. Done when you have a signed-off inventory and a written export method for each record type.
Export session history, attendance and recordings
Before the current contract ends, the platform owner pulls session history, attendance exports and recordings using the export method confirmed in the previous step. Store each file in a format the institution can read without the source platform, such as standard video and spreadsheet or CSV files, and keep a manifest that maps each recording to its course and session date. Verify a sample of files by opening them on a separate machine. Done when the archive opens correctly and the manifest matches the inventory.
Stand up a clean BigBlueButton 4.0 server
The infrastructure team installs BigBlueButton 4.0 on a fresh Ubuntu 24.04 64-bit server, not as an upgrade from an earlier version, because direct upgrades from 2.6, 2.7 or 3.0 are not supported. 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 for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. Open TCP ports 80 and 443 and UDP ports 16384 to 32768, configure a valid hostname for SSL, and install Docker for document conversion. Done when a test meeting runs with audio, video and a whiteboard from an outside network.
Connect BigBlueButton to Moodle
Configure the Moodle BigBlueButton integration with the server URL and shared secret, and keep the secret on the server side so it never appears in a page. Confirm that API calls use the checksum settings in the API documentation and that the server is reachable from the Moodle web servers. If the institution needs a TURN server for students behind restrictive firewalls, add it now and test from such a network. Done when a teacher can create a session from inside a Moodle course and a second user can join it.
Pilot with one course
Choose one course with an active instructor and a modest number of sessions, then run its live classes, breakout rooms, polling and recordings through the new setup for a full teaching cycle. Check that attendance appears in the Moodle course, that recordings are linked to the correct activity and that learners can find them without help. Record every issue with its owner and fix it before expanding. Done when the pilot instructor signs off and the attendance and recording checks match the manual records.
Reconfigure LTI and single sign-on
Recreate any LTI tool links and single sign-on connections that the courses depended on, using the authentication methods Moodle ships or a plugin the institution has approved, such as SAML 2 or OAuth 2. If Greenlight is used as a front end, connect its external authentication through OpenID Connect and confirm the sign-in path for staff and students. Test each login route with a test account for each role. Done when every role can sign in and reach the expected sessions and recordings.
Cut over and retain the archive
Announce a cut-over date to instructors and students, switch scheduled sessions to the Moodle-hosted BigBlueButton setup, and stop creating new sessions in Collaborate. Keep the archive and manifest in storage the institution controls, and confirm the retention periods set in the first step are applied to the new location. Assign an owner for patching and backups of the BigBlueButton server. Done when no new sessions are created in Collaborate, the archive is verified and the owner has signed off on the operations plan.
Questions institutions ask before replacing Collaborate
What drives the cost of self-hosting BigBlueButton instead of paying for Collaborate?
The cost is set mainly by the server, storage, bandwidth and the people who run them. BigBlueButton is licensed under LGPL-3.0, so there is no license fee, but a BigBlueButton 4.0 server needs at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk if you keep recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth, according to the install documentation. Recurring costs are hosting, storage growth from recordings, bandwidth, and staff time or a support contract. Ask any quote to break these out, and compare them with your current Collaborate license and support fees over the same period.
How long does it take to move from Collaborate to BigBlueButton?
The duration depends on how many courses use live sessions, how many integrations you must rebuild, and whether you run a pilot first. No supplied figure sets a timeline, so treat any date as something to agree in a written scope. The main drivers are the server build (BigBlueButton 4.0 requires a clean installation on Ubuntu 24.04 64-bit), connecting it to Moodle, testing firewall and port access, and training instructors. Run a pilot with a small set of courses before you schedule the full cutover.
What does the move require from our IT and academic staff?
IT staff own the infrastructure work: provisioning the server, opening TCP ports 80 and 443 and UDP ports 16384 to 32768, issuing a valid hostname for SSL, installing Docker for document conversion, and deciding whether a TURN server is needed for users behind restrictive firewalls. Academic staff own the teaching decisions: which sessions move, how recordings are kept, and how instructors learn the whiteboard, breakout room and polling tools. Name a single owner for each group before work starts, since the two groups depend on each other during testing.
Can our own team run this without outside help?
A team with Linux server administration, networking and Moodle experience can deploy and run BigBlueButton without an outside partner, because the install script and documentation cover the core setup. The harder parts are sustained: patching, monitoring capacity during peak class hours, backup and recovery of recordings, and keeping the Moodle integration working through upgrades. Be realistic about staff time. If nobody on the team has done this before, a fixed-scope implementation plus a support retainer is a common way to transfer knowledge. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and it sets scope and deliverables in writing before work starts.
Does BigBlueButton support the features teachers rely on most?
BigBlueButton covers the core virtual classroom functions: audio, video, slides with annotations, chat, screen sharing, polling, a multi-user whiteboard, shared notes and breakout rooms, according to the project repository. Check the gaps against your own list before committing, including any Collaborate-specific features your faculty use, such as particular moderation or reporting views and how attendance is exported. Test those features in a pilot with real instructors rather than relying on a feature list.
How do upgrades work for BigBlueButton and Moodle?
BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so the recommended path is a clean server installation rather than an in-place upgrade. Plan data migration and cutover for that case. Moodle 5.1 changed the web server document root: from that release it must point to the new /public directory rather than the main Moodle folder, or the site may show directory listings or errors. Moodle also ships major releases in April and October, so plan which release you run and when you test each upgrade. Confirm the exact steps for your versions in the release notes before you schedule changes.
Will sessions, attendance and recordings stay inside our course?
Yes, when BigBlueButton is connected to Moodle through its integration, sessions can be launched from the course and recordings can be tied to it. BigBlueButton is embedded in Moodle Cloud and other LMSs, but confirm the exact attendance and recording behavior you need against your installed Moodle version and plugin before you rely on it. Recordings also need storage planning, since the 500 GB disk figure applies to a server that keeps recordings.
Where BigBlueButton does not replace Collaborate
BigBlueButton covers the core live teaching functions, but it does not replace every part of Blackboard Collaborate, and the gaps are most likely to appear where Collaborate was tied to other Blackboard modules. Before you commit, list every place Collaborate is launched, embedded or reported on in your current Blackboard setup, including any vendor-specific links, grade sync, attendance reports or analytics that depend on Blackboard's own tooling. Each of these needs an equivalent in Moodle or an LTI integration, and some will need custom work. Treat this inventory as the first deliverable of a pilot, not an assumption to revisit at cutover.
Support is the second gap. BigBlueButton is open-source under LGPL-3.0, and BigBlueButton Inc. offers hosting and commercial support, but a self-run deployment has no contractual support unless you buy it. Ask who answers a failed session at the start of a class, what response times are offered in writing, and who holds the on-call duty for the TURN server, the media servers and the recording storage. Also confirm how mobile access works for your learners, since the mobile experience for joining, presenting and using breakout rooms should be tested on the devices your students actually use, not assumed from the desktop test.
Large-session performance is the third gap, and it depends entirely on your hardware and network. The install documentation sets minimum requirements for a BigBlueButton 4.0 server, but those minimums are not a capacity guarantee for your largest class. Run a load test with the number of concurrent participants, webcams, screen shares and recordings you expect at peak, on the hardware you will deploy, and watch CPU, memory and bandwidth throughout. Confirm the behavior of the whiteboard, polling and breakout rooms under that load. Record the results and make them the acceptance criteria for go-live.
How DeployOpen scopes and delivers a BigBlueButton replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Blackboard Collaborate replacement, that means fixing the server sizing, the Moodle integration and the access rules in a written scope before any installation begins.
How we scope
- Written scope lists the BigBlueButton version, server count, Moodle integration points and the cloud or data center hosting the servers
- Scope records which sessions must be recorded, how long recordings are kept and where they are stored
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Quote follows from the written scope, so ask for each component to be priced separately
How we build
- Installation on a clean Ubuntu 24.04 server, since direct upgrades from older branches are not supported
- Network setup for required TCP and UDP ports, valid SSL hostname, and a TURN server where firewalls restrict users
- Moodle integration so sessions, attendance and recordings are linked from inside the course
- Identity integration through OpenID Connect or SAML, with API secrets kept off web pages and tested before go-live
How we hand over
- Documentation of the architecture, server sizing, port map, backup procedure and upgrade runbook
- Test records for session quality, breakout rooms, recording playback and attendance reporting
- Operator training for administrators who will manage servers, recordings and Moodle plugins
- Clear ownership of the environment after handover, including which components the client maintains
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover moving between BigBlueButton maintenance releases and major versions, with the timing agreed in writing
- Security testing of the deployed services can be added to the scope if your compliance team requires it
- Compliance evidence is prepared for your auditors, who issue any formal reports or certifications
