Self-hosted video conferencing in 2026: revisit Jitsi Meet, BigBlueButton and LiveKit before you move another meeting off Zoom

Most Indian companies did not choose their video meeting tool. It arrived in a hurry in 2020, on a credit card, because people had to talk to each other from home. Six years later the same tool runs sales calls, interviews, customer training, board meetings and, in many education companies, the actual product: live classes. Then a renewal quote arrives, or a customer asks where the class recordings of their students are stored and for how long, and somebody says, “Why don’t we just host Jitsi?”

Under the grid of faces sit signalling, a media server, a TURN relay, a recorder, storage, sign-in and UDP ports most web teams have never opened. The software decides how many of those parts you own. It does not decide whether your network, your servers and your people can carry live media for three hundred students at 7 PM on a weekday. That part is yours.

We revisit three open-source options in 2026: Jitsi Meet (a complete meeting application built from Prosody, Jicofo and the Jitsi Videobridge, under the Apache 2.0 licence), BigBlueButton (a virtual classroom with whiteboard, polls, breakout rooms and recordings, under LGPL-3.0, usually paired with the Greenlight front end or an LMS) and LiveKit (an SFU media server with SDKs, recording and AI agent tooling, under Apache 2.0, which is a building block rather than a finished meeting app). They solve different problems; the useful question is which problem you have.

There is real news this autumn. BigBlueButton 4.0.0 was released on 14 October 2026 after more than nineteen months of work, and 4.0.1 followed on 29 October. The most important change is under the hood: BigBlueButton 4.0 uses LiveKit as its default media framework for audio, cameras and screen sharing, with the older mediasoup and FreeSWITCH stack still installed as an alternative. So two of our three projects now share a media server. LiveKit server reached v1.13.11 on 25 October 2026. On the Jitsi side, the stable release 2.0.11248 came out on 14 September 2026, and the Docker packaging has had two follow-up releases, the latest being stable-11248-2 on 23 October.

This post stays with meetings, classes and in-app video calls. For the pieces around them, see Keycloak and its alternatives for single sign-on, TLS certificate automation in 2026 because WebRTC will not work without a valid certificate, and self-hosted team chat in 2026, which is often the next tool people want to move after meetings.

A scenario to keep us honest

We will use one invented company through the post. Ganga Setu Learning Systems is an invented example, not a real business: a Patna company that builds a learning management product and runs live online classes for private nursing, pharmacy and paramedical colleges in Bihar and Jharkhand. It has about 180 people. About 40 are engineers and testers, about 60 are faculty and academic coordinators who teach live classes under contract with the colleges, about 30 are in student and college support, and the rest are in sales, accounts and HR. Infrastructure is a team of three, led by Farhan, with production on VMs at a cloud provider’s Mumbai region and a few internal tools on a Proxmox host in the Patna office.

What they use today:

• Zoom accounts for about 45 hosts, mostly faculty, for live classes of 40 to 150 students. Peak load is about 8 classes at the same time on weekday evenings, between 6 and 9 PM, and on Sunday mornings before exams.
• Google Workspace for mail, calendar and Google Meet, which staff use for internal meetings.
• Their own LMS, a Django application with a React front end and an Android app, where students see timetables, notes and a link to the Zoom class.
• Class recordings downloaded by faculty to their laptops and uploaded to the LMS when somebody remembers.
• A Keycloak instance that engineering set up last year for the LMS admin panel.

What triggered the review: one college group, which receives state scholarship funds for many students, asked in its renewal contract that recordings of classes, which show students’ names and often their faces, be stored on servers in India, kept only for the semester plus 90 days, and deleted on request. In the same quarter, the Zoom renewal quote went up and a faculty member’s laptop with six months of recordings was stolen from a bus. The product head also wants a new feature: a one-to-one video “viva” inside the Android app, where an examiner can see a student, ask questions and record the session for moderation.

Farhan’s questions: which system for classes and which for meetings, how students on weak networks connect, how faculty sign in, where recordings go and when they are deleted, and can three people own this for five years?

The short version

• Decide what kind of video you need before choosing software. A teacher with slides, a whiteboard and polls is a classroom. Ten colleagues talking is a meeting. A video call inside your own app is a product feature. These map to BigBlueButton, Jitsi Meet and LiveKit in that order, and pretending one tool does all three well is the most common mistake.
• Jitsi Meet is the quickest way to a complete, browser-based meeting service you control. It is Apache 2.0, has Debian packages and a Docker setup, scales by adding videobridges, and has lobby, passwords, JWT sign-in and optional end-to-end encryption in supported browsers. Recording through Jibri needs one recorder machine or container per meeting being recorded, which is heavy.
• BigBlueButton 4.0 is a virtual classroom first: presentation and whiteboard, polls, breakout rooms, shared notes, a learning dashboard and a recording pipeline that produces playable lessons. It needs a dedicated Ubuntu 24.04 server with, in the project’s own words, 16 GB memory and 8 cores as a minimum for production. It now uses LiveKit for media by default. It has no user database of its own; Greenlight, Moodle or another LMS creates the meetings.
• LiveKit is a fast, well documented SFU with SDKs for web, mobile and servers, plus separate Egress (recording and streaming out), Ingress (bringing RTMP, WHIP and other streams in), SIP and an Agents framework for voice AI. It is excellent when you are building video into your own product. It is not a meeting app you hand to staff on Monday; the LiveKit Meet example is a starting point, not a finished service.
• Network is the real project. All three need UDP media ports open to the world, a correct public IP advertised to clients, a TURN path over TLS on port 443 for users behind strict firewalls, and enough symmetric bandwidth. Most failed pilots are network failures, not software failures.
• For Ganga Setu, our plan is: measure classes and networks in month one, pilot BigBlueButton 4.0.1 with Greenlight and Keycloak sign-in for faculty in month two, move classes in batches with recordings kept on Indian object storage under a written retention rule, keep Google Meet for internal meetings for now, and build the viva feature on LiveKit with a small prototype only after classes are stable. Jitsi is the right tool if they later leave Google Workspace for internal meetings, and not before.

Where things stand on 2 November 2026

Jitsi Meet

• Current releases: Jitsi publishes stable releases of the whole stack under one number. The latest is 2.0.11248, tagged on 14 September 2026 in the jitsi-meet and jitsi-videobridge repositories. Before it came 2.0.11146 on 3 August, 2.0.11031 on 8 June and 2.0.10978 on 20 May 2026.
• Docker releases: the docker-jitsi-meet project follows the same numbers. stable-11248 came on 14 September 2026, with environment options for ICE restarts, message moderation, advanced audio settings and a switch to turn off third-party requests from the web client. stable-11248-1 on 22 October added support for a custom certificate authority, removed some old video quality options and, in Jibri, distrusts compromised eMudhra intermediate CA keys in Chrome. stable-11248-2 on 23 October was a small fix release for Jigasi and Prosody.
• Recent structural changes: the stable-11146 Docker release in August 2026 moved the base images to Debian Trixie, introduced rootless containers, moved the web container to unprivileged ports 8000 and 8443 inside the container, changed image publishing to GitHub’s container registry and removed the deprecated Colibri WebSocket support. If you run an older compose file, read those notes before you pull new images.
• Requirements: the Debian and Ubuntu guide supports Debian 12 or newer and Ubuntu 24.04 or newer, and says OpenJDK 17 must be used. The requirements page puts the network link first, suggests 8 GB of RAM (4 GB for small meetings), says 4 dedicated cores can be enough for a basic server, and notes that Prosody can only use one core.
• Licence: Apache 2.0 for jitsi-meet, jitsi-videobridge, jicofo, jibri and jigasi. Prosody, the XMPP server it uses, is under the MIT licence. Jitsi is a trademark of 8x8, Inc.

BigBlueButton

• Current releases: 4.0.1 on 29 October 2026 and 4.0.0 on 14 October 2026. The 4.0.0 notes describe more than 19 months of development, three betas and five release candidates. On the 3.0 line, 3.0.40 came out on 28 October 2026.
• What is new in 4.0: a redesigned client with a navigation sidebar and an Apps Gallery, user list search, a dedicated guest management panel, “request to present” for viewers, pinned chat messages, optional consent before a moderator unmutes someone, a learning dashboard for breakout rooms, an Audio settings tab with an optional WebAssembly noise filter, BlockNote as the only shared notes editor (Etherpad is removed), a plugin SDK 1.0 pre-release and LiveKit as the default media framework. 4.0.1 added rate limits on presentation uploads, an experimental “Last-N” audio mode for the LiveKit bridge, and a setting to keep browser-based live caption transcription on the user’s device.
• Support window: the project’s security policy says 3.0 gets important fixes until 14 December 2026 and security fixes until 15 March 2027, when it reaches end of life. 2.7 and earlier are no longer supported.
• Requirements: Ubuntu 24.04 64-bit with a 6.x kernel, 16 GB of memory with swap, 8 CPU cores with high single-thread performance, 500 GB of free disk for recordings (or 50 GB with recording off), 250 Mbit/s symmetrical bandwidth, IPv4 and IPv6 addresses and a hostname for a TLS certificate. The project recommends dedicated CPU, “compute-intensive” instance types on clouds, and running nothing else on the server.
• Front end: Greenlight v3 is the project’s own front end, built with Ruby on Rails and React. The latest is 3.9.0.1 on 9 September 2026; 3.9.0 made URL_HOST a required setting, so deployments without it will not start.
• Licence: LGPL-3.0 for both BigBlueButton and Greenlight.

LiveKit

• Current releases: LiveKit server v1.13.11 on 25 October 2026. The 1.13 line has moved fast, with v1.13.4 in July and five releases between 14 September and 25 October. The v1.13.11 changelog includes a cap on retransmissions per subscriber track, a new rtc.rtx_budget config option, file-backed credentials for external TURN servers, AV1 turned off for Firefox, and a rebuild with Go 1.27.3 and a patched Alpine base image, both linked in the notes to the eMudhra intermediate CA compromise.
• Around the server: Egress v1.15.0 on 6 October 2026, which updated its bundled Chrome to fix two V8 bugs that were being exploited and added a native Oracle Cloud object storage upload option; Ingress v1.5.0 on 22 April 2026, which added WHIP pass-through to the SFU and a media watchdog; and the Python Agents framework at livekit-agents 1.8.10 on 29 October 2026.
• Requirements: a single Go binary or container. For production the docs ask for a domain with a certificate from a trusted authority (self-signed certificates do not work), TLS termination at a load balancer or reverse proxy, a separate TURN domain and certificate if you use TURN, Redis for multi-node setups, compute-optimised instances and 10 Gbps networking or faster.
• Licence: Apache 2.0 for the server, Egress, Ingress, the Agents framework, the JavaScript client SDK and the LiveKit Meet example. LiveKit, Inc. also sells LiveKit Cloud, and some features in the docs and examples are tied to the Cloud, so read each page for that note.

The first questions to ask

1. What kind of sessions do you run? Classes with slides and polls, internal meetings, webinars with a few speakers and many viewers, one-to-one calls inside an app, or all of these. Count each type per week.
2. What is the peak? Concurrent sessions, participants per session and how many cameras are on. One busy hour decides your server and bandwidth, not the monthly average.
3. Where are your users connecting from? Mobile data, home broadband, college or hospital Wi-Fi, corporate networks that block UDP. The answer decides how much TURN over TLS you need.
4. Who creates meetings and who may join? Staff only, staff plus guests with a link, students from your LMS, outside examiners. This shapes sign-in and lobby settings.
5. What gets recorded, who can watch it, where is it stored and when is it deleted? Write this down before you enable recording anywhere.
6. Do you need phone dial-in, SIP rooms or live streaming to YouTube? Each adds a component and ports.
7. Is video a tool your staff use, or a feature your customers use inside your product? The second is a software project, not an installation.
8. Who owns it in year three? Upgrades, certificates, TURN, recordings storage, capacity at exam time, and a plan for the evening the media server stops.

How each one works

WebRTC conferencing in one minute

Browsers and mobile apps send audio and video using WebRTC. Media travels over UDP where possible, encrypted with DTLS-SRTP. For more than two people, sending your camera directly to every other participant does not scale, so almost all modern systems use a selective forwarding unit (SFU): each participant sends one upstream to the server, often in two or three qualities (simulcast), and the SFU forwards to each receiver the layer that suits their screen and bandwidth. The SFU does not mix video; it routes packets. A separate signalling service, usually over a WebSocket on port 443, tells clients who is in the room and how to connect. When a client cannot reach the SFU’s UDP ports, a TURN server relays the media, ideally over TLS on port 443 so it looks like normal HTTPS to a firewall. Recording is usually a separate process that joins the room as a hidden participant, either as a headless browser that captures the screen or as a pipeline that writes the media tracks to files.

Jitsi Meet: Prosody, Jicofo, the videobridge and friends

Jitsi Meet is a set of cooperating services:

• Jitsi Meet web: the React application served by nginx. The same code base is used for the Android and iOS apps through React Native.
• Prosody: an XMPP server used for signalling. Rooms are XMPP multi-user chats, and the client connects over a WebSocket. Authentication, lobby and many room features are Prosody modules.
• Jicofo, the Jitsi Conference Focus: it manages the media sessions for each conference and picks a videobridge for each new conference, which is how load is spread across bridges.
• Jitsi Videobridge (JVB): the SFU that routes audio and video between participants, by default on UDP port 10000.
• Jibri: the recording and streaming service. It launches a Chrome instance in a virtual framebuffer, joins the meeting, and captures and encodes the output with ffmpeg.
• Jigasi: a gateway that lets SIP clients and phone dial-in join conferences, and is also used for transcription.

For two-person calls, Jitsi can connect the browsers peer to peer. Jitsi’s own security page makes a point worth remembering: rooms are ephemeral, created when the first person joins and destroyed when the last one leaves, and the room name is what people need to join. On an open server, anyone who reaches it can create a room, unless you turn on authentication.

BigBlueButton: a classroom with its own media stack

BigBlueButton began in 2007 with a clear mission, stated again in the 4.0 release notes: to build an effective virtual classroom, measured in learning outcomes. The features follow that goal: a presenter with uploaded slides and a shared whiteboard, polls and quizzes, breakout rooms, shared notes, a timer, raise hand, a learning dashboard that shows participation, closed captions and live transcription, and a recording system that turns a class into a playable lesson.

On the server, BigBlueButton is a bundle of many packages on one Ubuntu machine: nginx, bbb-web (a Grails and Spring Boot application with the API), an Akka service that holds meeting state, Redis, a GraphQL layer for the HTML5 client, presentation conversion, the recording scripts, and the media stack. The media stack has changed several times:

• Early versions used Flash. The HTML5 client later replaced it.
• For WebRTC, BigBlueButton used Kurento Media Server for cameras and screen sharing, through its bbb-webrtc-sfu service, with FreeSWITCH for audio.
• From version 2.5, mediasoup replaced Kurento as the default WebRTC media server. The 2.5 notes said Kurento was still installed and still used for recording; 2.7 introduced an experimental Go recorder, bbb-webrtc-recorder, built on the Pion project, to replace Kurento for recording.
• In 4.0, LiveKit is the default for audio, cameras and screen sharing. The bbb-livekit package (livekit-server and livekit-sip) is installed by default, and the mediasoup and FreeSWITCH stack stays installed and supported. Each media type can be pointed back to the old stack per meeting or server-wide, for example audioBridge=bbb-webrtc-sfu while keeping LiveKit for cameras. Recording of LiveKit sessions uses bbb-webrtc-recorder, not LiveKit Egress.

One design choice surprises many teams. BigBlueButton has no meeting database or user database. A front end, such as Greenlight, Moodle or your own LMS, calls the create API with a shared secret, then sends users to a signed join URL. The server keeps the meeting in memory and clears it if nobody joins. Schedules, rooms, users and who may see which recording all live in the front end. This is why Greenlight exists: it gives staff a place to sign in, create rooms, share links and see recordings.

LiveKit: an SFU plus SDKs, not a meeting app

LiveKit server is a single Go program, built on the Pion WebRTC libraries. Clients connect with an access token, a JWT signed with your API secret that names the room, the participant identity and what they may do (publish, subscribe, publish data, and so on). Your application backend issues those tokens. LiveKit then handles rooms, participants and tracks, simulcast and adaptive streaming, data messages and RPC between participants, and webhooks to your backend.

Around it sit separate services:

• SDKs for web, mobile, game engines and server languages, which is where most of the value is for a product.
• Egress records or streams out: a whole room composited through a headless Chrome page, one participant, or individual tracks without transcoding. Outputs include MP4 files, HLS segments and RTMP to streaming services, with uploads to S3-compatible, Azure, Google Cloud and, since v1.15.0, Oracle Cloud storage.
• Ingress brings outside media into a room, such as an RTMP push from OBS, WHIP, or a file or URL.
• SIP connects phone calls and SIP trunks to rooms.
• Agents is a Python and Node.js framework for programs that join rooms as participants, usually for voice AI: speech to text, a language model and text to speech in a loop.

What LiveKit does not give you is a finished meeting service for staff. There is no built-in user directory, scheduling, room list, moderator role or admin console in the open-source server. LiveKit Meet is an open-source Next.js example built on LiveKit’s React components. It needs a LIVEKIT_URL, API key and secret, can be pointed at a self-hosted server, and has optional recording settings for S3. Its README describes it as built on LiveKit Components and LiveKit Cloud, and its sample environment file says the settings menu with Krisp noise filters is for use with LiveKit Cloud. Treat it as a well made demo you can learn from or fork, not as a supported product.

Network, TURN, UDP and NAT

This is the section that decides whether the pilot works. Web teams are used to one port, 443, behind a load balancer. Real-time media wants UDP, wants it direct, and wants the server to know its own public address.

Ports each project asks for

• Jitsi Meet (Debian quick start): TCP 80 and 443, UDP 10000 for the videobridge, plus UDP 3478 and TCP 5349 if you run the bundled coturn for TURN. In the Docker setup the guide asks for TCP 80 and 443, UDP 10000 and, only if you use Jigasi, UDP 20000 to 20050. For a server behind NAT, you set the public address (for Docker, JVB_ADVERTISE_IPS) so the bridge tells clients the address they can actually reach. In a split setup, bridges need UDP 10000 open to the world and TCP 5222 open only from the bridges to the Prosody server, never to the internet.
• BigBlueButton 4.0: TCP 80 and 443, TCP and UDP 3478 for STUN and TURN, and UDP 16384 to 32768 for media. The 4.0 notes strongly recommend setting a network interface filter in /etc/bigbluebutton/livekit.yaml (the rtc.interfaces.includes setting) so LiveKit advertises only the right interface. They also note a bug in 4.0.0 where bbb-conf --set-port-range did not apply to LiveKit; the fix is in 4.0.1, but the 4.0.1 notes say you should run the command again after upgrading if you had used it.
• LiveKit (self-hosted): TCP 7880 for the API and WebSocket, normally behind a TLS reverse proxy or load balancer on 443; UDP 50000 to 60000 for ICE (the docs say two ports per participant) or a single UDP mux port such as 7882; TCP 7881 for ICE over TCP; TCP 5349 for TURN over TLS, or 443 if there is no load balancer in front; UDP 3478 for TURN over UDP. SIP adds 5060 or 5061 for signalling and a UDP RTP range, by default 10000 to 20000.

TURN over 443 is not optional for real users

College Wi-Fi, hospitals, banks and strict corporate firewalls often block UDP or allow only port 443. Without TURN reachable on TLS 443, those users see the page but get no audio or video. Each project handles it differently:

• Jitsi documents TURN through coturn with ephemeral credentials handed out by Prosody’s mod_external_services module (the XEP-0215 standard). The handbook warns against static TURN credentials. To run TURN on port 443 on the same machine as the web server, it shows nginx’s stream module with ssl_preread and a second DNS name for TURN, so nginx can send TLS for the TURN name to coturn and everything else to the web server.
• BigBlueButton has long recommended a separate coturn server for TURN on 443. In 4.0 there is an optional bbb-coturn package (coturn 4.16.0) which is not enabled on install. The 4.0 notes warn that its default configuration allows anonymous access, so leaving it like that makes your server an open relay; configure authentication first.
• LiveKit includes an embedded TURN server, with authentication handled by LiveKit itself through the access token. The docs want a separate domain and certificate for TURN over TLS. If TURN listens on 443, nothing else on that IP can use 443, so either use a separate IP, put TLS termination in front, or use port 5349. Since v1.13.11 you can also point LiveKit at external TURN servers with credentials read from a file.

Practical rules from many small pilots

• Advertise the right IP. Most “I can see myself but nobody else” problems are a media server telling clients a private address. On a cloud VM with a mapped public IP, set it explicitly: JVB_ADVERTISE_IPS in Jitsi Docker, the interface filter and port range in BigBlueButton 4.0, and rtc.use_external_ip or rtc.node_ip in LiveKit.
• Open UDP in every layer: cloud security group, host firewall and any office firewall.
• Do not put media behind an HTTP load balancer. Only signalling goes through a reverse proxy. LiveKit’s docs recommend host networking for the container for this reason. For general reverse proxy choices, see reverse proxies in 2026.
• Use a real certificate. Browsers require a secure context for camera and microphone, and LiveKit’s docs say self-signed certificates will not work. Automate renewal from the first day.
• Test from bad networks, not your desk. Mobile data, CGNAT home broadband, a college network and one network that blocks all UDP; if that last one cannot join, TURN over 443 is broken.
• Plan bandwidth with symmetric numbers. Upload matters as much as download on a media server. Indian cloud regions and data centres can provide it; office broadband usually cannot, which is why the Proxmox host in Patna is a poor home for live classes.
• Keep the admin side private. Prometheus endpoints, LiveKit’s debug pages, Prosody’s admin interfaces and BigBlueButton’s API secret should not be open to the world. A mesh VPN is a simple way to reach admin ports; see mesh VPNs in 2026.

Security and accounts

Who can create a room

• Jitsi: out of the box, anyone who can reach your server can create a conference. The handbook now says the older “secure domain” setup is deprecated and recommends JWT token authentication. It has a Keycloak example: Keycloak issues tokens, Prosody checks them, a guest domain lets invited people join without an account once a signed-in host has started the room, and a lobby can be kept persistent. In Docker, ENABLE_AUTH, ENABLE_GUESTS and AUTH_TYPE (internal, jwt or ldap) control this. Do not run an open Jitsi server on the public internet; people will find it and use your bandwidth.
• BigBlueButton: only something holding the shared API secret can create meetings. In practice that is Greenlight or your LMS. Greenlight v3 has local accounts by default and supports OpenID Connect, with Keycloak as the recommended provider in its docs. Guard the API secret like a database password; anyone with it can create meetings and fetch recording lists.
• LiveKit: nobody joins a room without a token signed with your API secret, and the token decides what they may do. Our loopback drill confirmed that a validation request without a token gets an HTTP 401 with “no permissions to access the room”. The security is only as good as the backend that issues tokens: keep tokens short-lived, give publish rights only to those who need them, and never ship the API secret in a mobile app.

For one sign-in across all of these, see our post on Keycloak and its alternatives.

In-meeting controls

All three can keep people waiting until admitted. Jitsi has a lobby and room passwords. BigBlueButton has guest policies, and 4.0 adds a guest management panel with a “remember choice” option, plus “request to present” so a viewer cannot take the presenter role without approval (the default policy in 4.0 requires approval). In LiveKit, the equivalent controls are whatever your application builds using token permissions and the server API, such as removing a participant or muting a track.

What encryption really covers

All WebRTC media is encrypted on the wire with DTLS-SRTP. With an SFU, that encryption ends at the server: the server decrypts the outer layer to route packets. So the server operator can, in principle, access the media. Jitsi’s security page explains this plainly and says the media is held only in the bridge’s memory while it is routed.

End-to-end encryption adds a second layer that the server cannot remove:

• Jitsi supports E2EE using insertable streams in Chromium-based browsers (version 83 or newer) and in the Jitsi Electron app. It covers audio, video and screen sharing, but not chat or polls. Because the server cannot read encrypted media, plan on server-side features that need the media, such as recording, not working in those rooms. Jitsi’s own security page carries the line “e2ee likely doesn’t do what you think it does” and asks readers to understand the limits, which is honest advice.
• LiveKit supports E2EE for media and, in recent SDKs, data messages, with the newer encryption option replacing the older e2ee field. The docs say key management is your responsibility, and signalling is not end-to-end encrypted. Server-side recording of an encrypted room records encrypted media, which is useless unless you design for it.
• BigBlueButton does not offer end-to-end encryption in its documentation that we reviewed. It is a classroom where the server records and converts content, so the trust model assumes you trust the server.

The practical rule: self-hosting already removes a third party from the media path. If you need E2EE as well, accept that recording, transcription and some browsers will not work in those rooms, and test it before you promise it to anyone.

Recordings, personal data and DPDP

Recordings are the biggest privacy risk in any video system. They contain faces, voices, names in the participant list, chat, and sometimes student or patient details on shared screens. India’s Digital Personal Data Protection Act, 2023 and the rules under it apply to digital personal data, so treat recordings as personal data with a purpose, a retention period and a way to delete. We are not lawyers; read the official framework on the MeitY site and take advice for your case.

How each system stores recordings:

• BigBlueButton: if a meeting is created with record=true, the server captures the whole session, and the record button only marks which parts should be in the final recording. The raw files sit under /var/bigbluebutton/recording/raw/ and, per the docs, raw files for meetings with no marked segments are deleted after two weeks by default. Processed recordings are published as web playback, and Greenlight or your LMS controls who can see them. You can turn recording off per room or server-wide.
• Jitsi: Jibri writes a video file on the recorder machine. Where it goes after that, and who can access it, is up to you, usually through a finalize script that uploads it somewhere.
• LiveKit: Egress writes files and uploads them to the storage you configure. Note from the v1.15.0 notes that Egress runs its Chrome without a sandbox unless you enable it, so treat the Egress host as a place where untrusted web content runs.

One more data flow worth knowing: BigBlueButton 4.0.1 notes that browser-based live captions in Chrome send audio to Google’s speech service unless on-device processing is used, and added a speechProcessing setting (cloud, local or auto) to control this, with on-device recognition available from Chrome 139 on desktop. If your data rule says student audio stays in India, set it to local or keep live captions off. Self-hosting the server does not automatically mean every byte stays on your servers.

Performance and capacity

Vendors and projects publish numbers. They are useful as a sense of scale, not as a promise for your network.

• Jitsi documentation gives typical bitrates: about 200 kbit/s for 180p, 500 kbit/s for 360p, 2,500 kbit/s for 720p and up to 10 Mbit/s for 4K, and says a 1 Gbit/s link is enough for small organisations while serious use needs 10 Gbit/s. It says CPU is rarely the limit and that the network link is. For larger sites, you add videobridges and Jicofo spreads conferences across them; the scalable setup guide suggests 4 CPU and 8 GB for the main server and 4 to 8 CPU with 8 GB for each bridge. For recording, the requirements page says one Jibri per meeting being recorded at the same time, about 8 GB of RAM for 720p, and not on the same machine as the bridge.
• BigBlueButton’s FAQ says a server meeting the minimum specification should support about 200 simultaneous users, for example 3 sessions of 50 or 6 of 25, and that since 2.5 no single session should go above 200 users. It warns that webcams multiply load fast: 20 users sharing webcams in one room means 400 streams. Its stated bandwidth for a typical viewer is about 0.5 Mbit/s up and 1 Mbit/s down, and it tells readers to take third-party stress tests “with a grain of salt”. These are the project’s own guidance.
• LiveKit’s benchmark page reports its own runs on a Google Cloud c2-standard-16 machine (16 cores): an audio-only room with 10 publishers and 3,000 subscribers at about 80% CPU, a large meeting with 150 publishers and 150 subscribers at about 85% CPU, and a livestream with 1 video publisher and 3,000 subscribers at about 92% CPU and about 531 MBps out. These are LiveKit’s own numbers, run with its lk load-test tool; the sample command shown for the audio test on that page lists 1,000 subscribers rather than 3,000, so read the page carefully. A single room must fit on one node.

A rough estimate for Ganga Setu, our own arithmetic and not a vendor number: 8 classes at peak, about 80 students each, at about 1 Mbit/s down per viewer is roughly 640 Mbit/s of outbound media at peak, before teachers’ cameras and screen sharing. That is more than double BigBlueButton’s 250 Mbit/s minimum for a single server, which already tells Farhan that the classes will need several servers, not one big one. The only reliable number is the one you measure in your own rehearsal.

Practical habits:

• Keep student webcams off by default in large classes; it helps students on mobile data and the servers.
• Watch CPU per core, not average. BigBlueButton asks for high single-thread performance for a reason.
• Rehearse the Sunday peak with real devices, not only a load tool.
• Monitor the servers and alert on CPU, packet loss and disk; see infrastructure monitoring in 2026 and, for simple external checks of the meeting URL and TURN port, uptime monitoring in 2026.

Licences

We checked the licence files in each repository:

• Jitsi Meet, Jitsi Videobridge, Jicofo, Jibri and Jigasi: Apache License 2.0. Prosody: MIT. You can modify and run it, including commercially, with notice requirements. The name and logo are 8x8’s trademarks, so a rebranded service should use its own name.
• BigBlueButton and Greenlight: GNU LGPL v3. Running it unmodified for your own classes creates no special obligations. If you modify and distribute it, the LGPL terms apply; read them with your legal adviser.
• LiveKit server, Egress, Ingress, Agents, the JavaScript SDK and LiveKit Meet: Apache License 2.0. LiveKit Cloud and some Cloud-only features, such as the Krisp noise filters mentioned in the Meet example, are commercial services, not part of the open-source server.
• coturn, used by Jitsi and optionally by BigBlueButton for TURN, is a separate open-source project with its own licence file; check it before you bundle it in a product.

All three are open source in the usual sense, with no “open core” licence switch in these components as of this writing. The practical licence risk is less about the text and more about dependency on a single company’s roadmap: 8x8 for Jitsi, LiveKit, Inc. for LiveKit, and a smaller core team with education sponsors for BigBlueButton.

Operations and day two

• Upgrades: BigBlueButton upgrades across major versions mean a fresh Ubuntu 24.04 server and a new install, then moving recordings, and the 4.0 notes are long; read them all. Minor releases come through apt. Jitsi Debian packages upgrade through apt, and Docker deployments mean pulling new images and reading notes like the August 2026 port and registry changes. LiveKit upgrades are a binary or image swap; the server supports draining, so it stops taking new rooms on SIGTERM and exits when existing rooms finish.
• Certificates: all three fail in visible ways when a certificate expires, because browsers refuse camera access on insecure pages and TURN over TLS breaks. See TLS certificate automation in 2026.
• Recording storage: BigBlueButton recordings grow fast, which is why the project asks for 500 GB. Move published recordings to object storage on a schedule and delete by rule. For an S3-compatible store you run yourself, see MinIO and its alternatives.
• Backups: BigBlueButton keeps no meeting database, but Greenlight’s PostgreSQL does hold users, rooms and recording links. Jitsi with JWT keeps users in your identity provider. LiveKit keeps rooms in memory and, in distributed mode, in Redis. Back up the configs, the Greenlight database, the recordings and the TURN secrets, and test a restore; see backups in 2026.
• Scaling out: Jitsi adds videobridges. BigBlueButton uses Scalelite, a load balancer that sits in front of several BigBlueButton servers and presents one API to Greenlight or your LMS. LiveKit runs several nodes with Redis, chooses a node per room, and can be region-aware.
• Security updates in the chain: note how often the autumn 2026 releases mention a CA compromise and Chrome fixes. Jibri, Egress and BigBlueButton’s own server all depend on browser engines and base images. Subscribe to release notes, not only to the main project.
• People: someone must own the 7 PM evening, with a short runbook and a fallback.

Side by side

Best fit

• Jitsi Meet: internal meetings and guest calls in the browser, a Zoom or Meet replacement for staff.
• BigBlueButton: live classes and training with slides, whiteboard, polls, breakouts and recorded lessons.
• LiveKit: video, voice and AI agents built into your own web or mobile product.

What you get on day one

• Jitsi Meet: a complete meeting web app plus Android and iOS apps.
• BigBlueButton: a complete classroom client; rooms and users come from Greenlight or your LMS.
• LiveKit: a media server, SDKs and an example app; the product is yours to build.

Sign-in

• Jitsi Meet: internal, JWT (Keycloak example in the handbook) or LDAP; open by default.
• BigBlueButton: through the front end; Greenlight v3 has local accounts and OpenID Connect.
• LiveKit: access tokens issued by your backend.

Recording

• Jitsi Meet: Jibri, one recorder per recorded meeting, about 8 GB RAM each at 720p.
• BigBlueButton: built-in pipeline, marked segments, web playback.
• LiveKit: Egress to MP4, HLS or RTMP with object storage upload.

Licence

• Jitsi Meet: Apache 2.0 (Prosody MIT).
• BigBlueButton: LGPL-3.0.
• LiveKit: Apache 2.0.

A worked plan for Ganga Setu

Month 1: measure and decide rules. Export Zoom usage for the last semester: classes per hour, participants, cameras on, duration. Ask ten students from different colleges to run a WebRTC connectivity test from their usual network. Write the recording rule with the college group: which classes are recorded, who may watch, storage in India, semester plus 90 days, deletion on request, and who signs off. Connect Keycloak to Google Workspace so faculty sign in with existing accounts. Create DNS names class, bbb1 and turn.

Month 2: pilot BigBlueButton 4.0.1. One dedicated cloud VM in the Mumbai region with 8 dedicated cores and 16 GB, Ubuntu 24.04, installed with bbb-install.sh -v noble-400. Greenlight 3.9 with URL_HOST set and Keycloak through OpenID Connect. A separate small coturn VM for TURN over TLS on 443 with authentication on. Set the LiveKit interface filter. Recording only in rooms marked “record”, and a nightly job that copies published recordings to Indian object storage and a deletion job that logs what it deleted. Set speechProcessing to local or keep live captions off. Ten volunteer faculty for four weeks, with Zoom kept as fallback.

Month 3: measure and rehearse. CPU per core, packet loss, join failures by network type, complaints. Run a Sunday-morning rehearsal with real devices at the expected peak. Test restoring Greenlight from backup. Ask faculty one question: would you go back?

Month 4 onwards: scale and migrate. Add Scalelite and a second server once the first reaches about 70% CPU at peak; our estimate from the bandwidth sum is three to four servers for the full evening peak. Move classes college by college, with the LMS calling the BigBlueButton API through Scalelite so students click “Join class” in the app. Monthly: patch, check certificates, review recordings deleted. Quarterly: rehearsal at peak, restore test, read release notes.

Internal meetings stay on Google Meet while they have Workspace. If they leave Workspace, Jitsi Meet with JWT through Keycloak is the natural next step.

The viva feature goes on LiveKit, as a prototype in 2027 after classes are stable: the Android SDK in the app, tokens from Django, Egress recordings to the same Indian storage under the same deletion rule, on LiveKit nodes separate from the BigBlueButton servers.

When not to adopt each

• Do not pick Jitsi Meet for structured classes where you need polls, whiteboard with slides, breakouts with a dashboard and recorded lessons as a habit. Also not when you cannot spare a separate machine per recorded meeting.
• Do not pick BigBlueButton for quick internal meetings, for embedding video inside your own app, or when you cannot give it a dedicated server.
• Do not pick LiveKit when what you need is a meeting tool for staff next month and you have no developers to build and maintain the application around it.
• Do not self-host at all if nobody can own the evening peak, your users are mostly on networks you cannot test, you have no need for data control beyond what a commercial contract gives you, or your total volume is a few meetings a week. A paid service will be cheaper than the people time.

Why not just stay on Zoom, Meet or Teams?

For many teams, staying is the right answer. These services handle global networks, mobile apps, phone dial-in, captions and support far better than a three-person team can. The case for self-hosting is narrower: you need control over where recordings and personal data live, you need video inside your own product, your usage is large enough that per-host licences hurt, or you want to avoid dependence on one vendor for a core part of your service. For Ganga Setu, the college contract and the in-app viva are real reasons. A cheaper bill alone would not be.

A short history

• Jitsi started in 2003 as SIP Communicator, a student project by Emil Ivov at the University of Strasbourg. His company Blue Jimp was formed around it in 2009, the project was renamed Jitsi in 2011, Jitsi Videobridge arrived in 2013 and Jitsi Meet in 2014. Atlassian bought Blue Jimp in 2015, and 8x8 acquired Jitsi in 2018.
• BigBlueButton was created in 2007 with the mission, in its own words, to build the world’s most effective virtual classroom measured in learning outcomes. It moved from Flash to an HTML5 client, from Kurento to mediasoup in 2.5, and to LiveKit as the default media framework in 4.0.
• LiveKit’s main repository was created in September 2020. The company grew around the open-source server, added Egress, Ingress, SIP and the Agents framework, and runs LiveKit Cloud.

A simple decision guide

• Is video a feature inside your own product? Choose LiveKit.
• Is it teaching, with slides, polls, breakouts and recorded lessons? Choose BigBlueButton.
• Is it staff and guest meetings in the browser? Choose Jitsi Meet.
• Can nobody own a 7 PM incident, or is volume small? Stay on a hosted service.
• Several of these at once? Use more than one tool, with one sign-in and one recording rule.

Checklist before go-live

• Sessions, peak and networks measured.
• Written recording and retention rule, signed off.
• Sign-in through your identity provider; open room creation disabled.
• Valid certificates with automatic renewal.
• UDP ports open in cloud, host and office firewalls; correct public IP advertised.
• TURN over TLS 443 tested from a network that blocks UDP.
• Recordings moved to Indian storage, deletion job logged.
• Live captions data flow checked.
• Monitoring and alerts on CPU per core, packet loss, disk and certificate expiry.
• Backups of configs, Greenlight database, recordings and TURN secrets, with a tested restore.
• Peak rehearsal with real devices.
• Runbook and fallback for the evening the media server fails.

Common mistakes

• Running an open Jitsi server without authentication.
• Leaving bbb-coturn with anonymous access, an open relay.
• Testing only from the office network.
• Putting the media server behind an HTTP load balancer.
• Running BigBlueButton on a shared or burstable VM.
• Turning on recording everywhere and never deleting anything.
• Promising end-to-end encryption without testing what it breaks.
• Upgrading BigBlueButton across major versions in place without reading the notes.

Hands-on check: what we ran and what we did not

We kept the drill small and on loopback only, in a scratch folder with user-level permissions, on 2 November 2026 at about 10:28 AM IST. We did not install Jitsi or BigBlueButton: both need root, system packages, real DNS, certificates and public UDP ports, which a shared machine and a loopback drill cannot give honestly.

What we did run, with LiveKit server:

• Downloaded the official livekit_1.13.11_linux_amd64.tar.gz release (19,464,037 bytes) and checked its SHA-256 against the project’s checksums file and the GitHub release digest. They matched. livekit-server --version printed 1.13.11.
• The ports subcommand listed 7880 for HTTP, 7881 for ICE over TCP and 7882 for ICE over UDP.
• Started it in development mode with --dev --bind 127.0.0.1 --node-ip 127.0.0.1 for about 15 seconds. The log said it was starting in development mode with the built-in development key, used single-node routing, and had debug profiling pages enabled.
• GET / on port 7880 returned 200 with “OK”. The /rtc/validate endpoint without a token returned 401 with “no permissions to access the room”.
• One finding worth knowing: --bind 127.0.0.1 applied to the HTTP port only. ICE over TCP on 7881 listened on all interfaces, and the UDP port bound to the machine’s non-loopback interfaces. If you test development mode on a laptop or server, assume the media ports are reachable from your network, and do not leave development mode with its well known key running anywhere.
• We stopped the server with SIGTERM; it logged a clean shutdown, and no ports remained open.

We did not join a room with a browser, test TURN, record with Egress, or measure capacity. Those need real networks and real devices.

Unlearn and re-learn

• Unlearn: “Video conferencing is a web app.” Re-learn: it is a real-time network service with a web page in front.
• Unlearn: “One tool for all video.” Re-learn: classes, meetings and in-app calls are different problems.
• Unlearn: “E2EE is a checkbox.” Re-learn: it removes recording and server features, and key management is yours.

Sources

• Jitsi Meet releases: https://github.com/jitsi/jitsi-meet/releases
• docker-jitsi-meet releases: https://github.com/jitsi/docker-jitsi-meet/releases
• Jitsi handbook, requirements, quick start, Docker, scalable setup, TURN and authentication: https://jitsi.github.io/handbook/docs/devops-guide/
• Jitsi security: https://jitsi.org/security/
• Prosody licence: https://hg.prosody.im/trunk/file/tip/COPYING
• BigBlueButton releases: https://github.com/bigbluebutton/bigbluebutton/releases
• BigBlueButton security policy: https://github.com/bigbluebutton/bigbluebutton/blob/develop/SECURITY.md
• BigBlueButton install, FAQ, firewall and recording docs: https://docs.bigbluebutton.org/
• Greenlight releases: https://github.com/bigbluebutton/greenlight/releases
• LiveKit server releases: https://github.com/livekit/livekit/releases
• LiveKit Egress and Ingress releases: https://github.com/livekit/egress/releases and https://github.com/livekit/ingress/releases
• LiveKit self-hosting, ports, distributed setup and benchmark docs: https://docs.livekit.io/transport/self-hosting/
• LiveKit encryption docs: https://docs.livekit.io/transport/encryption/
• LiveKit Meet: https://github.com/livekit-examples/meet
• MeitY data protection framework: https://www.meity.gov.in/data-protection-framework

Related on Revisit.Tech

• Keycloak and its alternatives
• Reverse proxies in 2026
• TLS certificate automation in 2026
• Mesh VPNs in 2026
• Self-hosted team chat in 2026
• Uptime monitoring in 2026
• Infrastructure monitoring in 2026
• Backups in 2026
• MinIO and its alternatives
• Self-hosted file sync and share in 2026
• Self-hosted wikis in 2026