What upgrades and support cover for BigBlueButton
Ongoing support for a self-hosted BigBlueButton service is the recurring work that starts once classes are running. It covers applying maintenance releases on the 3.0 branch and the 4.0 branch, retesting LMS embedding after each change, watching call quality, and providing on-call coverage when a session fails. The 3.0 branch continues to receive maintenance releases, so a 3.0 server needs regular patch windows of its own. Moving from 3.0 to 4.0 is not an in-place upgrade. Direct upgrades from 3.0 are not supported, so the move is a clean installation on Ubuntu 24.04 with data carried over separately. That work belongs to the migration scope, not to this service.
Each trigger for work is different. A new maintenance release needs a staging test and a dated change window. A failed class session needs logs, media port checks and a root cause before the next timetable slot. A host OS change can affect Docker, FreeSWITCH-related services and the firewall rules that BigBlueButton depends on, so it should be tested on a copy of the server first. An LMS update, such as a new Canvas, Moodle, D2L or Schoology release, can change how the embedded launch behaves, so each LMS version in use should be checked against a test course after every BigBlueButton change.
Ask any partner which LMS versions and BigBlueButton branches are in scope, what the staging environment looks like, how release notes are reviewed before a change, and who answers an out-of-hours call. Ask how call quality is measured and what is reported back. Confirm response expectations in writing, since they are not set by the software.
For a team that already runs Linux servers, the short answer is that routine patching and basic health checks can stay in-house if someone has time for a maintenance window each month and can read BigBlueButton logs. Bringing in a partner makes more sense for LMS regression testing across several platforms, for 24-hour coverage during teaching periods, or when the team has no one who has run a 4.0 installation before. Compare the recurring cost of a retainer with the staff hours and the cost of a failed exam or lecture.
What the service includes
Support is organized as recurring work packages on the BigBlueButton branches your server runs, plus the deliverables you receive at the end of each cycle and at handover.
Patch cycle per branch
Each branch in use gets its own patch cycle. For a 3.0 server, that means applying maintenance releases such as 3.0.39, which was published on October 2, 2026. Once you are on 4.0.0, released October 14, 2026, the same cycle applies to that branch. Confirm which branch each server runs before the first cycle, because 4.0 does not accept in-place upgrades from 2.6, 2.7 or 3.0.
Host and dependency patching
Ubuntu host packages, Docker used for sandboxed LibreOffice conversion, and the TURN and database components on the same host are patched on a schedule tied to the BigBlueButton release notes. Each change is checked against the notes for port, configuration or dependency changes before it goes live, so a host update does not silently break media or document conversion.
Post-update LMS and Greenlight tests
After each update, test runs cover the paths your users actually use: joining a room from Canvas, Moodle, Sakai or another LMS you run, signing in and creating a room in Greenlight, recording playback and breakout rooms. Results are logged against the release so a regression can be traced to one change.
Call quality monitoring and alert thresholds
Monitoring tracks server load, media connectivity across the UDP range 16384 to 32768, and the health of TURN for users behind restrictive firewalls. Alert thresholds are agreed with your team during onboarding, since the right values depend on your concurrent user counts, bandwidth and class sizes.
On-call and incident handling
Incidents are triaged by severity, with a named escalation path from the support desk to the platform engineer and then to your own contacts. Ask in any quote which hours are covered, how response targets are written, and whether an SLA is part of the contract, since coverage levels vary by retainer.
Runbooks and change records
Runbooks cover restarts, certificate renewal for the required hostname, adding capacity, recording storage cleanup and rollback to the previous package set. Every change is recorded with the release, the operator, the tests run and the outcome, so audits and post-incident reviews have a trail.
Cycle and handover deliverables
At the end of each cycle you receive the release change record, test results, updated runbooks and the monitoring status. At handover you receive the full runbook set, alert definitions, access records and a list of open items. Confirm the exact document format and retention period in the written scope.
What drives support cost and effort
Each row names a factor that changes how much upgrade, testing and support work a BigBlueButton service needs, why it moves effort, and how to keep it contained.
| Driver | Why it moves effort | How to keep it contained |
|---|---|---|
| Number of servers and Scalelite pooling | Every server needs its own patching, 4.0 or 3.0 maintenance releases and health checks. A Scalelite pool adds a load balancer, PostgreSQL, Redis and an NFS recordings volume to maintain. | Standardize server builds and automate patch runs. Ask for a written inventory of which hosts sit behind Scalelite and who owns each component. |
| Number and type of LMS integrations | Each LMS (for example Canvas, Moodle, Sakai, D2L or Schoology) has its own plugin or LTI configuration and its own upgrade cycle. Each BigBlueButton update can change what must be retested. | Limit the integration list to the platforms in use. Keep a regression script per LMS and retest only the integrations touched by each release. |
| Greenlight or LTI on the same server | Installing the Greenlight front end or LTI support on the BigBlueButton host ties web application updates to conferencing server updates and widens the set of services that must be restarted together. | Decide early whether Greenlight or LTI shares the host. Separate hosts make upgrade windows and rollback steps easier to reason about. |
| Recording volume and storage | The install requirements call for 500 GB of disk with recording, compared with 50 GB without. Recording growth drives disk alerts, retention work, backup scope and privacy requests. | Set a written retention policy, automate archiving or deletion, and monitor disk use. Confirm the recording sizing with your expected class volume. |
| TURN deployment | A TURN server is recommended for users behind restrictive firewalls. It adds a separate service with its own certificates, ports and firewall rules to test after each change. | Decide whether TURN is needed for your user base. If it is, include it in the same change calendar and certificate renewal process as the main servers. |
| Number of environments (staging versus production) | A staging environment that mirrors production lets each BigBlueButton maintenance release and each LMS change be tested before it reaches learners. It also doubles the hosts to patch and monitor. | Keep staging small but structurally identical. Clarify in the quote whether the support scope covers staging, production or both. |
| On-call hours and response expectations | Call quality problems and failed joins often happen during scheduled classes. Coverage hours, escalation paths and who responds outside business hours determine the staffing load. | Agree coverage hours, severity definitions and response targets in writing before go-live. Confirm what the support scope does and does not include. |
| Custom branding or plugins | Custom themes, client plugins or changes to the default client need rework when BigBlueButton or Greenlight versions change, and they may not carry over between the 3.0 and 4.0 branches. | Limit customization to what the teaching model requires. Keep changes in version control and record each one with its test steps. |
| Compliance evidence needs | Assessors may ask for patch records, change approvals, access reviews, backup tests and recording handling procedures. Producing this evidence is ongoing work, not a one-time task. | Agree the evidence list early and generate it from routine tasks. DeployOpen prepares controls and evidence, while independent auditors issue any assessment outcome. |
How a support engagement runs
The sequence moves a running BigBlueButton service from an unverified baseline to a patched, monitored and documented state that your own team can operate.
Assess the running servers against requirements
We check each BigBlueButton server against the install requirements: at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 250 Mbit/s symmetrical bandwidth, and TCP ports 80 and 443 plus UDP 16384 to 32768 reachable. We also record the installed branch, Ubuntu release and LMS or Greenlight integration. The step closes with a written baseline report listing each gap and the change it needs, which you review before any work starts.
Build a staging environment that mirrors production
We build a staging environment with the same BigBlueButton branch, Ubuntu release, integration settings and network path as production, so test results carry over. Where production uses a recording store, TURN server or load balancer, staging uses equivalent components. The step closes when a test call completes end to end through staging, and the differences from production are listed in the baseline report.
Write and run the repeatable test plan
We write a test plan that covers LMS launch from each integrated platform, joining as moderator and as attendee, recording and playback, and breakout rooms. Each case has an expected result and a pass or fail record. We run the plan on staging before any change and again after each update. The step closes with a signed-off result sheet that shows which cases passed, failed or were accepted with known issues.
Apply the patch cycle
We apply maintenance releases on the branch you run, staging first, then production in a window agreed in the written scope. Before each change we take configuration and data backups and record the current versions. After the change we re-run the test plan and confirm that LMS launch, joining and recording still work. The step closes when production matches the agreed version and the post-change test results are filed.
Tune monitoring and alerts
We set up monitoring for server load, memory, disk use for recordings, media port health and call quality indicators, then tune alert thresholds against the baseline so that routine peaks do not page on-call staff. We document what each alert means and who acts on it. The step closes when test alerts fire and reach the right recipients, and the threshold values are recorded in the handover pack.
Hand over with runbooks
We deliver runbooks for patching, restoring from backup, rebuilding a server, rotating the shared secret, renewing the SSL certificate and responding to common alerts, along with the test plan and monitoring configuration. We walk your operators through a live patch on staging. The step closes when your team completes that patch without assistance, and any remaining support scope is confirmed in writing.
What stays in-house and what to outsource
This table shows who usually owns each upkeep activity for a self-hosted BigBlueButton service and the skills each one needs, so you can decide which rows to keep in-house and which to hand to a support partner.
| Activity | Who usually owns it | Skills required |
|---|---|---|
| Release tracking for 3.0 and 4.0 branches | Platform lead or outsourced support partner | Reading release notes, judging urgency, knowing the 4.0 clean-install requirement |
| Patch application on BigBlueButton servers | Outsourced server rotation under a retainer, or internal ops | Linux administration on Ubuntu, package management, service restarts during quiet windows |
| Staging test runs before production updates | Shared: support partner builds the test, school or college IT approves | Scripted call tests, recording checks, familiarity with each LMS integration |
| LMS administrator coordination | Usually in-house (LMS admin and instructional technology staff) | Knowledge of Canvas, Moodle, D2L or Schoology plugin settings and course-level impact |
| Class scheduling and room policy | Usually in-house with academic or training staff | Understanding of teaching calendars, room ownership and user permissions |
| Call quality monitoring and tuning | Outsourced monitoring with in-house reporting | Network troubleshooting for TCP 443 and UDP media ports, TURN checks, media server metrics |
| On-call rotation and out-of-hours cover | Usually outsourced, with an internal escalation contact | 24-hour incident response, runbooks for failed joins, audio or recording outages |
| Vendor escalation to BigBlueButton Inc. | Shared: support partner escalates, internal owner signs off on commercial support | Clear bug reports with logs, version details and reproduction steps for a commercial support team |
| Recording storage housekeeping | Usually in-house, with the support partner running cleanup jobs | Disk capacity planning, retention policy design, privacy handling of stored recordings |
What usually goes wrong after go-live
These failure patterns appear most often in BigBlueButton upgrades and day-to-day operations. Each one has a prevention step to build into the change plan, the runbook or the monitoring before the service is relied on.
In-place upgrade from 3.0 to 4.0
BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit, and the install docs do not support direct upgrades from 2.6, 2.7 or 3.0. Running the 4.0 installer over an existing 3.0 server can leave mixed packages and broken services. Prevention: plan a clean 4.0 server, move Greenlight data and recordings across deliberately, and keep a tested rollback path.
LMS launch fails after host change
LMS integrations sign requests with the shared secret and expect a specific hostname. Changing either during maintenance makes launches fail with checksum or redirect errors, often in the LMS that was not tested. Prevention: update the secret and hostname in every LMS together, then launch a test meeting from each integrated platform before closing the change.
Media blocked by firewall or missing TURN
Media needs UDP ports 16384 to 32768 reachable, so a firewall edit that closes them leaves audio and video failing while chat still loads. Users behind restrictive networks also need a TURN server, which the install docs recommend but which is easy to omit. Prevention: treat port rules as change-controlled, test a call from outside the network after each edit, and confirm TURN works from a restricted network.
Recording disks fill before alerts fire
The 4.0 install docs call for 500 GB of disk for recordings, or 50 GB without recording. Recordings accumulate quietly, and a full disk stops new recordings and can disrupt the host. Prevention: alert well before the disk is full, define a retention and archival policy, and confirm recordings are copied off the server before any cleanup runs.
Host patches without a restart window
Ubuntu security updates can restart services or require a reboot, which ends any live classes in progress. Patches applied during teaching hours cause dropped sessions that nobody is watching for. Prevention: agree maintenance windows with the academic calendar, test patches on a staging server first, and check that BigBlueButton services are healthy after each reboot.
Scalelite NFS and database issues under load
Scalelite depends on a PostgreSQL database, a Redis cache and an NFS shared volume for recordings. NFS latency and database connection limits often appear only at peak concurrency, so a light test can pass and a busy day can fail. Prevention: load test with realistic concurrency before go-live, monitor NFS latency and database connections, and treat these components as their own sizing tier.
How support changes by starting point
A single server running Greenlight or LTI is the simplest case. One host carries media, the web front end and recordings, so one patch window affects everything at once.
- Test scope: After each 3.0 maintenance release or a 4.0 update, rerun a join, audio, video, screen share, a recording and the Greenlight login or LTI launch on that same server.
- Monitoring and on-call: Watch CPU, memory, recording disk space, TCP 443 reachability and the UDP media range. Alerts usually go to one on-call rota.
- Upgrade path: 4.0 installs on Ubuntu 24.04, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a clean rebuild with a tested restore of Greenlight data.
- Package access: Confirm with the vendor which repository the installer reads, and confirm that your server can reach it on a schedule you control.
A Scalelite pool places several BigBlueButton servers behind one entry point. Capacity survives a single node failure, but the shared components become the parts most likely to cause an outage.
- Test scope: Update one node at a time, then test meeting placement, failover of a node removed from the pool and a recording written to and read from the shared volume.
- Monitoring and on-call: Track per-node status, PostgreSQL and Redis health, NFS latency and free space on the recording volume. Losing shared storage affects every node.
- Version alignment: Confirm that the Scalelite release you run supports the BigBlueButton branch on each node, and stage that pairing before changing either side.
- Package access: Ask the vendor whether Scalelite and BigBlueButton packages are obtained through the same channel and whether your support terms cover both.
When the LMS team owns the launch configuration, a BigBlueButton update can break course access even though the conferencing server is healthy. Two teams share the outcome.
- Test scope: After any server or LMS change, test a course launch for instructors and students, role mapping, recording visibility and the return path into the course.
- Change control: Agree in writing which team tests, who approves a change and who communicates a planned window to instructors.
- Monitoring and on-call: Watch LMS launch error reports alongside server logs. A shared secret mismatch appears as a failed API call, so define who receives that alert.
- Package access: Confirm with the LMS vendor which BigBlueButton integration version it supports and whether that integration tracks the server branch you run.
On a private network or air-gapped site, updates are staged on a mirror, verified and carried in by hand. Each step adds time, so the update cycle depends on the transfer process as much as on the software.
- Test scope: Run the full regression set on a staging copy before anything crosses the boundary, including the Docker images used for LibreOffice document conversion.
- Integrity checks: Verify checksums of every transferred package and image, and record which versions entered the network and when.
- Monitoring and on-call: Monitoring must run inside the network, with no external call-home. Plan the on-call response around transfer windows, not only around alert timing.
- Package access: Ask the vendor how offline packages are obtained, which Ubuntu packages and Docker images must be bundled, and whether support covers offline installs and branch upgrades.
What you need to provide
Before support starts, the first thing to settle is how we reach the servers. We need either SSH with sudo rights on every BigBlueButton host, or access to the deployment pipeline that builds and rolls out those hosts if you manage them through code. Alongside access, provide the current server inventory: hostnames, the Ubuntu release on each host, whether BigBlueButton was installed with bbb-install.sh or from packages, and whether Greenlight, LTI components, TURN or Scalelite run on the same machines. Without that list, the baseline will rest on guesses. For the first baseline, also provide LMS administrator contacts for each connected Canvas, Moodle, Schoology or other platform, plus at least one test course per LMS where we can join meetings, record and check playback. Name the DNS and certificate owners too, because renewals and hostname changes during a patch can break SSL or the join links that LMS integrations use. Confirm who holds the registrar and certificate authority accounts.
Every patch cycle needs three things from you: the agreed maintenance window, the change freeze calendar (exam weeks, enrollment periods, graduation events), and a named business owner who approves each change before it goes live. Confirm the recording retention rules as well, since a patch may move or prune recordings on the 500 GB disk, and the rules decide what must be backed up first. Ask the business owner to confirm whether a rollback to the previous package is acceptable within the window, and what counts as a failed upgrade. Finally, decide two operational points. Choose the monitoring and paging tools that will watch the servers and alert the on-call engineer, and confirm who speaks to end users during an incident: the LMS team, the faculty support desk, or a communications lead. These decisions shape the runbook and the escalation path, so make them before the first incident, not during it.
Frequently asked questions
What drives the cost of BigBlueButton support, and how is it quoted?
DeployOpen quotes from a written scope, and the scope sets the price. The main drivers are the number of BigBlueButton servers and whether they sit behind Scalelite, the number of LMS integrations that need retesting after each change, recording storage and retention, the patch cadence across the 3.0 and 4.0 branches, and the on-call hours and response expectations you set. Ask the quote to separate one-time work, such as onboarding existing servers, from recurring work, such as patching, monitoring and on-call coverage.
Can our own team patch BigBlueButton, or do we need a partner?
Yes, your own team can patch BigBlueButton using the install documentation and a staging server before production. What is usually outsourced is the work around the patch: testing the LMS platforms you run, such as Canvas, Sakai, D2L or Schoology, after each update, and carrying the on-call load when a release causes a login or call-quality problem outside office hours. Ask any partner to confirm which of these tasks its scope includes and which stay with your staff.
How long does a BigBlueButton patch cycle take?
The length of a patch cycle is set in the written scope, so there is no fixed figure to quote. It depends on how many servers you run, whether each change needs a staging test and an LMS regression pass, how many maintenance windows your institution allows, and how many approvals sit in your change process. The 3.0 branch still receives maintenance releases, such as 3.0.39 on October 2, 2026, so plan for a steady cadence. Ask the partner to list the steps, who signs off each one and how long a rollback takes.
Can a BigBlueButton 3.0 server be upgraded in place to 4.0?
No. Direct upgrades from 2.6, 2.7 or 3.0 to 4.0 are not supported, and the install documentation recommends a clean server installation on Ubuntu 24.04 64-bit. The usual path is a new 4.0 server built alongside the 3.0 system, with Greenlight rooms, recordings and LMS settings carried over and tested before cutover. Recordings and room data move as separate tasks, so ask for those migration steps in writing. BigBlueButton 4.0.0 was released on October 14, 2026, so confirm the current 4.0 maintenance level before you build.
What hardware and network does a BigBlueButton 4.0 server need?
According to the install documentation, 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 of symmetrical bandwidth. The network must allow TCP ports 80 and 443 and UDP ports 16384 to 32768, the server needs a valid hostname for SSL, and Docker is required for sandboxed LibreOffice conversion. A TURN server is recommended for users behind restrictive firewalls. These are minimums for one server, so confirm capacity against your own peak class sizes.
How does DeployOpen support differ from BigBlueButton Inc. commercial support?
BigBlueButton Inc. maintains the project and offers hosting and commercial support through its own site, so ask it directly what its support covers. DeployOpen is a separate company that plans, implements, hardens, upgrades and supports BigBlueButton inside your own infrastructure under a written scope. The two can address different needs. Confirm with each vendor which responsibilities it carries before you sign anything.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including BigBlueButton servers on the 3.0 and 4.0 branches. Each engagement starts from a written scope, so you know what is covered before work begins.
How we scope
- Inventory which BigBlueButton branch each server runs, and whether it is a 3.0 or 4.0 install on Ubuntu 24.04.
- Record the LMS integrations, Greenlight or LTI links and recording retention that each upgrade must not break.
- Agree in writing which patching, testing, monitoring and on-call tasks are in scope, with fixed deliverables and timelines.
How we build
- Plan patch windows around the 3.0 maintenance releases and any 4.0 point releases your team needs to adopt.
- Test LMS integrations, including Canvas, Moodle, Sakai, D2L and Schoology, in a staging environment before production changes.
- Check media ports, TURN reachability, bandwidth and call quality metrics after each change, and record the results.
How we hand over
- Document the upgrade runbook, rollback steps and the server build your team will reuse for future updates.
- Walk your operations staff through monitoring dashboards, alert thresholds and the escalation path for call quality problems.
- Deliver the configuration, test evidence and access records in your own repositories, so your team owns the service.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, with coverage hours agreed in the written scope.
- Confirm with us during scoping which incidents go to on-call coverage and which go to your own service desk.
- Ask any quote to itemize patching, LMS regression testing, monitoring, and on-call hours as separate, recurring or one-time lines.
