BigBlueButton implementation plan and cost

The install documentation gives the starting point for sizing: each 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 recording is enabled (50 GB without recording) and 250 Mbit/s of symmetrical bandwidth. Treat these as minimums for one server, not as a capacity figure. The docs do not state how many concurrent users one server can carry, and the number that matters to your plan depends on how your classes actually run. Ask any partner quoting the work to state the concurrency they assume per server and the usage pattern behind it.

Concurrency varies widely with usage. A 20-person seminar with audio only behaves very differently from a 60-person lecture where every student turns on a webcam, several breakout rooms open, and a presenter shares a high-motion screen. Webcam video, screen sharing and breakout rooms each add media processing and bandwidth load, so the same hardware can host very different session counts. Record the expected pattern before you commit to hardware: typical participants per session, share of users with video on, how often breakout rooms are used and whether screen sharing is routine or occasional.

The defensible way to settle a server count is a pilot on the hardware you plan to buy or rent. Run sessions that match your real profile at your expected peak, watch CPU, memory, swap use and outbound bandwidth on each server during the sessions, and note the point where audio or video quality starts to degrade. Repeat the test with the usage pattern you expect at peak, not the average day. The pilot result gives you a per-server session ceiling that you can multiply out, with headroom for failure and maintenance windows. Include the pilot effort in your plan, since it is labor your team or a partner must perform.

A pool of servers behind Scalelite is worth the added components once you need more than a single server can carry, or once you need redundancy and a single join address for users. Scalelite sends each new meeting to the least loaded server in the pool. The cost is real: it relies on a PostgreSQL database, a Redis cache and an NFS shared volume for recordings, and each of these needs its own provisioning, backup, monitoring and patching. For a small deployment, a single well-sized server is usually simpler to run. Confirm with your architect when the pool becomes the better choice for your peak.

Before anyone can check a sizing, you must supply three inputs: the expected peak number of concurrent sessions, the typical and maximum participants per session, and your recording policy, including whether recordings are kept, for how long and what share of sessions are recorded. Recording policy drives disk size (500 GB versus 50 GB per server in the install minimums) and, when pooled, the NFS capacity. Provide these figures in writing so the quote states its sizing assumptions, the pilot scope and the number of servers, and so you can compare it against your own measurements.

Three integration decisions shape the plan more than server count does: where Greenlight runs, whether the service must connect to a learning management system, and how users behind restrictive networks reach the media servers. Settle these before requesting a quote, because each one adds components, test cases and operating tasks that a server-only estimate will miss. The first decision is the front end. The bbb-install.sh script can install BigBlueButton together with the Greenlight front end or LTI support on the same server, which is the simplest layout for a single-server pilot. Running Greenlight v3 on a separate host is the usual choice when the front end needs its own patch cycle, its own TLS certificate or a separate access policy. Ask whether the institution needs LTI support for an LMS such as Canvas, Moodle, Sakai, D2L or Schoology. Each LMS connection needs its own LTI registration, shared credentials, and a test run from a course page as a student and as an instructor.

The number of LMS connections and the test effort behind them are among the largest drivers of the work. One LMS with a single course template is a short test plan. Several LMS instances, multiple versions, or separate sandbox and production tenants multiply the cases, including role mapping, recording visibility and join from mobile browsers. Confirm each LMS version and its LTI setup with the vendor and with your own environment, since the LMS and BigBlueButton release cycles do not move in lockstep. Ask the partner to list every connection in the written scope and to state which ones are included in acceptance testing. The second decision is how users reach the server from restrictive networks. BigBlueButton needs TCP ports 80 and 443 and UDP ports 16384 to 32768 to be reachable, and some campus, government or corporate networks block UDP entirely. A TURN server relays media for those users and is recommended for that reason. A TURN deployment adds its own TLS certificate, its own open ports, and its own capacity planning, because relayed traffic consumes bandwidth on the TURN host rather than on the BigBlueButton server. Ask who will measure the share of users who need relaying and who will size the TURN host against peak concurrent participants.

The third decision is user identity. At a high level, the choice is between local accounts in Greenlight, an external identity provider reached through OpenID Connect, and sign-in handled by the LMS through LTI. Greenlight v3 supports external authentication through OpenID Connect configured with environment variables, and its documentation suggests Keycloak to add Google, Microsoft, SAML and other login methods. Each choice changes who creates rooms, how roles map to instructors and students, and what the operator must support after launch. This section only sets the direction. The SSO page covers the configuration detail. Before requesting a quote, write down three answers: which front end and LMS connections are in scope, who measures and sizes the TURN capacity, and which identity path applies to each user group. Ask the partner to show how each answer changes the test plan and the number of hours it requires.

A BigBlueButton quote becomes final only when your team has named who owns each decision and what the implementer can reach. Name one owner for the BigBlueButton platform, one for the learning management system that will embed it (for example Canvas, Moodle or D2L), and one for identity, because Greenlight, LTI launches and any OpenID Connect login each involve a different team. Provide access to the target environment, whether that is a cloud account, a data center or a hypervisor, with rights to create instances, storage and network rules. Without that access, the estimate assumes work that cannot start, and the quote is revised once access is granted.

Network and naming decisions drive most of the rework. Choose the public hostname before installation, because BigBlueButton needs a valid hostname for SSL, and the DNS record must resolve to the server before a certificate can be issued. Document the TLS certificate process: who requests the certificate, which certificate authority or internal CA signs it, and who handles renewal. Name the person with authority to open TCP 80 and 443 and the UDP range 16384 to 32768 on firewalls and load balancers, and state whether a TURN server is in scope for users behind restrictive networks. Firewall change approvals often take longer than the build itself, so the schedule in the quote should reflect your approval path, not an assumed same-week change.

Sizing inputs must come from your side. Provide expected concurrent users, the number of classes or meetings running at peak, typical session length and whether sessions cluster at fixed times. These figures determine how many BigBlueButton 4.0 servers are needed and whether Scalelite for load balancing is in scope. The install documentation sets a per-server baseline of at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance and 250 Mbit/s symmetrical bandwidth, so your numbers translate directly into the hardware and bandwidth lines of the quote. Recording policy is equally binding: decide whether sessions are recorded, how long recordings are kept and who may delete them. The documentation lists 500 GB of disk for recordings against 50 GB without recording, so retention drives the storage line.

LMS access and approvals close the plan. Give the implementer LMS administrator access for the integration, along with test accounts for an instructor, a student and a course administrator in a non-production course, so LTI launches can be verified without touching live classes. Confirm the LMS version your administrators run and the integration method they will accept. Finally, name who approves go-live and who signs off the acceptance tests. If that person is not named before work starts, acceptance slips and extra test cycles appear as change requests. Items missing at this stage are rarely absent for good. They surface later as scope changes, and each one adds time and cost to a plan that was priced without them.