BigBlueButton single server vs Scalelite cluster

No, not directly. Direct upgrades from 2.6, 2.7 or 3.0 are not supported for BigBlueButton 4.0, so the install documentation recommends a clean server installation on Ubuntu 24.04. A single server means one clean rebuild, followed by moving your configuration, recordings and any LMS or Greenlight settings across by hand. In a Scalelite pool, you repeat that process for every BigBlueButton server, one at a time, so that the remaining servers keep carrying meetings during each rebuild. Plan a staged cutover, keep the previous build available for rollback, and confirm the migration path with the BigBlueButton project before you commit to a date. Ask your provider how they will sequence the pool rebuild and test it on a non-production pool first.

Back up recordings and configuration on every BigBlueButton server, and back up the database on the Scalelite side. On a single server, the recordings sit on the same disk as the server, and the install documentation sizes that disk at 500 GB when recording is enabled, so storage growth is the main recurring cost to plan for. In a pool, recordings are consolidated and indexed by Scalelite in its PostgreSQL database, so you need consistent backups of that database together with the recording files they point to. The Scalelite NFS shared volume also needs its own backup policy. Restore tests matter more than backup jobs: ask your team to restore a recording and a database snapshot into a staging environment before go-live, and document the recovery order.

Monitor each BigBlueButton server, the Scalelite server, PostgreSQL, Redis and the NFS volume as separate components. Scalelite checks each server's reachability and load and places new meetings on the least loaded server, so a failing server is partly handled by the balancer, but it will not alert your team on its own. On a single server, monitoring centers on CPU, memory, disk growth for recordings, bandwidth and the UDP media ports. In a pool, add checks for the number of servers that pass Scalelite's reachability test, Redis persistence status, database connections and NFS latency, because a shared storage slowdown can affect recordings across the whole pool. Confirm with the Scalelite project which metrics and endpoints it exposes in your version, and build alerting around those rather than assumptions.

A TURN server is recommended, and it becomes more important as your users sit behind restrictive firewalls. The BigBlueButton install documentation recommends one for users who cannot reach the media ports directly, so it is an extra service you must install, certify, monitor and renew certificates for. On a single server it is one additional host or container to maintain. In a Scalelite pool, the TURN configuration has to be consistent across every BigBlueButton server, and the Scalelite README lists TURN server administration among the skills the setup requires. Ask your team who owns TURN after go-live, how credentials are rotated, and how bandwidth for relayed media is sized. Plan for it in the design rather than adding it after users report failed audio.

The Scalelite README says setup requires advanced technical knowledge of BigBlueButton, Linux, Docker, networking and TURN server administration. A single BigBlueButton server needs the same BigBlueButton and Linux knowledge, with fewer moving parts, because it has no load balancer, shared volume or database tier to keep consistent. A pool adds Docker to run the Scalelite services, PostgreSQL and Redis administration with persistence enabled, NFS permissions and performance, and networking across several hosts and the balancer. Ask whether your staff can cover those skills for on-call response, or whether you need a partner for the initial build and runbooks. The checklist below is a practical way to test readiness before you commit.

• Can your team rebuild a BigBlueButton server from a clean install on a set schedule?
• Can they restore PostgreSQL, Redis and NFS data together?
• Can they diagnose TURN and firewall failures for end users?

The cost of ownership recurs in staff time, infrastructure and any support contract, and the mix shifts as you add servers. A single server has the lowest recurring infrastructure footprint, but a single failure takes all classes offline, so you pay in risk rather than hardware. A pool spreads capacity across several BigBlueButton servers and adds the Scalelite server, database, cache and shared storage, each with its own patching and backup work. Your costs come from your own staff, cloud or data center resources, bandwidth, and any external help you buy. Ask any provider for a written quote that separates the one-time build, the first clean rebuild cycle, and the recurring tasks for monitoring, backups, upgrades and TURN, so you can compare the two models on the same basis.

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For BigBlueButton, that can cover the initial single server or pool design, the Scalelite build, backup and monitoring setup, runbooks and upgrade work. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Confirm in that scope how pool rebuilds, TURN administration and on-call response are split between your team and DeployOpen.

One server can be enough when your peak concurrency stays below what a single well-sized server handles, and the Scalelite README says a single server meeting the minimum configuration supports around 200 concurrent users. That figure assumes the minimum hardware, so count your peak simultaneous learners and staff, add headroom for growth, and confirm the per-server limit with the BigBlueButton project for your workload mix. Video-heavy classes use far more bandwidth and CPU than audio-only sessions, so test with a realistic class profile before you commit. Also plan for a second server in case the first one fails, since a single server is a single point of failure.

The Scalelite README recommends a minimum of 3 BigBlueButton servers in the pool. The reason is resilience and headroom: with three or more servers, Scalelite can place new meetings on the least loaded healthy server, and the pool keeps working when one member is down or being upgraded. Treat three as the project's stated floor, not a sizing result for your classes. Confirm with the Scalelite maintainers how a pool behaves during a server failure, and ask whether your peak load still fits when one server is removed from service.

The cost has five parts: hardware or cloud instances, bandwidth, staff time to install and operate, outside help, and recurring upkeep. A single server needs at least 16 GB of memory, 8 CPU cores, 500 GB of disk for recordings (or 50 GB without recording) and 250 Mbit/s symmetrical bandwidth, according to the BigBlueButton install documentation. A Scalelite pool multiplies those servers and adds a Scalelite server sized at 4 CPU cores and 8 GB of memory, a PostgreSQL database, a Redis cache and an NFS shared volume. Each extra component adds patching, monitoring and backup work. Your hardware or cloud bill is recurring, while setup labor is largely one-time. Whoever pays for staff time, whether your team or a contractor, will carry most of the ongoing burden.

The duration depends on your team's skills, the number of servers, your network and how much integration you need, and no researched figure is available for a typical timeline. Setup covers provisioning each BigBlueButton server, configuring TURN for users behind restrictive firewalls, building the NFS volume, PostgreSQL and Redis, wiring Scalelite to your front ends and testing failover. Ask any provider for a written, fixed-scope plan that lists each deliverable and the test evidence it produces. Confirm the schedule against your change-control windows and the upgrade path, because BigBlueButton 4.0 cannot be upgraded directly from 2.6, 2.7 or 3.0 and requires a clean installation.

Your staff can run it if they already know BigBlueButton, Linux, Docker, networking and TURN server administration. The Scalelite README states that setup requires advanced technical knowledge across those areas. If that skill set is thin, plan for training or outside help, and budget for on-call coverage, since a pool has more moving parts than a single server. Ask whether at least two people can operate each component, and whether the runbooks cover database recovery, Redis persistence and NFS failures.

Ask for a written, fixed-scope quote that names every server, the Scalelite host, the database, cache and shared storage, and the front-end integrations such as Moodle or Greenlight. Request the sizing basis, the peak concurrency it covers, and the failover test plan. List which items are one-time (installation, integration, documentation, knowledge transfer) and which recur (support, upgrades, monitoring, backups, continuous testing). Confirm who supplies hardware, bandwidth and TURN capacity, and what happens to the pool if you later need more servers. DeployOpen does not publish a price list, so the quote follows from the written scope.

Integration depends on your front end and identity setup. Greenlight v3 supports external authentication through OpenID Connect, configured with environment variables, and its docs suggest Keycloak to add Google, Microsoft, SAML and other login methods. Confirm with your LMS vendor which BigBlueButton versions and API options it supports, and test checksum handling, since every API call needs a checksum computed with the shared secret. Never embed that secret in a web page.