Google Meet vs BigBlueButton

Server capacity is the largest recurring infrastructure line, and it depends on the number of concurrent classes and whether recording is on. The BigBlueButton install documentation sets a minimum for a 4.0 server of at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance and 500 GB of disk for recordings, or 50 GB without recording. Larger deployments usually add more servers and a load balancer such as Scalelite, which is a separate open-source component. Ask the vendor or integrator to quote instance types for your peak concurrent sessions, and to state whether that quote is on your own hardware or a cloud account you pay for directly.

Bandwidth is billed by your hosting provider or data center, and it scales with concurrent users, video use and the number of servers. The install documentation lists 250 Mbit/s symmetrical bandwidth for a 4.0 server, which is a baseline rather than a capacity plan. Egress charges on cloud platforms can exceed compute costs for large classes with webcams on. Ask for a quote that shows the assumed participants per session, video ratio, and whether the provider charges for outbound traffic or offers a flat-rate port.

Recordings are the main source of recurring storage growth. The install documentation specifies 500 GB of disk for recordings, against 50 GB without recording, so recording policy changes the disk you buy. Costs also grow with retention periods, because recordings from past terms accumulate unless you delete or archive them. Keep backups of recordings in mind too, since a second copy doubles storage. Confirm in the quote how long recordings are kept, where they are backed up, and what happens to them when a course ends.

A TURN server is recommended when users sit behind restrictive firewalls, and it relays media that cannot connect directly. The install documentation lists TCP ports 80 and 443 and UDP ports 16384 to 32768 as required, so the TURN service needs its own reachable address and bandwidth. Costs come from a second host or a managed relay, plus the traffic it carries, which is often the part that surprises schools with strict campus networks. Ask whether the quote covers TURN capacity and who monitors it.

Staff time is the cost most often underestimated, because it recurs for as long as the service runs. Upgrades need a clean installation for 4.0, since direct upgrades from 2.6, 2.7 or 3.0 are not supported, and maintenance releases on the 3.0 branch arrive separately. Monitoring, certificate renewal, disk management and capacity planning sit on top. Your cost is the hours of your own administrators, weighed against the hours during term time when a failure is most visible. Ask the provider to describe the upgrade path and expected on-call coverage in writing.

BigBlueButton Inc. offers hosting and commercial support through bigbluebutton.com, and DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your infrastructure under a fixed-scope written agreement, with ongoing support available as a retainer. Both are optional. You pay for implementation once, and support recurs, so the scope determines the cost. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask each vendor what is covered, response expectations, and whether the price includes upgrades and backups.

Often yes, because Meet is bundled into Google Workspace editions, and Gmail, Calendar, Drive and identity usually stay on Workspace. Leaving Meet alone rarely removes a line item unless you also change edition or leave Workspace entirely. Review which edition you hold, whether the price per user changes if you drop Meet features, and what email and calendar services you still need. Ask your Google reseller or account team for the per-user cost of the edition you would move to, and compare it with the BigBlueButton infrastructure and staff costs above.

A school can run BigBlueButton without its own specialists, but someone must own the server. The server needs patching, monitoring, backups, certificate renewal and capacity checks through the school year, and these tasks recur. Schools usually choose one of three models: a hosting partner, the vendor's commercial hosting and support offered by BigBlueButton Inc. through bigbluebutton.com, or a fixed-scope implementation followed by a support retainer. Ask each option for its written responsibilities, response expectations and what happens during term-time outages. Confirm the terms directly with the vendor or provider, since they are not set by this page. The main question for a school is whether the team that answers a failed class session is named and reachable.

The pilot length depends on the scope you define, and no fixed duration applies to every school. The work usually includes a clean server build, hostname and SSL setup, firewall changes, a test course in your learning management system, and a short group of teachers trying live sessions. Each step can wait on a network or procurement change, so the calendar time often exceeds the technical work. Ask for a timeline in the written scope that lists the dependencies on your side, such as DNS, firewall rules and LMS administrator access. A pilot limited to one course and one server is the simplest way to measure how sessions behave before you commit to wider rollout.

The IT team controls the network, DNS and server access that BigBlueButton depends on. Plan for these items before installation:

• A valid hostname so SSL certificates can be issued, with TCP ports 80 and 443 reachable.
• UDP ports 16384 to 32768 open for media, since restrictive firewalls can block them.
• A TURN server, which the install documentation recommends for users behind strict firewalls.
• Docker on the server, which sandboxes LibreOffice document conversion.
• About 250 Mbit/s of symmetrical bandwidth, based on the install requirements.

IT should also handle identity integration with the school directory and the LMS connection. Check the current install guide on the official documentation site before you approve the change request.

No. BigBlueButton is a virtual classroom for live sessions, and it does not provide email, calendars, contacts or document storage. Staff and students will still use Gmail, Google Calendar and Drive, or whichever services your school chooses, to send invitations and store files. The practical change is that session links come from your learning management system or the Greenlight room manager instead of a Meet link in a calendar event. If you want room bookings or invitations to appear in calendars, plan that integration separately and confirm with your calendar provider how it works. Removing Workspace is a separate decision that needs its own scope, data migration and user communication.

No. Direct upgrades to BigBlueButton 4.0 from versions 2.6, 2.7 or 3.0 are not supported, and the install documentation recommends a clean server installation. Plan a new server running Ubuntu 24.04 64-bit, then move your configuration, room settings and any recordings you need. The 3.0 branch continues to receive maintenance releases, such as 3.0.39 on October 2, 2026, so a planned migration does not have to be rushed. Check the release notes on the official GitHub releases page before scheduling cutover, and keep the existing server running until users are confirmed on the new one. Ask any implementation partner to write the migration steps and rollback plan into the scope.

A BigBlueButton 4.0 server needs at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, and 250 Mbit/s of symmetrical bandwidth. Disk needs are 500 GB if you record sessions and 50 GB if you do not. Your real capacity depends on how many concurrent classes run, how many people join each one, and whether webcams, screen sharing and recording are used at the same time. Those numbers set how many servers you need and how the cost grows, so measure peak concurrent sessions during a pilot before you size the production environment. Confirm the figures against the current install documentation at release time, since requirements can change between versions.

Greenlight v3, the room manager front end, supports external authentication through OpenID Connect, which you configure with environment variables. The Greenlight documentation suggests Keycloak as an identity broker, which can add Google, Microsoft, SAML and other login methods. This lets your school directory handle sign-in while Keycloak handles the protocol translation. Your identity team should confirm which login method the school uses, how user roles map to Greenlight roles, and how accounts are deprovisioned when students leave. Keep the shared secret used for API calls out of web pages, because the API documentation warns that anyone who reads it can create meetings on your server.

Yes. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which includes BigBlueButton. Most engagements are fixed-scope, so the deliverables, timeline and responsibilities are agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen also prepares systems and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Ask for a scope that names your LMS, identity provider, server location and support hours.