Jitsi vs Nextcloud Talk: which to choose

Jitsi or Nextcloud Talk: when a dedicated video bridge fits and when calls inside Nextcloud fit

Choose Nextcloud Talk when your people already work in Nextcloud and calls are small, internal and tied to shared files. Choose Jitsi Meet when meetings are a standalone service, need larger rooms, or must serve guests outside your file platform. Talk keeps chat, file sharing, mentions and call links in the same Nextcloud account, so there is one login and one place to find a document discussed in a call. That benefit holds only at small scale. Without the High Performance Backend, each participant sends a stream to every other participant, and the Nextcloud Talk scalability documentation says Talk usually scales to about 5 to 20 users per call. The High Performance Backend, a selective forwarding unit obtained through Nextcloud sales, is the route to larger calls. Confirm its participant limits and terms in writing before you depend on them.

Choose Jitsi Meet when meetings are a service in their own right. Jitsi Videobridge is the media router, and the scalable setup guide notes that the default install is already configured for horizontal scaling, so you add bridges as demand grows. Jitsi supports JWT tokens, LDAP and Matrix user verification, and the handbook recommends JWT tokens with a separate anonymous domain for guests, which lets you tie room access to your own identity controls. The costs fall on your team. You need a proper domain certificate, because the handbook warns that self-signed certificates cause problems, especially on mobile clients. You also need to open 443/TCP and 10000/UDP, with 5349/TCP and 3478/UDP as optional fallbacks. Chat and file context must come from another system.

The decision turns on four questions. First, how many people will speak or appear on video at the same time, and how many will only watch. Second, whether files and chat must sit in the same place as the call, since that integration is the main reason to pick Talk. Third, whether your network and certificates are ready. Talk needs HTTPS and a TURN server on port 443 or 80 in almost all scenarios, and Jitsi also depends on HTTPS for working audio and video. Fourth, who will run the servers. A Talk deployment adds work to an existing Nextcloud operation, while Jitsi adds a separate stack of web, Prosody, Jicofo and bridge services to patch, monitor and back up. Put these four answers to your platform team before you choose.

Which platform fits which scenario

This table maps common team situations to the platform that usually fits better, with the condition that would change the answer. Read it alongside the participant figures in the scalability documentation, since the High Performance Backend changes the picture for large meetings.

Scenario	Better fit	Why and where the answer changes
Small team already running Nextcloud for files	Nextcloud Talk	Talk sits inside the existing file platform, so chat, file sharing and calls share one login and one admin surface. Without the High Performance Backend, calls usually scale to about 5 to 20 users, so this fits small group calls.
Company-wide meetings with large attendance	Jitsi Meet	Jitsi Videobridge scales horizontally by adding bridges. Talk without the High Performance Backend sends a stream to every other participant, so large rooms become costly. Talk with the High Performance Backend typically handles about 30 to 50 or more active participants, so confirm the sizing with Nextcloud before choosing Talk for this case.
Webinar with many passive viewers	Jitsi Meet or Talk with the High Performance Backend	Talk's documentation describes hundreds of passive participants for webinars only with the High Performance Backend. Without it, Talk is not a fit for this pattern. Jitsi needs its own load test against your bridge sizing before you commit.
Team that needs SIP dial-in	Depends on the backend	Jitsi supports SIP dial-in through the optional Jigasi component. Talk offers optional SIP dial-in through the High Performance Backend, which Nextcloud sells through its sales team. Confirm which option meets your telephony requirements and who supports it.
Video that should sit beside shared files	Nextcloud Talk	Talk offers chat with file sharing and mentions inside the same platform, so calls and documents are reached from one place. If files live in Nextcloud, the fit is strongest. If files live elsewhere, Talk gains less and Jitsi may be simpler to add.
Mixed estate with Nextcloud for files and Jitsi for meetings	Both	Many teams keep Talk for quick calls next to files and add Jitsi for larger meetings or external guests. The cost is a second service to host, secure and back up, plus a second identity integration to maintain.
Team that needs a fully separate meeting service with its own identity options	Jitsi Meet	Jitsi's Docker guide lists internal XMPP accounts, JWT tokens, LDAP and Matrix verification, which lets the meeting service be governed apart from the file platform. Confirm the authentication design against your directory before rollout.
Team that needs a Talk backend only for specific rooms	Confirm with Nextcloud	Talk's requirements call for HTTPS and a TURN server on port 443 or 80 in almost all scenarios. Confirm TURN and signaling capacity with your network team before deciding which rooms need the extra backend.

How Jitsi Meet and Nextcloud Talk are built and what that means for operations

Jitsi Meet is a set of separate services that you deploy and tune as one meeting stack. Nextcloud Talk is a feature inside Nextcloud, so its calls depend on the Nextcloud server, HTTPS and TURN. The cards below show which piece does what and where each choice creates operating work.

Jitsi media and signalling services

A Jitsi Meet deployment combines the Jitsi Videobridge media router, the Jicofo conference focus, the Prosody XMPP server for signalling, and the web server that serves the app. Each service can be checked, restarted and monitored on its own. Jitsi Videobridge carries the media, so it is the component to size first when concurrency grows. Confirm with your team which of these services will own logs, alerts and upgrades.

Optional Jibri and Jigasi

Jibri handles recording and streaming, and Jigasi provides SIP dial-in. Both are optional and both add their own moving parts. Recording means storage planning, retention decisions and handling of recorded personal data. Dial-in means telephony connectivity and a SIP trunk. If you do not need these features, leave them out of the design, and if you do, add them to the written scope before you compare costs.

Debian, Ubuntu or Docker install

The Debian and Ubuntu quick start supports Debian 12 or newer and Ubuntu 24.04 or newer and requires OpenJDK 17. The official Docker setup runs web, prosody, jicofo, jvb, jigasi and jibri as separate containers, and since stable-11146 the containers run rootless with read-only filesystems. The package route suits teams that manage hosts directly. The container route suits teams that already run container platforms and want consistent upgrades. Choose one before you write the scope.

Talk runs inside Nextcloud

Nextcloud Talk runs as an app on your Nextcloud server, so calls share its login, sharing and chat. WebRTC calls need HTTPS, and a TURN server on port 443 or 80 is needed in almost all scenarios. Without a separate media tier, every participant sends a stream to every other participant. Plan the TURN server, its certificate and its firewall rules as part of the Nextcloud rollout, not as an afterthought.

High Performance Backend as a selective forwarding unit

The Talk High Performance Backend is a selective forwarding unit that Nextcloud describes as a partner product obtained through Nextcloud sales. It typically supports 30 to 50 or more active participants and hundreds of passive participants for webinars, and it can provide optional SIP dial-in. Ask Nextcloud for the licensing, sizing and support terms in writing, since these are separate from the Nextcloud server subscription. Do not assume it is included in a standard Nextcloud install.

Database constraints for Talk

Talk must not be used with SQLite, and MySQL or MariaDB must have utf8mb4 support enabled. Because Talk lives in the Nextcloud database, these rules apply to the whole platform, not just to calls. Teams that already run PostgreSQL for Nextcloud should confirm their database version against the Nextcloud requirements. Teams that build a new database should set utf8mb4 from the start, since changing character sets later is disruptive.

Capability by capability: Jitsi Meet against Nextcloud Talk

This table compares Jitsi Meet and Nextcloud Talk on license, scale, collaboration features, identity, recording, network requirements and database needs. Read each row with its condition note, because several answers depend on whether you deploy the High Performance Backend, which identity provider you connect, and how your network allows media to pass.

Capability	Jitsi Meet	Nextcloud Talk
License	Apache-2.0. Jitsi is a trademark of 8x8, Inc.	AGPL-3.0 app for Nextcloud. Condition: the app runs inside a Nextcloud Server, which is AGPL-3.0-only.
Participant limits	Scales horizontally by adding Jitsi Videobridge instances. Condition: size bridges to your concurrency and confirm limits with your own load tests.	Usually about 5 to 20 users per call without the High Performance Backend. Condition: each participant sends a stream to every other, so bandwidth grows with the call.
Participant limits with the High Performance Backend	Not applicable as a separate backend; scale comes from additional bridges.	Typically 30 to 50 or more active participants and hundreds of passive participants for webinars. Condition: the backend is a Nextcloud partner product obtained through Nextcloud sales.
Chat and file integration	Chat is part of the meeting room. File sharing is not built into the meeting app; use your own storage or links.	Chat with file sharing and mentions, tightly bound to Nextcloud files and users. Condition: requires a Nextcloud Server deployment.
Screen sharing	Supported in the meeting client.	Supported. Condition: confirm behavior on your client platforms during testing.
Federation	Not a native federation feature of Jitsi Meet.	Federated chats with users on other Nextcloud servers. Condition: both servers must be configured to federate.
Matrix bridging	Matrix user verification is an authentication option, not a chat bridge.	Integrates Matterbridge to sync messages with other chat systems. Condition: you configure and operate the bridge.
Identity options	Internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, set in the .env file for Docker installs. Condition: JWT is recommended over the deprecated secure domain method.	Nextcloud accounts. Condition: directory integration follows what your Nextcloud Server supports; confirm with your admin manual.
Recording and SIP dial-in	Optional Jibri for recording or streaming and Jigasi for SIP dial-in, deployed as separate components. Condition: these are extra services you run.	Optional SIP dial-in through the High Performance Backend. Condition: recording depends on your setup; confirm before relying on it.
HTTPS and TURN requirements	HTTPS with a proper domain certificate is necessary for working audio and video. Ports 10000/UDP, 80/TCP and 443/TCP are needed; 5349/TCP and 3478/UDP are optional.	HTTPS is required for WebRTC calls. A TURN server on port 443 or 80 is needed in almost all scenarios. Condition: plan TURN capacity with your network team.
Database requirements	Not documented as a Nextcloud-style database dependency; Prosody handles signalling. Condition: confirm the current Docker or package guidance.	Must not be used with SQLite. MySQL or MariaDB needs utf8mb4 support enabled. Condition: follows the Nextcloud Server database support list.

What the licenses and paid options cover for each platform

Jitsi Meet is licensed under Apache-2.0, so you can run, modify and redistribute it inside your own infrastructure without a per-user license from the project. The Jitsi trademark belongs to 8x8, Inc., which matters if you rebrand the product or publish a modified version under the Jitsi name. The latest stable release tag supplied is stable/jitsi-meet_11248, published September 14, 2026.

No license fee for self-hosting: Apache-2.0 places no per-user or per-server charge on the software itself.
Trademark is separate: jitsi.org states that Jitsi is a trademark of 8x8, Inc., so check naming rules before rebranding.
Hosted option from the same vendor: 8x8 offers JaaS (Jitsi as a Service), which is a separate contract and a separate decision from self-hosting.
Paid support is not in the supplied facts: the project's own materials do not define a paid support tier, so ask any provider what support is included.

Confirm the trademark terms and any support arrangement in writing before you commit.

What drives the running cost of each video option

Running either option means paying for servers, certificates, people and upgrades, and the split differs. Jitsi spreads load across a central server and bridges you add, while Talk's cost sits mostly in the Nextcloud host, the TURN server and, for large calls, a paid backend. Use these cards to build the list of what each quote must itemize.

Media servers and bridges

Jitsi needs a central server plus one or more Jitsi Videobridge media routers. The 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 bridge, and says the default install is already set up to scale horizontally. Talk runs its signaling and chat on the Nextcloud server, so its load grows with the Nextcloud instance and with how many users mesh-connect in a call. Ask a provider to size both against your peak concurrent participants, not your total user count.

TURN server hosting

Talk needs HTTPS for WebRTC calls and a TURN server on port 443 or 80 in almost all scenarios, so a TURN relay is a required component, not an option. Jitsi also needs open media ports, including 10000/UDP, and lists 5349/TCP for TCP fallback. Whichever option you pick, budget for the network path that carries relayed media, its bandwidth and its monitoring. Ask who operates the relay and what bandwidth it is sized for.

High Performance Backend licensing

The Talk High Performance Backend is a Nextcloud partner product that enterprises obtain through Nextcloud sales. It adds a selective forwarding unit for larger calls and optional SIP dial-in. It is a recurring commercial line item that Jitsi does not require, since Jitsi's bridges are part of the open-source stack. Ask Nextcloud for a written quote that states the license term, the participant tier, what it includes and whether it is priced per user, per server or per call.

Skills to run TURN, certificates and bridges

Jitsi needs a proper domain certificate, since self-signed certificates cause problems with audio, video and mobile clients. Operating it means keeping Prosody, Jicofo and bridges patched, and handling OpenJDK 17 on the Debian or Ubuntu path or the container stack on Docker. Talk adds TURN configuration, utf8mb4 database settings and HTTPS on the Nextcloud host. Staff time for these tasks is often the largest recurring cost, so ask who on your team owns each one.

Support and retainer options

Nextcloud Enterprise is a paid subscription that includes support from Nextcloud GmbH, and the core server remains AGPL-3.0-only. Jitsi has no equivalent vendor subscription in the sources supplied for this page, so support would come from a provider or from your own team. DeployOpen runs fixed-scope implementations and offers ongoing support, upgrades and testing as retainers, priced from a written scope. Ask any provider for the response commitments, the hours covered and whether upgrades and incident work are included.

Upgrade cadence and switching cost

Nextcloud currently maintains three major lines, and Jitsi Meet publishes stable tags by build number. Each upgrade touches the Nextcloud server, the Talk app and the TURN service together, so plan a test window for each. Moving later is costly in both directions: Talk call history and chat sit inside Nextcloud, while Jitsi rooms are stateless and easier to replace. Ask how each option exports data and how long a parallel run would take before you commit.

Moving calls from Jitsi to Nextcloud Talk or back, in order

This sequence moves a team's meeting practice between Jitsi Meet and Nextcloud Talk without losing user accounts, file access or chat history, and leaves the team with verified links and client settings on the new platform.

Confirm participant profile and TURN readiness
Before anything else, record the typical call size, the share of participants joining from outside the corporate network, and whether calls need SIP dial-in or recording. Nextcloud Talk needs HTTPS for WebRTC calls and a TURN server on port 443 or 80 in almost all scenarios, and Jitsi needs ports 80/TCP, 443/TCP and 10000/UDP open. Confirm with your network team whether those ports can be reached from the internet and whether a TURN service is already running. Output: a one-page profile listing the largest typical call, the network paths in use and a yes or no on TURN readiness.
Stand up the target platform
Install the target and test it with a small set of internal users. For Nextcloud Talk, confirm the Nextcloud server version against the system requirements, and do not use SQLite with Talk. If your largest calls exceed the range that Talk usually handles without the High Performance Backend, ask the vendor or Nextcloud sales about that backend before you commit, since it is a Nextcloud partner product that enterprises obtain through Nextcloud sales. For Jitsi, the Debian or Ubuntu quick start and the Docker setup are the two documented routes. Output: a test instance with HTTPS working on a proper domain certificate, and a test call that succeeds from inside and outside the network.
Map identities and rooms or conversations
Export the list of accounts and the rooms or conversations in use, then decide how each maps to the target. Directory sync can carry user accounts across when your identity source is LDAP or a similar directory, so confirm that path with your identity team. Jitsi authentication options include internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid mode, and the handbook recommends JWT token authentication over the deprecated secure domain method. Documented room links can be recreated on the target with the same names where the naming rules allow. Output: a mapping sheet with one row per user group and per recurring room, marked as carried over or rebuilt.
Move files and chat history the platform keeps
Calls do not carry history, so the work here is for the parts that persist. Nextcloud Talk keeps chat with file sharing and mentions inside the Nextcloud data set, so the chat and shared files move with the Nextcloud data store when you migrate that instance. Jitsi itself keeps no chat history of its own, so any recordings or transcripts should be moved from wherever your Jibri or storage setup wrote them. Confirm with your administrators where recordings are kept and how long they are retained. Output: a list of what moved, where it now lives, and a sample of files and chat threads opened on the target to confirm they are intact.
Rebuild JWT claims, room naming and TURN configuration
Items that do not transfer must be configured again on the target. On Jitsi, JWT claims, the separate anonymous domain for guests and the configuration keys in the Docker .env file are set by hand. On Talk, TURN server settings, the signaling configuration and room types (private, group, public and password-protected) are set in the admin panel. Document each rebuilt setting with its owner. Output: a configuration record listing each key or setting, its value owner and the test that confirmed it works.
Update client settings and retire old links
Update desktop and mobile clients, bookmarks, calendar invitations and any embedded meeting widgets to point at the new platform. Set a date after which old Jitsi links redirect users or stop working, and tell users in advance. Keep the old instance running in read-only form for the overlap period so that existing invitations can be answered. Output: a list of every place a meeting link appeared, marked as updated or retired, with the cutover date recorded in writing.
Verify calls, access and recovery end to end
Run scripted test calls at the sizes in your participant profile, from inside the network, from an external network and from a mobile client. Check that identities log in, that guest access works through the intended path, that recordings or dial-in function if you use them, and that a restore from backup brings the platform back. Ask your team to confirm the results in writing. Output: a signed-off test report covering participant sizes, client types, access paths and one restore test, with any open defects assigned to an owner.

What implementing each platform involves and where projects usually run long

Implementing Jitsi starts with HTTPS on a proper domain certificate, because the Jitsi handbook says it is necessary for working audio and video and warns that self-signed certificates cause problems, especially with mobile clients. Plan for 80/TCP, 443/TCP and 10000/UDP to be open, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional. The choice of authentication is the main design decision. The handbook marks the older secure domain method as deprecated for new installations and recommends JWT token authentication, with a separate anonymous domain for guests. Confirm with your identity team how JWT tokens will be issued and whether LDAP, Matrix verification or internal XMPP accounts are needed, since these are set in the .env file for Docker installs. Bridge capacity grows by adding videobridges, so decide early whether one bridge is enough for your concurrency.

Nextcloud Talk work sits in different places. The Talk system requirements call for HTTPS for WebRTC calls and a TURN server on port 443 or 80 in almost all scenarios, so the TURN service and its certificate are the first items to build and test. The database rules are strict: Talk must not be used with SQLite, and MySQL or MariaDB needs utf8mb4 enabled. Sizing for the High Performance Backend is the largest open question. It is a Nextcloud partner product that enterprises obtain through Nextcloud sales, so its sizing and cost come from a quote, not from this page. Ask for the expected participant counts per call, the SIP dial-in requirement, and the hosting footprint in writing before procurement starts.

Projects usually run long in four places: certificate and firewall work, identity integration, TURN testing across networks, and quote approval for the High Performance Backend. TURN failures often appear only from guest networks or mobile carriers, so test calls from outside the office before sign-off. A fixed-scope agreement should define in writing the hostnames and certificates, the firewall rules and ports, the authentication method and token issuance, the TURN and signaling tests across named networks, the database configuration, the bridge or backend sizing, and who approves the Nextcloud partner quote. Ask the provider to state which items are one-time setup and which recur, such as certificate renewal, upgrades and retained support.

Questions buyers ask before choosing Jitsi or Nextcloud Talk

How many people can a Nextcloud Talk call support without the High Performance Backend?

Without the High Performance Backend, Talk usually scales to about 5 to 20 users in a single call, according to the Talk scalability documentation. Each participant sends a stream to every other participant, so the upload load grows with the number of people in the call. The practical limit depends on each participant's bandwidth and device, so pilot with your typical meeting size before you commit. Confirm the figures for your own client mix with the Talk scalability guidance at Nextcloud Talk scalability.

How many people can a Talk call support with the High Performance Backend?

With the High Performance Backend, Talk typically scales to 30 to 50 or more active participants and hundreds of passive participants for webinars, according to the Talk scalability documentation. The backend uses a selective forwarding unit, so each participant sends one stream to the server rather than to every peer. It is a Nextcloud partner product that enterprises obtain through Nextcloud sales, so its licensing and cost are set by that sales process, not by the open-source core. Ask for the exact terms and sizing in writing before you plan large meetings.

Can Jitsi run alongside Nextcloud, and when does that make sense?

Yes, many teams keep Nextcloud Talk for chat and small calls inside their file platform and add Jitsi for larger meetings, webinars or rooms that guests join without a Nextcloud account. Jitsi is a separate Apache-2.0 stack with its own web server, Prosody, Jicofo and Videobridge components, so it adds a second system to run and back up. The case is strongest when meeting size or guest access is the main requirement. Decide whether the added operations are worth it by listing which meetings Talk cannot serve well today.

What TURN and certificate work falls to our team?

Talk needs HTTPS for WebRTC calls and a TURN server on port 443 or 80 in almost all scenarios, according to the Talk system requirements, so your team must provide certificates and TURN reachability through firewalls. Jitsi needs HTTPS with a proper domain certificate, since the Jitsi handbook warns that self-signed certificates cause problems, especially with mobile clients. Jitsi also expects ports 80/TCP, 443/TCP and 10000/UDP open, with 5349/TCP for TCP fallback and 3478/UDP for STUN optional. Ask the implementation partner to document the certificate renewal process, firewall rules and TURN placement in the scope.

How long does an implementation of either platform take?

No supplied duration exists for either platform, so the timeline depends on your scope, existing identity and network setup, and the number of integrations. The work usually grows with the TURN and certificate design, the authentication choice for Jitsi, and any high performance backend or recording requirements. Ask for a timeline, milestones and acceptance criteria in the written scope, since most DeployOpen engagements are fixed-scope and agreed in writing before work starts.

Can our own team deploy and run these platforms without outside help?

A capable Linux operations team can deploy both platforms, but it needs skills in DNS, certificates, firewalls, UDP media networking, databases and upgrades. Jitsi's Debian or Ubuntu quick start requires OpenJDK 17 and supports Debian 12 or newer and Ubuntu 24.04 or newer, while Talk depends on the Nextcloud server, a supported database and TURN configuration. Ongoing work includes patching, monitoring call quality and handling upgrades across both systems. If the team lacks these skills, ask for a fixed-scope handover or a support retainer in the quote.

What does the work need from our infrastructure and staff?

You need servers or virtual machines in your own cloud, data center or network, a domain with valid certificates, open UDP media ports and a named owner for each service. Jitsi scalable setups add videobridges as load grows, and the Jitsi scalable guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Talk's sizing depends on the Nextcloud deployment and whether the High Performance Backend is added. Confirm current sizing with the vendor or the documentation before you approve hardware or cloud spend.

How DeployOpen helps teams choose, implement or migrate video

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Jitsi vs Nextcloud Talk, that means working out whether a dedicated Jitsi bridge or calls inside Nextcloud fit the participant sizes, network paths and identity setup your organization actually has.

How we scope

Written scope agreed before work starts, covering which video platform, user counts and call types are in play.
Review of your Nextcloud or other file platform version, database, and whether Talk or a separate Jitsi deployment is needed.
Network inventory for HTTPS certificates, TURN reachability, UDP media ports and identity sources such as LDAP or JWT.

How we build

Installation in your cloud accounts, data centers or air-gapped networks, with TURN, certificates and firewall rules configured.
Integration of chosen authentication, such as Jitsi JWT tokens or Nextcloud user accounts, tested against real sign-in paths.
Load and concurrency testing against the participant sizes your teams expect, with results recorded for the scope.

How we hand over

Documentation of the architecture, configuration keys, ports, certificates and upgrade steps for your operations staff.
Runbooks covering scaling, backup of configuration and recording storage, and troubleshooting of audio and video failures.
Handover session with administrators so your team can run the platform after delivery.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Security testing of the deployed video service and its exposed web and TURN endpoints, if included in the written scope.
Confirm with us in the quote which support windows, response expectations and upgrade cadence apply to your environment.

Jitsi vs Nextcloud Talk