Jitsi vs Element Call: which to choose

Jitsi vs Element Call: when each fits a Matrix rollout

If you are rolling out Matrix or already run a homeserver and need video, Element Call is the choice when calls must stay inside Matrix with federation and end-to-end encryption. Jitsi Meet is the choice when a general meeting app with Matrix sign-in is enough, because it adds a standalone video product on top of your existing identity without making calls part of the Matrix protocol. The decision turns on four questions: how strict your encryption requirement is, whether Matrix is the primary chat for your users or one of several tools, how many federated homeservers will take part in calls, and who will operate the media stack after go-live.

Element Call is built on MatrixRTC (MSC4143) with LiveKit as its backend for large meetings, and its calls are federated across Matrix homeservers and end-to-end encrypted. It can run standalone or embedded in Matrix clients as a widget. Choose it if participants are spread across several homeservers and you want call membership and encryption to follow the Matrix model. Your team will then own the LiveKit backend, the homeserver and the client versions that must agree with each other. Confirm current client support and the encryption behavior for your specific clients with Element and in a test room before you commit, since the Element Call release line is still moving (v0.28.0 was published on October 13, 2026).

Jitsi Meet is the simpler operational choice when you want a finished meeting application. Its Docker setup runs separate web, prosody, jicofo, jvb, jigasi and jibri containers, and the Docker guide lists LDAP, JWT and Matrix user verification as authentication options, configured through the .env file. Matrix verification lets people who already have Matrix accounts join Jitsi rooms, but the calls remain Jitsi calls. Before choosing it, confirm with your security team that media is not end-to-end encrypted across the Matrix model, and plan for the HTTPS certificate and port requirements the Jitsi handbook describes.

Which scenario favors Jitsi and which favors Element Call

This table maps common Matrix rollout situations to the platform that fits each one better, and names the condition that tips the decision. Read each row against your own user base and federation requirements, since the answer often changes with whether calls must cross organizational boundaries. Jitsi Meet can verify Matrix users without making its calls federated, so a team with Matrix sign-in does not automatically need Element Call.

Scenario	Better fit	Condition that makes it so
An existing Matrix homeserver with users in one organization	Jitsi Meet with Matrix user verification	Choose this when staff already sign in through Matrix and you want a standalone meeting app with a long-established web experience, with Jitsi's Matrix verification handling access without federated calls.
A standalone meeting tool for staff with Matrix sign-in	Jitsi Meet with Matrix user verification	Choose this when the goal is a meeting tool, not a full Matrix-native calling layer. Confirm in the Docker guide's .env settings that the hybrid Matrix plus JWT mode fits your access model.
A federated multi-organization network where calls must cross homeservers	Element Call	Choose this when participants on different Matrix homeservers must join the same encrypted call. Element Call calls are federated and end-to-end encrypted, so confirm that every participating homeserver and client supports MatrixRTC before committing.
Calls that must be end-to-end encrypted within a Matrix deployment	Element Call	Choose this when end-to-end encryption of calls is a stated requirement. Verify with the vendor how encryption behaves in your client mix, since Jitsi's security model is documented separately and should be reviewed on its own terms.
A deployment that must avoid running Matrix at all	Jitsi Meet	Choose this when no Matrix homeserver is in scope. Jitsi Meet runs on its own with Prosody, Jicofo and Videobridge, and its authentication options (internal accounts, JWT or LDAP) do not require a Matrix service.
A team that wants calls embedded in a Matrix client	Element Call	Choose this when calls should appear as a widget inside the Matrix client users already run. Element Call can run standalone or embedded, but confirm your client's widget support and plan for a LiveKit backend for larger meetings.

How Jitsi Meet and Element Call are built and what that means for operations

Jitsi Meet is one application stack you run as a unit, while Element Call sits on top of a Matrix homeserver and a LiveKit media backend. The cards below cover each moving part, what it means for the people who patch and monitor it, and what to confirm for the exact versions you plan to deploy.

Jitsi web, Prosody, Jicofo and Videobridge

A Jitsi Meet deployment combines a web server (nginx or Apache) serving the web app, the Prosody XMPP server for signalling, Jicofo as the conference focus, and one or more Jitsi Videobridge media routers. Your team patches four cooperating services, and the Debian and Ubuntu quick start requires OpenJDK 17. Ask the vendor which Jitsi build your chosen package or Docker tag pins for each component, and test upgrades on a staging host first.

Videobridges scale by adding nodes

The Jitsi scalable setup guide says videobridges scale horizontally by adding more, and that the default install is already configured for horizontal scaling. Capacity planning then becomes a question of how many bridges you run and how load is spread across them. Confirm with your Jitsi version how the central server and each bridge are sized, and monitor bridge load so you add capacity before calls degrade.

Element Call depends on a Matrix homeserver

Element Call is an AGPL-3.0 Matrix video app built on MatrixRTC, and its calls are federated across Matrix homeservers and end-to-end encrypted. You cannot run it in isolation: the homeserver handles accounts, rooms and call signalling, so a Matrix rollout must be operated before video works. Your team owns the homeserver upgrade path as well as the call app. Confirm which homeserver versions and Element Call release you are validating together.

LiveKit as the media backend

Element Call uses LiveKit as its backend for large meetings, so media traffic goes through a separate service that has its own configuration, TURN and networking needs. This means a second product to patch and monitor alongside the homeserver. Ask the vendor how the LiveKit component is versioned with Element Call and what network paths must be open for your user base, including users behind restrictive firewalls.

Synapse needs PostgreSQL, Redis and workers to scale

Synapse recommends PostgreSQL for production, and versions 1.143.0 and later require PostgreSQL 14 or newer. Larger deployments scale with worker processes, where the main process and all workers connect to Redis for replication. Operators must run and back up PostgreSQL and Redis, and the upgrade notes warn that rolling back can be difficult because of schema changes. Plan a tested restore path before the first upgrade.

Ports and HTTPS certificates

Jitsi's quick start needs ports 80/TCP, 443/TCP and 10000/UDP open, with 5349/TCP for TCP fallback and 3478/UDP for STUN optional. The Jitsi handbook says a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially on mobile. Synapse federates on port 8448 by default unless delegation is set. Check firewall rules and certificate renewal for every host on both stacks before go-live.

Encryption, scale, identity and client support compared

This table compares licensing, federation, encryption, media scaling, identity, server components, client support and TLS requirements for Jitsi Meet and Element Call. Read each row as a question to confirm for your rollout, since the supplied material documents some capabilities on one side only.

Capability	Jitsi Meet	Element Call
License	Apache-2.0 for Jitsi Meet, per its GitHub repository. Jitsi is a trademark of 8x8, Inc.	AGPL-3.0, developed by Element. Review the AGPL obligations with counsel if you modify and host it.
Federation	Not a federated system. Each deployment is its own XMPP domain, so users on separate servers do not join each other's rooms.	Calls are federated across Matrix homeservers, so users on different servers in the same Matrix network can join the same call.
End-to-end encryption	Not documented in the supplied material. Confirm with the Jitsi project and test E2EE behavior in your own client mix before relying on it.	Calls are documented as end-to-end encrypted. Verify key handling and device verification behavior in a pilot.
Media scaling model	Horizontal scaling by adding Jitsi Videobridge instances. The default install is already configured for horizontal scaling, per the scalable setup guide.	Built on MatrixRTC with LiveKit as the backend for large meetings. Confirm the LiveKit sizing and deployment model with Element documentation for your expected call size.
Identity integration	Internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, configured in the .env file.	Identity comes from the Matrix homeserver. Synapse supports OpenID Connect, SAML2 and CAS, so confirm the SSO path your homeserver uses.
Server components	Web server (nginx or Apache), Prosody, Jicofo and one or more videobridges, with optional Jibri and Jigasi.	Matrix homeserver, Element Call and LiveKit. Synapse at scale also uses workers and Redis, which adds operating work.
Client support	Browser-based meetings through the Jitsi web app. Confirm mobile and desktop app coverage against your device fleet.	Native Matrix video app that runs standalone or embedded in Matrix clients as a widget. Confirm which clients support the current MatrixRTC flow.
TLS requirements	HTTPS with a proper domain certificate is necessary for working audio and video. The handbook warns that self-signed certificates cause problems, especially on mobile.	Served through the Matrix deployment's own HTTPS endpoints. Confirm certificate and federation port requirements, including the default federation port 8448, with your homeserver setup.

How Jitsi Matrix user verification ties to your homeserver

The decision that shapes a Jitsi rollout for Matrix users is which authentication mode the Jitsi Docker setup runs, because that choice determines whether a Matrix login is enough to join or create a room. The Jitsi Docker guide lists internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, all set through the .env file. Matrix user verification checks the caller against your homeserver, so the homeserver must be reachable from the Jitsi stack and its user directory must match who you intend to admit. The hybrid mode adds JWT tokens for cases where you need to control room names, moderator rights or guest entry from your own application. The older secure domain method, which relies on usernames and passwords for room creation, is marked deprecated for new installations, so it should not be the starting point.

Single sign-on sits upstream of either design. Synapse supports OpenID Connect providers through oidc_providers, SAML2 through saml2_config, and CAS, so people normally sign in once at the identity provider and then hold a Matrix session that the verification path can trust. Confirm with the vendor and in your own test environment which Matrix account types, including accounts provisioned through SSO and any accounts from other homeservers, the Matrix user verification path supports, and which homeserver versions it has been tested against. Also confirm whether the identity flow you choose for Synapse, such as Matrix Authentication Service with upstream providers, changes what the Jitsi side can verify.

Three choices remain for your team. Decide whether guests may join without a Matrix account, which in the hybrid mode usually means a separate anonymous domain with its own rules. Decide who may create rooms, since room creation is where moderator control and recording permissions start. Finally, decide how JWT claims map to Matrix identities if you run the hybrid mode, and write those mappings down before go-live so that support staff can trace a rejected join to a specific rule. Test each path with a standard user, a guest and an account from a second homeserver if you federate.

Licenses and paid options for each stack

Jitsi Meet is licensed under Apache 2.0, so you can run, modify and redistribute it inside your own infrastructure without a per-seat license from the project. The name is a separate matter. The Jitsi project states that Jitsi is a trademark of 8x8, Inc., so any customized or branded deployment needs a check against that position. The hosted route is 8x8's JaaS (Jitsi as a Service), which the project describes as the team that builds Jitsi running it for you. The free public instance at meet.jit.si is a different thing from JaaS and is not a commitment your organization can rely on.

Apache-2.0 code: Self-hosting carries no license fee from the project, so your costs are infrastructure, certificates and staff time.
Trademark held by 8x8: The Jitsi name belongs to 8x8, Inc., so confirm with counsel what you may call an internal or customized deployment.
JaaS as a commercial service: 8x8 runs Jitsi for customers under its own terms, which are separate from the open-source project.
meet.jit.si is not JaaS: The free public instance carries no contract, support or data-location commitment for your organization.
Stable release tracking: The latest stable tag listed is stable/jitsi-meet_11248, published September 14, 2026.

Check the current JaaS terms and trademark usage guidance directly with 8x8 before you settle on a naming or hosting model.

What drives the running cost of a Matrix video stack

Running a Jitsi Meet deployment and an Element Call stack costs money in different places, so compare them by component rather than by a single line item. On the Jitsi side, the cost centers are the central server and the Jitsi Videobridge machines. The Jitsi scalable setup guide suggests a 4 CPU, 8 GB machine for the central server, which runs Prosody and Jicofo, and 4 or 8 CPU with 8 GB RAM for each videobridge. Because the default install is already configured for horizontal scaling, most of the recurring growth cost is adding bridge machines as concurrent participants rise. On the Element Call side, the cost centers are the Matrix homeserver, usually Synapse, with its PostgreSQL database, plus Redis and any worker processes, and the LiveKit capacity that carries call media. The Synapse upgrade notes say PostgreSQL is recommended for production, so budget for a database that is backed up and tested, not only a homeserver process.

Separate one-time setup from recurring operation. One-time work includes choosing domains, issuing TLS certificates, configuring identity, sizing and load testing, and, for Element Call, deciding how federation will be exposed. Recurring work includes the servers and database that stay powered on, certificate renewal, monitoring, and upgrades. Matrix upgrades are where staff time tends to concentrate: the Synapse upgrade notes warn that rolling back can be difficult because of database schema changes between releases, so each upgrade needs a rehearsal and a backup plan. The Jitsi handbook is also clear that HTTPS with a proper domain certificate is necessary for working audio and video, so certificate management is a recurring task with a direct effect on call quality.

Federation and the number of Matrix servers push cost up in ways that are easy to miss. Each additional homeserver you operate adds its own database, workers, upgrades and certificates, and federated calls and events add traffic on the federation listener, which Synapse serves on port 8448 by default unless delegation is configured. Ask any vendor or partner for a written quote based on your own scope: the number of concurrent participants, the number of homeservers and whether they federate, the identity provider and its licensing, redundancy targets, and who carries paid support or upgrade retainers. Quotes from DeployOpen follow the agreed written scope, and any paid Element or LiveKit subscription terms should be confirmed directly with those vendors.

Moving rooms, users and calls between Jitsi and Element Call

This sequence shows how a Matrix team can run Jitsi and Element Call side by side, switch widgets and call links over in stages, and retire the old video path without losing accounts, room membership or the ability to roll back.

Back up the homeserver before any change
Before touching video configuration, the Matrix administrator takes a full backup of the Synapse PostgreSQL database, the media store and the homeserver configuration files. The Synapse upgrade notes warn that rolling back can be difficult because of database schema changes between releases, so a restorable backup is the only dependable rollback path. Confirm the backup by restoring it to a separate test host and starting Synapse there. Record the Synapse version in use, because the upgrade notes tie some releases to minimum PostgreSQL and Python versions that you must check before any upgrade.
Inventory accounts, rooms and existing call links
The platform team lists the homeserver accounts, the rooms that contain Jitsi widgets or links, and the authentication method each Jitsi deployment uses. Accounts and room membership already live on the homeserver, so they transfer without being rebuilt. Widget definitions, Jitsi room URLs and any JWT or LDAP settings in the Jitsi .env file do not transfer and must be rebuilt for Element Call. The inventory is complete when every room with a video widget appears on one list with its owner and its current link.
Stand up Element Call alongside Jitsi
Your administrator deploys Element Call and its LiveKit backend next to the existing Jitsi stack, so both run during a pilot. Element Call is AGPL-3.0 and is configured against the homeserver, and its calls are end-to-end encrypted and federated, so the pilot should use a homeserver that your federation policy already allows. Keep the Jitsi servers running unchanged. The step is done when a test account can start and join an Element Call session from two clients, and the call audio and video work over your network path.
Run a pilot room set with a named group
Pick a small set of rooms and a named group of users, and give them an Element Call widget next to the existing Jitsi widget. Ask pilot users to report join failures, audio problems and any client that cannot open the call. Keep Jitsi links live in the same rooms so people can fall back. The pilot closes when the group has completed a set number of real meetings that you agreed in advance and the open issues are logged with an owner. Confirm the client support list for each platform your users run before widening the pilot.
Repoint widgets in Matrix clients
After the pilot, the room administrators replace the Jitsi widget with the Element Call widget in each room that is in scope. Room membership and history stay intact because they sit on the homeserver. Users will see a different call button and a different join screen, so send them a short notice in each room explaining the change and the new join path. The step is done when the widget list for each room shows only the Element Call entry and a test join succeeds from a non-admin account.
Retire old Jitsi links and monitor the new path
Remove or disable the Jitsi links in migrated rooms, and keep the Jitsi servers online for a period your team sets so late links still resolve. Rebuild monitoring for the new path, covering LiveKit, the Element Call deployment and the homeserver, because the Jitsi dashboards will not reflect Element Call traffic. Users must re-learn the join flow, how the encrypted call is verified and where to find the call link after a restart. The step closes when no room contains a Jitsi link, the new monitoring reports healthy calls, and the decommission date is written down with the backup retained.

Questions buyers ask before choosing Jitsi or Element Call

Can we use Jitsi without running a Matrix server?

Yes. Jitsi Meet runs on its own stack of Prosody, Jicofo and Jitsi Videobridge, and it does not need Matrix to start a meeting. The Matrix link is optional: the Jitsi Docker guide lists Matrix user verification and a hybrid Matrix plus JWT mode as authentication options, configured through the .env file. Choosing that route means you still run a Matrix homeserver for the people who log in with Matrix accounts, so the Matrix work does not disappear, it just becomes an identity question. Confirm with your team which login source your users will actually use before you commit to the hybrid mode.

Are Element Call calls end-to-end encrypted?

Element Call's README states that its calls are end-to-end encrypted and federated across Matrix homeservers. Encryption protects the media content from the infrastructure in the path, but it does not remove the need to operate that infrastructure securely. Your homeserver, the LiveKit backend and the clients still have to be configured and kept current, and you should verify the exact encryption behavior, key handling and any limits for your client versions in the Element Call repository before you write it into a policy. Jitsi's security and privacy page is the place to check how Jitsi handles its own media path for comparison.

What skills does a Synapse and LiveKit deployment need?

A Matrix rollout built on Synapse needs people comfortable with PostgreSQL administration, Python runtime versions and Redis, because the Synapse documentation recommends PostgreSQL for production and workers relay replication through Redis. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. The upgrade notes warn that rolling back can be difficult because of schema changes, so your staff also need a tested upgrade routine. LiveKit adds WebRTC networking knowledge for TURN, media ports and scaling. Confirm these requirements against the current version you plan to deploy.

How long does a pilot take, and can our team run it alone?

The duration depends on your identity setup, your network and how many people must move, and no supplied fact gives a timeline, so ask for a written scope with milestones before you plan dates. A Jitsi pilot is smaller because the Debian or Ubuntu quick start covers the core services on Debian 12 or Ubuntu 24.04 with OpenJDK 17, though HTTPS with a proper domain certificate is required for working audio and video. A Matrix pilot takes longer because it includes homeserver setup, federation decisions and client testing. Whether your team can run it alone depends on the Linux, database and networking skills you already have.

What would a consultant be paid for in this project?

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. In a Jitsi and Element Call project that could mean the authentication design for Jitsi, the Synapse and LiveKit deployment, identity integration and the runbooks your team inherits. Ongoing upgrades and support are available as retainers. DeployOpen does not publish a price list, so ask for a quote built from the written scope, and make sure it names which parts are one-time and which recur.

Which identity options does Synapse support for single sign-on?

Synapse supports single sign-on through OpenID Connect providers configured with oidc_providers, SAML2 configured with saml2_config using pysaml2, and CAS, according to its configuration manual. Choose the option that matches your existing directory, then confirm the mapping of user attributes and the behavior of account creation in your environment. The Matrix Authentication Service documentation on upstream identity providers is the natural next read if you plan to separate authentication from the homeserver. Test each login path with real accounts before cutover, since a broken SSO path blocks both chat and calls.

Should we restrict federation for a Matrix video rollout?

Restrict it if your calls and users should stay inside your organization. Synapse's federation_domain_whitelist limits federation to listed domains, an empty list disables federation, and the documentation recommends also firewalling the federation listener. Federation listens on port 8448 by default, and delegation can serve user IDs such as @user:example.com from another host on port 443. Decide this before users join, because changing federation later affects room membership and identities. Confirm the setting and its effect with your own federation test in a staging environment.

How do we scale video without rebuilding the whole stack?

The two stacks scale differently, so plan for each. Jitsi's scalable setup guide says videobridges scale horizontally by adding more, and the default install is already configured for that, with the guide suggesting 4 CPU and 8 GB for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Element Call uses LiveKit as its backend for large meetings, so capacity planning centers on LiveKit nodes and TURN reachability. Ask your vendors or the upstream documentation for current sizing for your expected concurrency, since no supplied fact gives a LiveKit figure.

How DeployOpen helps choose, implement or migrate Matrix video

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Jitsi vs Element Call, that means working from your Matrix homeserver, identity setup and network constraints to a written scope before any build begins.

How we scope

Confirm which Matrix homeserver and client users already run, and whether calls must be end-to-end encrypted.
Record expected participant sizes, recording needs and identity sources in the written scope document.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ask for a quote that separates the decision review, the build and any migration work for each option.

How we build

Deploy the chosen video stack in your cloud accounts, data centers or air-gapped network.
Wire authentication, such as Matrix user verification or JWT tokens, to your existing identity setup.
Test HTTPS certificates, firewall ports, TURN reachability and call quality on the client platforms you support.
Harden the deployment and document configuration, upgrade steps and rollback procedures for your team.

How we hand over

Hand over architecture diagrams, configuration files and runbooks written for your operations staff.
Walk your administrators through upgrades, backups and monitoring of the media and signalling components.
Record which features remain open decisions, such as recording or dial-in, so your team can confirm them.
Provide evidence and documentation prepared for your compliance assessors, who issue any audit outcome.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades for the video stack and the Matrix homeserver it depends on.
Security testing of the deployed calling service can be scheduled as part of an ongoing retainer.
Ask any support proposal to name response expectations and upgrade responsibilities in writing.

Jitsi vs Element Call