Open-source alternative to Microsoft Teams meetings

When an open-source alternative to Microsoft Teams meetings fits

If you are keeping chat in Microsoft Teams but want to move video meetings out, or the reverse, the self-hosted candidates for meetings are Jitsi Meet, BigBlueButton and Element Call. None of them replicates every Teams meeting feature, so the useful question is which subset of Teams meetings your organization actually depends on. Renewals, licensing changes, data residency rules and lock-in are the usual triggers, but they only tell you that a review is due. They do not tell you which product fits.

Start by listing how your people use meetings today: how many participants a typical call has, whether sessions are recorded and who needs the recordings, whether external guests or phone callers join, and how invitations reach calendars. Jitsi Meet suits ad hoc, browser-based calls and scales by adding videobridges. BigBlueButton is built around teaching and webinar-style sessions, with slides, polling, breakout rooms and recording, and it needs more server capacity per session. Element Call fits organizations already moving chat to Matrix, since it runs in the same Matrix ecosystem. Confirm each candidate's participant limits, calendar integration and dial-in options directly with its documentation and a test deployment.

Confirm Teams meeting limits, licensing and feature availability against Microsoft's current documentation before you compare, because those details change and depend on your Microsoft 365 plan. Then run a pilot with your real meeting patterns, including external guests on unmanaged devices and a recording handed to a non-member. The choice usually depends on use case rather than on a single winner, so plan for two products if your teaching, all-hands and ad hoc calls differ materially.

Teams meeting capabilities mapped to open-source options

This table maps the meeting features buyers ask about in Teams to Jitsi Meet, BigBlueButton and Element Call. Read the cells as the starting point for a proof of concept: where a cell says to confirm, the public materials do not settle the answer for your version and setup. Use the table to decide which features need testing before you commit to a platform.

Capability	Jitsi Meet	BigBlueButton	Element Call
Participant limits	Scales by adding videobridges. Load test your target meeting size.	Sized per server, with 8 CPU cores and 16 GB RAM minimum for version 4.0. Confirm limits in a proof of concept.	Depends on the media backend. Confirm capacity with Element before sizing.
Recording and transcripts	Jibri handles recording and streaming in the Docker setup. Confirm transcription separately.	Recording is built in and needs 500 GB of disk for recordings. Confirm transcript options.	Confirm recording and transcripts for your Element edition before a pilot.
Dial-in by phone	Jigasi SIP gateway is available in the Docker setup. Confirm carrier and number needs.	Confirm telephony options and carrier requirements in a proof of concept.	Confirm PSTN dial-in with Element and your carrier.
Calendar invites	Invites are room links. Confirm calendar add-ins with your team.	Greenlight creates rooms with links. Confirm calendar integration in a proof of concept.	Room links from Matrix clients. Confirm calendar invite support.
Breakout rooms	Confirm breakout room support for your version before a pilot.	Supported as a core feature. Test size and moderator controls.	Confirm breakout room support in a proof of concept.
Screen sharing	Supported in the web app. Confirm behavior on mobile clients.	Supported as a core feature. Test with your largest presenter setup.	Confirm screen sharing across browsers and mobile clients.
Lobby and moderation	JWT tokens can assign moderators. Confirm lobby controls for your version.	Moderator roles are built in. Confirm lobby options for version 4.0.	Confirm waiting room and moderator controls in a proof of concept.
Single sign-on	Internal accounts, JWT, LDAP, Matrix or hybrid modes, set in the .env file.	Greenlight v3 supports OpenID Connect. Keycloak can add SAML and other providers.	Synapse supports OIDC, SAML2 and CAS. Confirm the sign-in flow.
Guest access	Use a separate anonymous domain for guests. Confirm the setup for your deployment.	Confirm guest join rules in Greenlight and the API.	Confirm whether guests can join without an account.

Jitsi Meet, BigBlueButton and Element Call compared

Each option below runs video meetings on servers you control, but they differ in architecture, licensing and the kind of meeting they serve best. Compare them on participant scale, recording, dial-in and the infrastructure each one needs before you choose a replacement for Teams meetings.

Jitsi Meet

Jitsi Meet is an Apache 2.0 licensed conferencing app built from a web server, the Prosody XMPP server, Jicofo (the conference focus) and one or more Jitsi Videobridge media routers. It fits organizations that want a browser-first meeting service with horizontal scaling by adding videobridges. The Docker setup runs web, prosody, jicofo, jvb, jigasi and jibri as separate containers, and the .env file controls authentication through internal XMPP accounts, JWT tokens, LDAP or Matrix verification. Check whether you need JWT tokens for calendar-linked rooms, and confirm how your team will handle recording through jibri before you commit.

BigBlueButton

BigBlueButton is an LGPL-3.0 virtual classroom with polls, a multi-user whiteboard, shared notes, breakout rooms and recording built in. It fits training, webinars and education, where presenters need slides with annotations and facilitators need to split groups. The trade-off is weight: a 4.0 server needs at least 16 GB of RAM with swap, 8 CPU cores and 500 GB of disk if you record. Installs are clean-server only for 4.0, so plan a fresh host rather than an in-place upgrade from an older branch.

Element Call

Element Call is the video layer of Element Server Suite Community, which includes Synapse and Element Call under AGPL. It only works inside a Matrix deployment, so calls, rooms and identities sit in the same homeserver as your chat. This suits organizations replacing chat and meetings together, but it does not stand alone as a Jitsi-style service. Confirm your media backend, your Synapse database and your identity provider setup with Element before you plan a rollout, and check the AGPL obligations that apply to your use.

What each meeting stack needs in servers and bandwidth

The main sizing difference between these stacks is how they scale. BigBlueButton 4.0 is sized as one large server: the install documentation lists at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB if you turn recording off) and 250 Mbit/s of symmetrical bandwidth. Plan the disk and bandwidth around recording policy and how many concurrent sessions a single host must carry. Before you commit, ask your integrator or the project's support channel how the sizing changes for your session mix, and check that your firewall allows TCP 80 and 443 and UDP 16384 to 32768.

Jitsi splits the load across roles. The scalable setup guide suggests a 4 CPU, 8 GB machine for the central server (Prosody, Jicofo and the web tier) and 4 or 8 CPU with 8 GB RAM for each Jitsi Videobridge. Media traffic runs through the bridges, so capacity grows by adding videobridges rather than by enlarging one host, and the default install is already configured for horizontal scaling. Your UDP port 10000 must reach every bridge, and bandwidth is driven by the number of participants and video streams each bridge forwards, not by the number of meetings alone.

Neither guide gives a participant count for your hardware, so treat the suggested machine sizes as starting points. Run a load test with your own clients, your own network path and a realistic mix of camera-on and screen-share meetings, and record CPU, memory and bandwidth on each host. Ask your Element Call, Jitsi or BigBlueButton provider to show test results for the same profile before you buy or provision hardware. Repeat the test after each upgrade, because the sizing that held for one release may not hold for the next.

Keeping chat in Teams while moving meetings

Many organizations will keep Teams chat for a while and move meetings first. The cards below cover the links, invites, sign-in and recording decisions that connect a Teams chat tenant to an open-source meeting service, and the points to confirm in your own calendar and identity systems before users notice a difference.

Linking chat to an external meeting URL

Teams chat can carry a plain link to a Jitsi Meet, BigBlueButton or Element Call room, so users keep their existing conversations while joining a different meeting service. Decide one canonical URL pattern per team or per department, and confirm that your Teams tenant policies allow those external links in messages and that guests can open them without a Microsoft account. Test the join flow from a managed device and from a personal browser, since Jitsi and BigBlueButton both depend on a valid HTTPS certificate for audio and video.

Calendar invites with the open-source link

Invitations are the step most likely to break coexistence. A Jitsi or BigBlueButton room link must appear in the invite body, and the link must be generated by the system that creates the meeting, whether that is Outlook, a scheduling add-in or a separate booking tool. Confirm how invites are generated in your own calendar system, who owns the room naming scheme, and how cancelled or rescheduled meetings remove stale room links.

Single sign-on with JWT or OIDC

Users should not need a second password for the open-source meeting service. Jitsi supports JWT token authentication, which a trusted application uses to sign room access, and the Jitsi Docker setup can also be configured for LDAP and Matrix verification. BigBlueButton's Greenlight v3 accepts OpenID Connect, and the docs suggest Keycloak for Microsoft and SAML logins. Confirm which identity provider you will federate from, how group membership maps to moderator rights, and how a departing employee's access is revoked.

Guest access and moderator roles

Coexistence usually means external participants who have no Teams license or Entra ID account. Jitsi's current guidance favors JWT authentication with a separate anonymous domain for guests, while the older secure domain method is deprecated for new installations. Define who may start a meeting, who is a moderator, and how lobby or waiting room behavior works for guests before rollout, and test these rules against each product version you deploy.

Retaining Teams recordings and transcripts

Recordings and transcripts made in Teams do not move automatically to a new meeting service. The Microsoft Graph Teams Export APIs return meeting recording and transcript links, but only for users with an active Teams license, and they require admin-approved application permissions. Decide which recordings must be kept for records or legal hold, export them while licenses are still active, and set a retirement date for links that users still rely on.

Recording storage for new meetings

Recording in the open-source stack is a separate design decision. BigBlueButton 4.0 expects 500 GB of disk for recordings on a server that records, against 50 GB without recording, so storage planning must start before the first recorded meeting. Jitsi recording relies on the Jibri component, which is a separate deployment. Confirm where recordings are stored, who can download them, how long they are kept, and how retention lines up with the policies you already apply to Teams recordings.

Which meeting tool fits which situation

Large one-to-many events put the most load on the media layer, so the question is how many participants each server must carry and whether a single media router is enough. Jitsi Meet fits interactive meetings that scale by adding videobridges, and the Jitsi scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge.

Jitsi Meet with extra videobridges: The default install is already set up for horizontal scaling, so capacity grows by adding bridge nodes rather than rebuilding the core.
Central server profile: Plan the Prosody, Jicofo and web components on a separate 4 CPU, 8 GB machine as a starting point.
Network ports: Confirm 443/TCP, 10000/UDP and the optional 5349/TCP fallback are open end to end, including through corporate firewalls.
Authentication: Use JWT tokens with a separate guest domain, since the handbook marks the older secure domain method as deprecated for new installs.
Load testing: Ask the vendor or integrator to run a rehearsal at your expected peak participant count before the event.

Verify the largest session you expect, the number of concurrent sessions, and whether your team has someone who can add a bridge during a live event.

Calendar invites, dial-in and recording: what to confirm first

Calendar invites, dial-in numbers and recording are the three meeting features most often assumed to work out of the box, and each one usually needs an extra component or a decision. Teams users expect a meeting link, a phone number and a recording button in every invite. In the open-source stacks, these come from separate pieces. In Jitsi Meet, telephone access is provided by Jigasi, the SIP gateway that bridges phone calls into a conference, and it is a separate container in the official Docker setup, so it must be deployed, registered with your SIP trunk provider and tested before you promise dial-in to anyone. Recording is provided by Jibri, which also runs as its own container and needs its own capacity, since it captures a browser session in full. Confirm both with the Jitsi handbook before scoping the work.

BigBlueButton bundles recording into the server, but the storage cost is significant. The BigBlueButton 4.0 install documentation calls for 500 GB of disk for recordings, or 50 GB if you turn recording off, so the storage plan, retention period and backup approach must be settled at sizing time, not after the first all-hands. Calendar invitations are a different matter: BigBlueButton creates rooms through its API, and that API signs every call with a checksum computed from a server secret, so an invite generator must run server-side and never expose that secret in a web page. Scheduling tools and Outlook or Google Calendar plugins differ in how they create meetings, so test invite generation with your actual calendar system, including recurring meetings and external guests.

Before committing, run a short pilot that covers three checks: send an invite from your real calendar to an external guest and a dial-in user, record a meeting and confirm where the file lands and who can download it, and place a call from your actual telephony provider into a live room. Ask the vendor or integrator to document each result, because your telephony and calendar providers, not the open-source project, decide whether these paths work in your environment. For regulated organizations, the recordings and call metadata also become records that need retention and access rules, so agree those with your compliance lead during the pilot.

Migration path for moving meetings off Teams

This sequence moves scheduled meetings, dial-in numbers and recordings from Microsoft Teams to a self-hosted video platform in a controlled order, so each step ends with a check that the previous one held. The result is a tested, authenticated service with a cutover date agreed by the people who schedule meetings.

Inventory meetings, rooms and dependencies
The meeting owner or Teams administrator lists the recurring meetings, the channel meeting rooms, the users who depend on dial-in numbers, and the recordings and transcripts that must be kept. Record which calendars and Outlook add-ins create the Teams links, because those are the invites that must change. Confirm which Teams licenses and admin permissions the exports will need. The step is done when every meeting type has an owner and a documented requirement for participant count, recording, dial-in and calendar invites.
Select the tool and size the servers
Choose among Jitsi Meet, BigBlueButton and Element Call based on the inventory: web meetings with many guests, classroom-style sessions with recording, or meetings tied to a Matrix chat server. Read the vendor's hardware and bandwidth requirements for the expected concurrent meetings and recording load, and ask DeployOpen or your platform team to confirm the sizing in your own cloud or data center. The step is done when a written sizing sheet exists and the tool choice has been approved by the owner of the meeting inventory.
Deploy a proof of concept with a valid certificate
The platform team installs the chosen tool on a test host with a real domain name and a publicly trusted certificate, and opens the ports its quick start requires. Self-signed certificates cause audio and video failures, especially on mobile clients, so do not use them even for testing. The step is done when two internal users join a meeting from a laptop and a phone, with audio, video and screen sharing working in both directions.
Configure authentication and access rules
The identity team connects the meeting service to your directory or single sign-on provider, using the authentication method the tool supports, and decides which rooms allow guests. Token-based authentication is the current recommendation for Jitsi, and external login through OpenID Connect or a broker is available for BigBlueButton Greenlight. Confirm that shared secrets and API credentials are kept off web pages. The step is done when staff sign in with corporate accounts, guests join only the rooms meant for them, and an unauthenticated user cannot create a room.
Test invites, dial-in and recordings
The team creates test meetings from the calendar client the business uses, sends invites to external and internal addresses, and joins from browsers, desktop apps and a phone dial-in if one is in scope. Run a recording and confirm where the file is stored and who can retrieve it. Export a sample of Teams recordings and transcripts through the Microsoft Graph Teams Export APIs to confirm the archive path works, noting that the export needs admin-approved application permissions and active Teams licenses on the users concerned. The step is done when every test join, invite and recording check passes and the results are written down.
Pilot with a small group
Run the new service with one or two teams that hold regular meetings, and ask them to keep their Teams links active while they try the new room links in parallel. Collect issues on audio quality, firewall traversal, mobile behavior and recording storage, and fix them in the configuration before wider use. The step is done when the pilot group has held its normal meeting cadence on the new platform and the open issues list is short and assigned.
Cut over invites and retire Teams links
Update the calendar templates, meeting booking pages and any internal guidance so new invites carry the self-hosted room links, and announce a date after which Teams meeting links are no longer issued. Keep the Teams recording archive accessible for the retention period your policy requires. The step is done when new invitations use only the self-hosted links, the old Teams meeting links have been disabled on the schedule agreed in writing, and the service has a named owner for upgrades and backups.

What buyers ask before replacing Teams meetings

How much does a self-hosted Teams meetings replacement cost?

The cost is driven by four components: the servers that run the meeting stack, the bandwidth that carries participant media, the storage that holds recordings, and the people who install, operate and patch the platform. Open-source licenses for Jitsi Meet (Apache 2.0) and BigBlueButton (LGPL-3.0) remove per-user fees, so the recurring spend shifts to infrastructure, staff time and any support retainer. Server and bandwidth needs grow with concurrent participants and recording volume. The BigBlueButton install docs list minimum 4.0 server specifications of 16 GB of RAM, 8 CPU cores, 500 GB of disk with recording (50 GB without) and 250 Mbit/s symmetrical bandwidth. Ask for a fixed-scope written quote from DeployOpen based on your peak participant count, meeting length and recording policy.

How long does it take to deploy a self-hosted meeting platform?

Timing depends on the platform, the hosting model, the identity integration and how many environments you need. A single Jitsi Meet server on a supported Debian or Ubuntu host follows a short quick start, but production work adds TLS certificates, authentication, firewall rules and load testing. BigBlueButton 4.0 must be installed on a clean Ubuntu 24.04 server because direct upgrades from 2.6, 2.7 or 3.0 are not supported, which affects migration planning. The client typically needs to provide the server or cloud account, a DNS name with a valid certificate, firewall changes, identity provider access and a test group of users. DeployOpen agrees the timeline in writing as part of the fixed scope.

Can our own IT team run the meeting platform after go-live?

Yes, if the team has Linux server administration, network and certificate skills and a plan for upgrades, but the workload is ongoing rather than one-time. Jitsi Meet runs as several components (web server, Prosody, Jicofo and Jitsi Videobridge), and scaling means adding videobridges, so someone must monitor and patch each piece. BigBlueButton has more moving parts, including LibreOffice conversion in Docker, a TURN server for restrictive firewalls and a wide UDP media range. Many organizations split the work: internal staff handle user administration and daily checks, while an implementation partner handles hardening, backups, upgrades and testing under a retainer. DeployOpen offers ongoing support, upgrades and continuous testing as retainers.

Do dial-in and calendar invites work with Jitsi and BigBlueButton?

Calendar invites work with both platforms because a meeting is a link that can be placed in any calendar. Dial-in is different: Jitsi needs the optional jigasi SIP gateway component to bridge telephone callers, and it must be deployed and connected to your telephony provider. BigBlueButton's dial-in capability depends on its telephony setup and your carrier, so confirm the configuration with the project documentation and your provider before you promise phone access. Confirm the exact dial-in and invite behavior you need in a proof of concept. Also check how your identity provider handles sign-in, because Jitsi supports JWT tokens and LDAP, and Greenlight v3 supports OpenID Connect for account login.

What happens to our existing Teams recordings and transcripts?

Existing Teams recordings do not move automatically to a self-hosted platform. You can retrieve meeting recording and transcript links with the Microsoft Graph Teams Export APIs, but those calls require admin-approved application permissions and an active Teams license on the users being exported. Once downloaded, recordings should be stored in your own object storage or file system, with retention rules that match your policy. Plan storage for both legacy and new recordings, because recording volume is often the largest storage cost. Check retention and deletion windows for Teams content before you start the export.

Does a self-hosted meeting platform need HTTPS and a valid certificate?

Yes. The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video, and warns that self-signed certificates cause problems, especially on mobile clients. BigBlueButton also requires a valid hostname for SSL. Plan the DNS name and certificate lifecycle before installation, including renewal automation, because an expired certificate stops meetings. Also confirm which ports your network allows: Jitsi needs 80/TCP, 443/TCP and 10000/UDP, while BigBlueButton needs 80 and 443 TCP and UDP 16384 to 32768.

What compliance evidence does a self-hosted meeting platform produce?

Self-hosting gives you control over where meeting media, logs and recordings live, but it does not make the platform compliant on its own. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any audit report or certification. Ask what evidence you need for your framework, such as access logs, authentication settings, patch records and backup tests, and agree it in the written scope. Also confirm who can access recordings and how long they are kept.

How DeployOpen scopes and delivers meeting replacement

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted meeting platforms inside your own infrastructure, whether that is a cloud account, a data center or an air-gapped network. We start from the meeting needs you actually have, then agree the scope in writing before any build work begins.

How we scope

We confirm expected concurrent participants, meeting length and whether recording is required before choosing between Jitsi Meet, BigBlueButton and Element Call.
We map identity needs, such as JWT tokens, OpenID Connect or LDAP, and calendar invite behavior against your current Teams setup.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We size servers from the vendor requirements for each platform, including media server counts for Jitsi and CPU, RAM and disk for BigBlueButton.
We configure valid HTTPS certificates, the required TCP and UDP ports, and a TURN server path for users behind restrictive firewalls.
We test audio, video, screen sharing and dial-in paths across your network and client devices before anything goes live.

How we hand over

We document the deployment, configuration keys, upgrade steps and the recording storage and retention settings your staff will manage.
We walk your administrators through backup procedures, upgrade planning and the checks needed after each vendor release.
We prepare the security configuration and evidence your compliance assessors may ask for, while independent auditors issue any attestations.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover patching of the meeting stack, capacity reviews as participant numbers grow and periodic security testing.
Before you sign, ask us to confirm the support hours, response expectations and upgrade cadence in the written scope.