Which should you run for online classes: BigBlueButton or Jitsi?
If you are choosing a teaching platform for your institution, run BigBlueButton when classes need a classroom design, and run Jitsi when you need lighter meetings. BigBlueButton ships slides with annotations, a multi-user whiteboard, polling, shared notes and breakout rooms, and it is built to be embedded in learning management systems. Jitsi Meet is a simpler video meeting stack under Apache-2.0 that suits small groups, office hours and staff calls, but it does not position itself as a virtual classroom. The decision turns on four conditions: the class format, whether sessions must be recorded, whether your LMS needs native embedding, and how much server administration your team can carry.
Start with the LMS. BigBlueButton is LGPL-3.0 licensed and maintained by BigBlueButton Inc., and the project states that it is embedded in Canvas, Moodle Cloud, Sakai, Jenzabar, D2L and Schoology. From Moodle 5.3, BigBlueButton is enabled by default on new installs, but administrators must register on the BigBlueButton portal and enter a server URL and shared secret before the activity works. If you run Moodle, confirm which version you operate and whether you will host your own server or use a hosted option. Recordings are the second check. A BigBlueButton 4.0 server needs 500 GB of disk for recordings (50 GB without recording), so confirm storage and retention rules with your records office before you size the server. Jitsi recording relies on the optional Jibri component, which you should test with your own class format before committing.
Team skills decide the rest. A BigBlueButton 4.0 server needs Ubuntu 24.04, at least 16 GB of RAM with swap, 8 CPU cores and UDP ports 16384 to 32768 open, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a clean install. A Jitsi deployment needs Debian 12 or Ubuntu 24.04, OpenJDK 17 and a valid HTTPS certificate, and it scales by adding videobridges. Ask a deployment partner or your own team to confirm the expected class size, peak concurrent users and whether students must join from mobile devices, since those figures set the server count. Moodle's free hosted tier limits sessions to 60 minutes and 25 concurrent users, so it is a trial option rather than a production plan for larger cohorts.
How the two platforms compare on server size, recordings and class sizes
This table sets BigBlueButton 4.0 against Jitsi Meet on license, classroom features, LMS fit, server footprint, recording components, ports, authentication and hosted options. Read each row against your class sizes and hosting plans, and treat any cell marked for confirmation as a question to put to the vendor or your own test environment before you commit.
| Aspect | BigBlueButton | Jitsi Meet |
|---|---|---|
| License | LGPL-3.0, maintained by BigBlueButton Inc. with the project's own releases such as v4.0.0 (October 14, 2026) | Apache-2.0; latest stable tag stable/jitsi-meet_11248 (September 14, 2026). Jitsi is a trademark of 8x8, Inc. |
| Classroom features | Slides with annotations, multi-user whiteboard, shared notes, polling and breakout rooms built in | Video conferencing and screen sharing; classroom tools such as polls, whiteboards or breakout rooms depend on your setup, so confirm them |
| LMS integration | Embedded in Canvas, Moodle Cloud, Sakai, Jenzabar, D2L and Schoology; Moodle 5.3 enables it by default on new installs | No LMS embedding listed in the supplied facts; confirm plugin and LTI options with your LMS vendor |
| Server requirements | 4.0 needs Ubuntu 24.04, 16 GB RAM with swap, 8 CPU cores with high single-thread performance, 500 GB disk for recordings (50 GB without) and 250 Mbit/s symmetrical bandwidth | Scales by adding videobridges; the scalable guide suggests a 4 CPU, 8 GB central server and 4 or 8 CPU with 8 GB RAM per videobridge |
| Recording components | Recording is built into the server; recordings consume the 500 GB disk figure above | Jibri is an optional container for recording or streaming, deployed separately from the core stack |
| Network ports | TCP 80 and 443 free from other web servers, UDP 16384 to 32768; a TURN server is recommended for restrictive firewalls | TCP 80 and 443, UDP 10000; 5349/TCP for TCP fallback and 3478/UDP for STUN are optional |
| Authentication options | API calls signed with a shared secret; Greenlight v3 supports OpenID Connect, with Keycloak suggested for more login methods | Internal XMPP accounts, JWT tokens, LDAP, Matrix verification or a hybrid mode configured in .env; JWT is recommended over the deprecated secure domain method |
| Hosted options | Moodle's free BigBlueButton tier limits sessions to 60 minutes, 25 concurrent users and deletes recordings after seven days; BigBlueButton Inc. offers paid hosting | Public meet.jit.si instance; 8x8 offers JaaS. Confirm current limits and terms directly with each provider |
What changes the result for a teaching team
Six factors decide most teaching deployments: class size, session length, recording rules, the LMS in use, network constraints and Linux skills. Each one tilts the choice toward BigBlueButton or Jitsi, so check them in this order before you size any server.
Class size and concurrent users
Large cohorts push you toward a platform designed around a moderator and a shared room, not a flat meeting. BigBlueButton's classroom model with slides, polls and breakout rooms suits scheduled lessons. Jitsi's lighter meeting model scales by adding videobridges, so confirm how many participants your largest class will put in one room and test that load before committing. Check the concurrency your LMS plan or hosting tier allows.
Session length
Long lectures and multi-day courses make server stability and memory use more important than feature depth. BigBlueButton's hosted free tier caps sessions at 60 minutes, so any longer teaching depends on a server you run. Jitsi rooms have no comparable cap in the supplied facts, but you should test long sessions with your own participant mix and client devices before relying on either platform.
Recording retention
If lessons must be kept for a term or an accreditation period, the recording design decides the outcome. Moodle's free BigBlueButton hosting deletes recordings after seven days, so a retention rule forces self-hosting. A BigBlueButton 4.0 server needs 500 GB of disk for recordings. Jitsi recording runs through the optional Jibri component, which adds a separate container to size and operate.
LMS already in use
If your teaching runs in Moodle, Canvas, Sakai, D2L or Schoology, BigBlueButton is the more direct fit because LMS embedding is its core design. Moodle 5.3 enables it by default on new installs, but administrators must register on the BigBlueButton portal and enter a server URL and shared secret before anyone can use the activity. Jitsi needs a separate integration step, so confirm which LMS plugin your team will maintain.
Bandwidth and firewall constraints
Students behind restrictive school or campus firewalls can block the UDP media ports both platforms use. BigBlueButton needs TCP 80 and 443 plus UDP 16384 to 32768, and the project recommends a TURN server for restricted networks. Jitsi needs 10000/UDP, with 5349/TCP as a TCP fallback and 3478/UDP for STUN as optional. Test from the networks your students actually use, and budget for the 250 Mbit/s symmetrical bandwidth BigBlueButton 4.0 asks for.
Linux server skills in the team
Both platforms are self-hosted, so someone must own patching, certificates and backups. BigBlueButton 4.0 installs on Ubuntu 24.04 with a clean server, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, which makes upgrades a rebuild task. Jitsi's Debian and Ubuntu quick start and Docker setup are lighter but still need a valid HTTPS certificate. Name the person who will run each upgrade before you choose.
Why BigBlueButton's server needs differ from Jitsi's component stack
BigBlueButton 4.0 is planned as a single-server install with stated minimums, while Jitsi Meet is planned as a set of cooperating components. The BigBlueButton install documentation asks for Ubuntu 24.04, 16 GB of memory with swap, 8 CPU cores with high single-thread performance, 500 GB of disk if recordings are kept (50 GB without recording) and 250 Mbit/s symmetrical bandwidth, with UDP ports 16384 to 32768 and TCP ports 80 and 443 reachable. For a class platform, the decision is whether one machine of that size covers your largest expected session and your recording retention. Check the peak concurrent users and the recording volume per term against those minimums before you size hardware, and confirm the current figures in the BigBlueButton install documentation because they change between branches.
Jitsi splits the same job across a web server, Prosody for XMPP signalling, Jicofo for conference focus, one or more Jitsi Videobridge media routers, and optional Jibri and Jigasi for recording and SIP dial-in. The Jitsi handbook architecture page describes this layout. Horizontal scaling in Jitsi means adding videobridges as the load grows, and the scalable setup guide notes the default install is already configured for it. For your team, that means a second skill set: monitoring each bridge, keeping their configuration consistent, and handling the signalling and certificate work in one place. Ask whether your staff can run more than one host and whether a recording component must be placed on separate hardware. Note that Jibri is a separate container on the Docker path, so its load is not shared with the bridge.
Upgrade planning differs sharply between the two. BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so the project recommends a clean server installation. Any move from an older branch therefore means a new server, data migration of recordings and a planned cutover for any LMS that points at the server, such as Moodle. Jitsi components can usually be updated in place from the Debian or Docker packages, which makes routine maintenance lighter, but the team still needs a tested rollback for each bridge. Before you commit, schedule a rehearsal on a non-production host and confirm the upgrade path with the vendor for your version.
Which platform fits which teaching situation
If your teaching runs through Moodle, Canvas or another learning management system, the question is how the virtual classroom sits inside the course. BigBlueButton is built for this use. It is embedded in several LMS products, and from Moodle 5.3 it is enabled by default on new installs, although administrators must still register on the BigBlueButton portal and enter a server URL and shared secret before the activity works. The advantage matters most when instructors need slides with annotations, a multi-user whiteboard, polling, shared notes and breakout rooms inside a scheduled class. Jitsi can be linked to an LMS, but it is a meeting tool first and does not provide that classroom layer out of the box.
- Native activity support: BigBlueButton exposes sessions as LMS activities, so attendance and access follow the course.
- Moodle default: From Moodle 5.3, the activity is on by default for new installs, but a portal registration and shared secret are still required.
- Free hosted tier limits: Moodle's free BigBlueButton hosting tier caps sessions at 60 minutes and 25 concurrent users, and deletes recordings after seven days.
- Teaching tools: Polling, the whiteboard, shared notes and breakout rooms are part of the classroom design.
- Self-hosted integration: The install script can add Greenlight or LTI support on the same server.
Confirm with your LMS administrator which BigBlueButton option (Moodle's hosted tier, a commercial host or your own server) matches your session length, class size and retention rules.
For office hours, project teams or staff meetings that are not tied to a course shell, the lighter model of Jitsi often fits better. Jitsi Meet is Apache-2.0 licensed and runs as a set of components: a web server, Prosody for signalling, Jicofo for conference focus and one or more Jitsi Videobridge media routers. Rooms can be created quickly from a browser, and the stack does not require the full classroom toolset. The trade-off is that you give up the structured classroom features. This advantage matters when the goal is quick, low-friction conversation rather than a scheduled lesson with materials.
- Simple room model: Participants join a named room, which suits drop-in meetings.
- Lighter footprint: The Jitsi quick start targets Debian 12 or Ubuntu 24.04 with OpenJDK 17, and the scalable guide suggests a 4 CPU, 8 GB central server.
- Authentication choices: The Docker guide covers internal XMPP accounts, JWT tokens, LDAP and Matrix verification, and the handbook recommends JWT for new installs.
- Guest access: A separate anonymous domain can be used for guests.
- HTTPS requirement: A valid certificate is needed for working audio and video, and self-signed certificates cause problems, especially on mobile.
Confirm how many participants each room will hold and whether you need the classroom features listed in the other tabs before settling on Jitsi.
Recording changes the infrastructure decision. BigBlueButton 4.0 recommends 16 GB of memory, 8 CPU cores with high single-thread performance and 500 GB of disk for recordings, or 50 GB without recording, plus 250 Mbit/s symmetrical bandwidth. Its install needs UDP ports 16384 to 32768 and TCP ports 80 and 443 free of other web servers. Jitsi splits recording into Jibri, which is optional and runs as a separate component, and its scalable design adds videobridges horizontally. The right choice depends on whether lectures need to be archived inside the class platform or whether recording is a secondary need.
- Built-in recording path: BigBlueButton stores recordings on the same server, so disk planning is part of sizing.
- Disk and retention: Storage for recordings and retention rules must be sized before the first term.
- Optional Jibri: Jitsi recording or streaming requires adding the separate Jibri component.
- Horizontal scale: Jitsi videobridges can be added as class sizes grow, and the default install is already set up for this.
- Upgrade path: BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so a clean server is recommended.
Confirm the largest concurrent class size, the recording retention period and whether recordings must stay inside your own network before sizing either platform.
Some institutions want a vendor to run the service, while others must keep recordings and student data in their own environment. BigBlueButton Inc. offers hosting and commercial support through bigbluebutton.com, and Moodle's free tier is a hosted option with stated limits. Jitsi is also available as a hosted service through 8x8's JaaS offering, and the public instance at meet.jit.si is free to use. Self-hosting either platform means your team owns the server, the certificates, the backups and the upgrades. This matters most when data residency, network isolation or long retention rules apply.
- Hosted options: BigBlueButton Inc. offers hosting, and 8x8 offers JaaS for Jitsi.
- Free public use: The public Jitsi instance and Moodle's hosted tier have limits that suit trials rather than full programs.
- Self-hosting effort: Plan for server sizing, TLS, firewall rules and clean-install upgrades.
- Trademark note: Jitsi is a trademark of 8x8, Inc., so check naming and branding terms if you white-label the service.
- Support scope: Confirm whether the hosted provider or your own staff handles incidents for each option.
Confirm the data location requirements, the hosting regions available from each provider, and the support terms in writing before choosing a hosted or self-hosted path.
How to test both platforms against your class sizes and recording rules
This sequence turns class formats and recording rules into measured results on both platforms, so the choice rests on your own load instead of vendor summaries. Each step produces a record you can compare side by side before committing to one stack.
Define class formats and peak concurrency
Course or academic lead lists every class format you run, such as lectures, seminars, office hours and breakout-heavy workshops, with the largest expected number of simultaneous students and moderators for each. Record session length, how many sessions overlap in a normal week and whether any class must be recorded. The output is one table of formats, peak concurrent users and recording needs, which every later step uses as its target.
Check Moodle free tier limits against your table
Platform owner compares the table with Moodle's free BigBlueButton hosting limits: sessions of 60 minutes, 25 concurrent users, recordings deleted after seven days, and student webcams visible only to the moderator. Mark every format that exceeds any limit and every format that depends on recordings lasting longer than a week. The output is a short list of formats that need a self-hosted or paid route, and a list that stays within the free tier.
Build a BigBlueButton 4.0 test server
Infrastructure engineer provisions a clean Ubuntu 24.04 host that meets the BigBlueButton 4.0 minimums: 16 GB of memory with swap, 8 CPU cores, 500 GB of disk for recordings, and 250 Mbit/s symmetrical bandwidth. Open UDP 16384 to 32768 and TCP 80 and 443, confirm no other web server holds those ports, and install with a valid hostname for SSL. The step closes when a test room loads in a browser with audio, video and a shared whiteboard working.
Build a Jitsi Meet test stack
Infrastructure engineer builds a second environment on a supported Debian or Ubuntu release with OpenJDK 17, or uses the Docker setup, opening 80/TCP, 443/TCP and 10000/UDP. Add a domain certificate from a public authority, since the Jitsi handbook says self-signed certificates cause audio and video problems, especially on mobile. Plan the Prosody, Jicofo and videobridge components as separate roles so that a second videobridge can be added later. The step closes when a multi-party test call works from a laptop and a phone.
Run a timed pilot behind your firewall
Course lead and a small group of students, staff and external guests join both test environments from inside and outside the campus network, using the formats from step one. Run a timed session at the peak size, include a breakout or whiteboard activity, and record one session on each platform with the recording settings your policy requires. Log connection failures, dropped audio, and whether students behind restrictive firewalls needed a TURN server. The output is a pilot log for each platform.
Measure CPU, bandwidth and recording storage
Infrastructure engineer samples CPU load, memory, network throughput and disk growth on each server during the pilot, then calculates storage for a full term of recordings using the length and number of sessions from step one. Compare the measured figures with the BigBlueButton 4.0 minimums and with the Jitsi scaling guidance for the central server and each videobridge. The output is a per-session resource profile and a storage estimate that you can take to a capacity review.
Confirm authentication and TLS requirements
Identity lead checks how each platform will sign in teachers and students, comparing BigBlueButton's shared secret checksum model and Greenlight's OpenID Connect option with Jitsi's JWT token authentication, LDAP and the deprecated secure domain method. Confirm the certificate, hostname and port requirements with the LMS team and your security office, and ask both vendors or communities to confirm how their current releases handle these settings. The output is a signed-off authentication design and a TLS plan for each option.
Decide with the pilot records in hand
Project sponsor reviews the format table, the Moodle tier comparison, the pilot logs, the resource profiles and the authentication design together, then selects a platform for each class format that needs one. Record any format that still lacks a fit and what would close the gap, such as a larger server, a different recording retention policy or a hosted plan. The output is a written decision that names the platform, the server sizing and the retention rule for each format.
Questions buyers ask before choosing or hiring help
What does running BigBlueButton or Jitsi cost in staff effort?
Staff effort, not licence fees, is the main cost for both platforms, because both are open source and the software itself is free to download. BigBlueButton carries more fixed work: a dedicated server sized to the supplied minimums, TLS, firewall rules, recording storage and upgrades that must be done as clean installs. Jitsi carries less infrastructure but still needs a JWT or other authentication decision, certificate management and scaling of videobridges as class sizes grow. Ask any provider for a quote that separates one-time build work from recurring upkeep, and that states who maintains the server after handover.
How long does a clean BigBlueButton install take compared with Jitsi?
The supplied facts do not give a duration for either install, so confirm timing against your own environment. The effort differs in kind: BigBlueButton 4.0 needs Ubuntu 24.04, 16 GB of RAM with swap, 8 CPU cores, 500 GB of disk if you record, and UDP ports 16384 to 32768 open, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so a clean server is the recommended path. Jitsi's Debian or Ubuntu quick start requires OpenJDK 17 and ports 80, 443 and 10000/UDP, and its Docker setup runs separate containers. Ask for the sequence of steps, the hardware and network prerequisites checked before work starts, and what testing is included.
What does the institution's IT team need to provide?
Your IT team usually supplies the network and DNS, the server or cloud account, a valid hostname for SSL, and firewall changes. For BigBlueButton, the team must also confirm that ports 80 and 443 are not taken by another web server, and it should decide whether a TURN server is needed for students behind restrictive firewalls. For Jitsi, HTTPS with a proper domain certificate is required, since self-signed certificates cause problems, especially on mobile. If you connect to an LMS such as Moodle, the team also needs to register with the BigBlueButton portal or manage the shared secret and authentication settings.
Can a teaching team run either platform without outside help?
A team with Linux administration, DNS and certificate skills, and someone who can own the LMS integration, can run either platform without an outside partner. The harder parts are capacity planning for live classes, recording retention, authentication, and routine upgrades. BigBlueButton's upgrade path means planning a clean install rather than an in-place update, which is a recurring task. Jitsi's horizontal scaling is simpler to add to, but it still needs monitoring for media load. Be honest about who will be on call during a live lesson and how many people can cover that role.
What should a fixed-scope implementation quote for online classes include?
A fixed-scope quote should name the platform, the version and the target operating system, and list each deliverable with its acceptance test. For BigBlueButton, include server sizing against the supplied minimums, the bbb-install.sh steps, any Greenlight or LTI setup, LMS integration, authentication, TLS, recording storage and retention, backup, and handover documentation. For Jitsi, include the chosen authentication method, the domain and certificate setup, any videobridge scaling plan, and the Docker or package install path. Ask for the exclusions, the testing that is included, the support period after go-live, and the timelines agreed in writing before work starts.
When does a hosted option make more sense than self-hosting?
A hosted option makes more sense when the institution does not want to run servers, cannot staff on-call cover for live classes, or needs capacity that changes sharply from term to term. Moodle's free BigBlueButton hosting tier is limited to 60-minute sessions, 25 concurrent users and seven-day recording deletion, so it fits small trials rather than full course loads. Self-hosting suits institutions that need longer sessions, retained recordings or control of student data within their own infrastructure. Compare the hosted terms and the self-hosted running cost side by side before deciding, and confirm the data location and retention rules with the provider.
What it costs to switch platforms after classes have started
Switching from BigBlueButton to Jitsi, or the reverse, after a course is running is rarely a simple tool swap. The cost sits in three places: the recordings you have already made, the activity configuration inside the LMS, and the moderator roles that teachers and teaching assistants hold in each session. Jitsi Meet has no virtual classroom layer with slides, polls, whiteboard and breakout rooms as BigBlueButton does, so course content built around those features will need to be rebuilt or replaced, not carried across. Before any move, list every course that uses BigBlueButton features and mark which ones depend on them.
Recording retention is the constraint that most often catches planners off guard. On Moodle's free BigBlueButton hosting tier, recordings are deleted after seven days, so a teacher who expects to reuse a session next term may already have lost it. If you are on that tier, download anything you need before you plan the cutover, and do not count on the archive still existing when the migration date arrives. For a self-hosted BigBlueButton 4.0 server, recordings sit on local disk, and the 500 GB figure in the install documentation is the planning guide for that storage, not a migration tool. Jitsi recordings depend on whether Jibri was deployed, which is an optional component, so confirm its status before assuming any archive exists.
Before committing, confirm three things with the vendor or in a test environment: how recordings can be exported in a usable format, whether the export keeps the metadata a course needs, and how moderator roles can be recreated in the target platform. Moderator permissions in BigBlueButton are tied to the LMS role and to the join links that the LMS generates, so a teacher's access will need to be rebuilt on the new side rather than copied. Jitsi controls room access through its own authentication options, which must be configured separately in the .env file for the Docker setup or in the Prosody and Jicofo configuration for a package install. Ask your implementation partner for a written list of those steps, a test migration of one course, and sign-off from the teaching staff before any live class moves.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a choice between BigBlueButton and Jitsi for online classes, the work starts with the teaching requirements and ends with a platform your staff can run.
How we scope
- Written scope lists the LMS integrations, class sizes and recording rules you need before any build begins
- Scope records which server sizes, bandwidth and ports your network team must provide
- Engagements are fixed-scope, with deliverables and timelines agreed in writing up front
- Scope names who approves authentication choices, such as JWT tokens or LTI, before work starts
How we build
- We install and configure the chosen platform inside your infrastructure, with HTTPS certificates on a proper domain
- We integrate the platform with your LMS and identity provider and test student, teacher and moderator roles
- We test recording storage, retention and access controls against the requirements written in scope
- We run security testing on the deployment and document the findings and fixes for your review
How we hand over
- Handover includes architecture notes, configuration records and runbooks for your administrators
- We document backup, upgrade and recording cleanup procedures so staff can repeat them without us
- We prepare evidence for compliance assessments, while independent auditors and certification bodies issue any attestations
- Training for instructors and administrators is included where the written scope asks for it
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover version upgrades, including clean reinstalls where a platform release requires one
- Quotes follow from the written scope, so ask us to itemize one-time build work against recurring support
- Ask us to confirm any capability you need against the current release before you commit to a platform
