Webex vs Jitsi Meet: when a self-hosted alternative to Webex fits
Jitsi Meet fits organizations that want browser-based meetings, media kept inside their own network and a self-hosted platform they can operate, while Webex remains the better match where a standardized room device estate and Cisco-managed cloud services are the priority. Most readers arrive at this point because of a Webex renewal, a data residency or lock-in concern, or a Video Mesh estate they want to move off. Each trigger leads to the same question: what would your users lose if the meeting platform changed, and who would keep it running afterward?
The decision turns on four things. The first is room device needs. Webex is tied to Cisco and Webex room hardware and its registration model, and Jitsi has no direct equivalent for that ecosystem, so SIP room systems must be bridged through Jigasi and tested device by device. The second is data control requirements, including where media, recordings and identity data must sit and whether an HTTPS certificate from your own domain is acceptable. The third is in-house operations capacity. A Jitsi deployment spans the web front end, Prosody, Jicofo and one or more videobridges, and each of these needs patching and monitoring. The fourth is recording and SIP needs, which determine whether Jibri and Jigasi are required from day one.
Before you decide, confirm these points with your Webex account team and in your own environment: which devices and dial-in paths your users depend on, how many concurrent participants you host at peak, which recordings must be archived, and whether your identity provider can issue the tokens Jitsi needs. Run a pilot with a representative room and a representative external guest. The pilot results, not the feature list, should decide whether Jitsi fits your situation.
Which scenarios favor Webex and which favor self-hosted Jitsi Meet
This table matches common buying situations to the platform that fits them better, with the reason tied to Video Mesh, Control Hub and Jitsi's components. Read each row as a question about your own environment: if the answer leans toward the self-hosted column, confirm the listed dependencies before committing. Most organizations will find a mix of rows that point in both directions.
| Scenario | Better fit | Reason |
|---|---|---|
| Standardized Cisco room devices across many sites | Webex | Webex room devices and Control Hub management are built around the Webex cloud, and Jitsi has no direct equivalent of that device ecosystem. |
| Small IT team with no appetite for operations | Webex | Jitsi needs you to run the web front end, Prosody, Jicofo and videobridges, plus HTTPS certificates and upgrades, all of which fall to your staff. |
| Meetings that must stay on premises | Self-hosted Jitsi Meet | Jitsi media can run entirely in your network, while Video Mesh nodes must stay registered to the Webex cloud and be managed in Control Hub. |
| Sites needing SIP room systems | Depends on device fit | Jitsi reaches SIP endpoints through Jigasi, so confirm the room systems and call flows you need are supported before choosing it. |
| External guests joining from unmanaged devices | Self-hosted Jitsi Meet | Jitsi works in a browser without a client install, but you must issue a valid certificate for the domain, since self-signed certificates cause problems, especially on mobile. |
| Jitsi deployment with a tight certificate and domain policy | Webex | Jitsi requires HTTPS with a proper domain certificate for audio and video to work, so DNS and certificate renewal become a standing task. |
| Recording and live streaming to internal systems | Self-hosted Jitsi Meet | Jibri records and streams inside your environment, but it is an optional component you deploy and size yourself. |
| Teams that need to scale capacity for peaks | Depends on sizing discipline | Jitsi videobridges scale horizontally by adding more, but you buy and operate each one, while Video Mesh overflows to the cloud when local capacity runs out. |
How a self-hosted Jitsi Meet deployment fits together
A self-hosted Jitsi Meet deployment is several cooperating services, and the first decision is which parts you need. The web front end, served by nginx or Apache, delivers the Jitsi Meet app to browsers. The Prosody XMPP server handles signaling and accounts, Jicofo acts as the conference focus that creates and manages rooms, and one or more Jitsi Videobridge instances route the audio and video streams. Jibri, which records and live streams meetings, and Jigasi, the SIP gateway for room systems, are optional. Jigasi matters most if you are moving Webex room devices that dial in by SIP, so confirm early whether any of your endpoints need it. The components can be installed from Docker containers, with the official setup running web, prosody, jicofo, jvb, jigasi and jibri as separate containers, or from Debian and Ubuntu packages. Choose Docker if your team already operates container hosts, and packages if you prefer to manage the services directly on Linux.
For the package route, the Debian and Ubuntu quick start supports Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer, and requires OpenJDK 17. Open ports 80/TCP, 443/TCP and 10000/UDP on the host and any firewall in front of it. Port 5349/TCP is a fallback for clients that cannot reach media over UDP, and 3478/UDP for STUN is optional. Confirm these ports with your network team before the pilot, because blocked UDP is the most common reason calls degrade for remote staff.
HTTPS is not optional. The Jitsi handbook states that HTTPS with a certificate for your own domain is necessary for audio and video to work. Self-signed certificates cause problems, especially on mobile clients, so plan for a certificate from your internal certificate authority or a public one, and make sure every device in your fleet trusts it before users are moved over. Test a call from an iOS and an Android device on a mobile network as part of acceptance, not only from a desktop browser on the office LAN.
Where meeting data lives and who controls identity and compliance
Webex splits meeting work between on-premises media nodes and a cloud control plane, while a self-hosted Jitsi deployment keeps both inside your own infrastructure. The cards below cover where media and recordings sit, who runs administration, which sign-in methods Jitsi supports, how hosting models differ, and what compliance evidence you must produce yourself.
Media and recording location
Webex Video Mesh keeps media on premises, but meeting metadata and the node registration still go to the Webex cloud. With self-hosted Jitsi, the web app, Prosody, Jicofo, Jitsi Videobridge and any Jibri recorder run in your network, so media and recordings are written to storage you choose. Confirm where Jibri output lands, how long it is kept and who can download it.
Control plane dependence
Video Mesh nodes are managed in Control Hub and must stay registered to the Webex cloud, so administration depends on that service being reachable. A self-hosted Jitsi deployment has no vendor console to fail. Your team owns the configuration files, the .env settings, the certificates and the update cadence, which removes a dependency but adds operational work that must be staffed.
Identity options in Jitsi
Jitsi supports internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, all set through the .env file. The handbook marks the older secure domain method as deprecated for new installs and recommends JWT authentication with a separate anonymous domain for guests. Map these options to your directory before choosing one, and confirm how each handles offboarding.
Hosting model choice
8x8 sells Jitsi as a Service (JaaS), which runs the platform for you, and operates the free public instance at meet.jit.si. Self-hosting keeps the platform in your accounts or data centers but moves patching, scaling and incident response to your team or to a partner. Ask a JaaS provider where its data is processed and which contract terms govern recordings before you decide.
Compliance evidence ownership
Regulated buyers need documented controls, access logs, change records and retention settings to show an assessor. Webex and Jitsi each provide different artifacts, so list the evidence your framework requires and check what each side produces. DeployOpen prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
Operating a Jitsi deployment by team size and environment
Running Jitsi in your own cloud account keeps the media and recordings under your control while the provider handles physical hardware. Your team still owns the operating system images, the Jitsi packages or containers, the TLS certificates and the autoscaling rules for videobridges. The official Docker setup runs separate web, prosody, jicofo, jvb, jigasi and jibri containers, so you can rebuild and redeploy components independently.
- Patching: Rebuild and redeploy container images on a schedule you set, and track Jitsi releases such as the tagged stable builds listed in the GitHub repository.
- Certificates: Jitsi's handbook says HTTPS with a proper domain certificate is necessary for audio and video to work, so automate renewal and test it before expiry.
- Scaling: Add videobridges horizontally as meeting load grows. 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 videobridge, which you should validate against your own load tests.
- Monitoring: Watch bridge CPU, bandwidth and UDP port reachability, since the default media path uses 10000/UDP.
- Recording: Jibri needs its own sizing and storage planning if you enable it.
Confirm with your cloud provider which network and firewall rules you can apply, and ask your DeployOpen or in-house team to document the rebuild procedure.
A data center deployment gives you full control over hardware, network paths and physical access, but it also makes you responsible for every layer below the application. Capacity planning, switch configuration, storage for recordings and out-of-band management all sit with your infrastructure team. Scaling means ordering or repurposing hardware, so plan capacity ahead of demand rather than reacting to it during a live incident.
- Patching: Schedule operating system and Java updates, since the Debian and Ubuntu quick start requires OpenJDK 17, and test restarts of the Prosody and Jicofo services.
- Certificates: Use a certificate authority your clients trust. The handbook warns that self-signed certificates cause problems, especially with mobile clients.
- Network: Open 80/TCP, 443/TCP and 10000/UDP, and consider 5349/TCP for TCP fallback and 3478/UDP for STUN, which the quick start lists as optional. Coordinate with the firewall and load balancer owners.
- Monitoring: Feed host and service metrics into your existing monitoring stack, and alert on bridge saturation before users notice audio issues.
- Hardware lifecycle: Track warranty and replacement dates for the servers that host videobridges.
Confirm your internal change windows and who approves firewall rule changes before you commit to a design.
In an air-gapped network Jitsi must run without internet access, so every package, container image and certificate must be staged inside the enclosure. There is no external provider to call for certificate issuance or emergency patches, and no hosted fallback. Updates arrive through a controlled transfer process that your security team defines, which makes release tracking and verification part of the operating routine.
- Patching: Mirror the required packages or container images into an internal repository, verify signatures or checksums on import, and apply them in planned windows.
- Certificates: Issue certificates from an internal certificate authority with a proper domain name, and plan renewal well ahead of expiry because you cannot rely on public automation.
- Authentication: Choose between internal XMPP accounts, JWT tokens or LDAP as configured in the
.envfile, and avoid designs that need outbound calls to external services. - Monitoring: Keep logging and metrics inside the enclosure and define who reviews them.
- Recording and SIP: Jibri and Jigasi add components to patch and certify, so include them in the inventory only if you need them.
Confirm with your accreditation authority how software is admitted into the enclosure, and ask whether your team can rehearse a full restore from offline media.
A team with platform engineering experience can own Jitsi as a standard internal service. The main work is keeping the deployment current, automating the routine tasks and building the runbooks that let others respond when something fails. Staff cost is the largest variable, and it depends on how much of the platform team's existing capacity you can redirect, which you should confirm internally rather than assume.
- Automation: Keep configuration in version control, script certificate renewal and rolling updates, and test changes in a staging environment that matches production.
- Scaling: Use the default horizontal scaling configuration to add videobridges as load grows, and document the thresholds that trigger a new bridge.
- Monitoring: Build dashboards for bridge load, failed joins and certificate expiry, and route alerts to an on-call rotation.
- Security hygiene: Review the secure domain deprecation note and move to JWT token authentication with a separate anonymous domain for guests.
- Knowledge transfer: Record the deployment steps so that the service does not depend on one engineer.
Ask your team to estimate its own on-call and maintenance hours, and compare them with the scope of any retainer you consider.
A team without platform engineering depth should treat Jitsi as an operated service with named owners, not a set-and-forget install. Someone must be accountable for patching, certificates, capacity and incident response, either through internal staff trained for the task or through an external provider under a written agreement. The gap in skills is usually discovered during the first certificate renewal or first capacity incident, so test those before go-live.
- Ownership: Name a service owner and a backup, and define who responds when meetings fail to connect.
- Patching: Agree a patch cadence and a method for testing updates before they reach users.
- Certificates: Confirm that renewal is automated, since expiry breaks audio and video.
- Scaling and monitoring: Ask for alerts on bridge load and a documented procedure to add capacity.
- External support: Consider fixed-scope implementation followed by a support retainer, and ask for the written scope, deliverables and response expectations before signing.
Confirm with any provider which responsibilities they take on and which remain with your staff.
Cost of ownership: Webex subscriptions compared with Jitsi infrastructure and operations
Webex is paid for as a subscription, with Video Mesh hardware and support added where on-premises media is needed. A self-hosted Jitsi Meet deployment moves that spend into servers, bandwidth, implementation and staff time, most of it recurring. The cards below separate what is one-time from what recurs, and what to ask for before comparing totals.
Webex licensing and renewals
The Webex subscription is a recurring fee paid to Cisco or a reseller, usually per user or per license type, and it covers the cloud meeting service itself. Its cost moves with seat count, license tier and renewal terms, so the comparison should start from your current contract. Ask your reseller which features are bundled, what happens to pricing at renewal, and whether Video Mesh or Control Hub features sit in a separate line item. Webex prices are not quoted here, so confirm them against your own agreement.
Video Mesh hardware and support
If you run Video Mesh, the on-premises nodes are software installed on a Cisco UCS server, so you carry the server purchase, data center space, power and hardware support. Confirm with Cisco or your reseller whether the server and its support are billed separately from the subscription, and what capacity each node is sized for. Those figures determine how many nodes you need before overflow goes to the cloud. Treat this as a recurring support cost plus a one-time hardware purchase.
Central node and videobridge servers
A Jitsi deployment needs one central server running the web front end, Prosody, and Jicofo, plus one or more Jitsi Videobridge servers that carry the media. The published sizing suggestion is a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Hardware is a one-time purchase or a recurring cloud instance cost, and more bridges are added as concurrent participants grow. Confirm sizing with a load test in your own environment before buying.
Bandwidth and network capacity
Media traffic leaves each videobridge and crosses your internet link, so bandwidth is a recurring cost that scales with participants and video quality. Jitsi needs 10000/UDP open for media, with 443/TCP and optionally 5349/TCP for fallback, so firewall and load balancer changes are part of the network budget. Ask your ISP or cloud provider for committed bandwidth and egress pricing, and compare it with what Video Mesh and Webex cloud traffic consume today.
Implementation and certificates
Implementation is usually a one-time cost: planning, installation, domain and HTTPS setup, authentication configuration, and testing with clients. Jitsi's handbook says working audio and video need HTTPS with a proper domain certificate, and self-signed certificates cause problems, especially on mobile. Certificate issuance and renewal is an ongoing task. Ask any implementation partner for a written scope that names the authentication method, SIP gateway needs and the test plan.
Operations staff and upgrades
Operations is the largest recurring cost in most self-hosted estimates: staff time for patching, monitoring, capacity planning, backups and upgrades across the central node and bridges. Jitsi releases are published as numbered stable builds, so someone must track and apply them. Estimate the share of an engineer's time this takes, or the retainer cost of an outside provider, and compare it with the support you currently receive under Webex.
Optional JaaS hosted option
Jitsi as a Service, run by 8x8, is a hosted alternative that removes most server, bandwidth and operations cost, leaving a subscription that recurs. It also reintroduces a third-party hosting dependency that the self-hosted model avoids. If you consider JaaS as a middle path, ask 8x8 for pricing, data location terms and the SLA in writing, and compare them with your Webex renewal and with the self-hosted total.
How a move from Webex to Jitsi Meet is structured
The sequence turns Webex meeting use into a self-hosted Jitsi Meet service with a documented HTTPS domain, a token-based sign-in design, sized videobridges, archived recordings and a verified cutover. Each phase ends with a written output the next phase depends on.
Inventory meeting use and room devices
Your team, or DeployOpen under a written scope, catalogs how Webex is used: meeting volumes by team, guest and external participation, recording needs, scheduled webinars, and every room system or Video Mesh node that joins meetings. Room devices are the item most likely to lack a direct Jitsi equivalent, so each one is tagged as replaced, bridged through Jigasi for SIP, or retained. The output is a signed inventory that names an owner for each use case and each device. The step is done when every Webex feature in use appears on the list with a decision.
Set up the domain and HTTPS certificate
The platform team selects a domain, issues a proper certificate from a trusted authority and configures the web front end, Prosody, Jicofo and Jitsi Videobridge on Debian 12 or newer, or Ubuntu 24.04 or newer, or as Docker containers. The Jitsi handbook states that HTTPS is necessary for working audio and video and warns that self-signed certificates cause problems, especially on mobile clients, so this is a gate rather than a later hardening task. The check is a test meeting that opens and carries audio and video from a desktop browser and a mobile device on the corporate network and from outside it.
Design authentication with JWT and an anonymous domain
Security and identity staff decide who may create rooms and how guests join. The Jitsi handbook marks the older secure domain method, where users create rooms with a username and password, as deprecated for new installations and recommends JWT token authentication. The design normally keeps authenticated employees on the main domain and sends guests through a separate anonymous domain. The Docker guide lists internal XMPP accounts, JWT, LDAP and Matrix verification as options configured in the .env file, so the chosen option must be recorded with its configuration. The output is a reviewed authentication design and a test in which an unsigned guest cannot create a moderated room.
Size and scale the videobridges
Capacity planning turns the meeting profile from step one into a count of Jitsi Videobridge hosts. The scalable setup guide suggests 4 CPUs and 8 GB of memory for the central server and 4 or 8 CPUs with 8 GB of memory for each videobridge, and says the default install is already set up for horizontal scaling. These are starting points from the Jitsi guide, not guarantees for your traffic, so the load test in this step decides the final count. Ask the operator for the peak concurrent participant figure and the number of simultaneous meetings you need to support. The output is a tested capacity figure per bridge and a documented procedure for adding a bridge.
Archive existing Webex recordings
Recordings that must be kept are exported from Webex before the subscription ends, stored in the organization's own object or file storage, and indexed with owner, date and retention class. Webex export methods and formats are covered in the export guide, so this step follows that inventory rather than assuming a bulk download. Jitsi's optional Jibri component handles new recordings and live streams, and it needs its own host and configuration. The output is an archive with a retention schedule and a sample of files opened and checked by their owners. Items that cannot be exported are logged as known losses for legal review.
Run a pilot with a bounded user group
A pilot group of internal users and a small set of external guests hold real meetings on the new service for a defined period agreed in the project plan. Participants record problems in a shared log that covers audio, video, screen sharing, sign-in, and room device or SIP behavior through Jigasi. The team tunes bridge capacity, firewall rules for 10000/UDP and the TCP fallback ports, and the moderator procedures from what the pilot shows. The output is a closed issue log and a go or no-go decision recorded by the sponsor.
Cut over and decommission Webex
Users are moved to the Jitsi URL, calendar invitations and room device configurations are updated, and Webex scheduling is disabled for each group in an agreed order. Access to old recordings is kept available for the archive period, and Video Mesh nodes or room device registrations tied to Webex are removed only after the last dependent meeting type has moved. The output is a dated cutover record, a decommissioning checklist signed by the platform owner and a documented monitoring period. Commercial terms and contract exit are handled separately with Cisco.
Questions buyers ask before replacing Webex with Jitsi Meet
What does it cost to replace Webex with a self-hosted Jitsi Meet deployment?
The cost is the sum of infrastructure, one-time implementation and recurring operations, and no supplied figure sets the total for your organization. Jitsi itself is Apache 2.0 licensed, so there is no license fee to remove. You will pay for servers or cloud instances for the web front end, Prosody, Jicofo and one or more Jitsi Videobridge nodes, plus bandwidth, TLS certificates and staff time for patching and monitoring. Costs rise with concurrent participants, recording volume and the number of sites. Ask any provider for a written quote that separates one-time work from recurring hosting and support, and ask them to state their assumptions about peak concurrency.
How long does a Webex to Jitsi Meet migration take?
The pace is set by scope, not by the software install itself. The main drivers are how many meeting types you have, whether SIP room systems must keep working, how recordings are archived, identity integration, and how many users need retraining. The Jitsi Debian and Ubuntu quick start is short for a single server, but a production setup with separate videobridges, authentication and HTTPS certificates takes longer to design and test. Request a timeline in the written scope, with milestones for a pilot group, cutover and the Webex retirement date.
What does the work require from our own team?
Your team needs people who own DNS, certificates, network firewall rules, identity and day-to-day operations. Jitsi needs HTTPS with a proper domain certificate, because the handbook says self-signed certificates cause problems, especially on mobile clients. The ports to open include 80/TCP, 443/TCP and 10000/UDP, with 5349/TCP and 3478/UDP optional. Plan for on-call coverage, patch windows for the containers or packages, and a decision on how users sign in, for example JWT tokens or LDAP through the .env file. Confirm these responsibilities in the scope before work starts.
Can our internal team run the migration without an outside implementation partner?
Yes, a capable internal team can deploy Jitsi, but the question is whether it has the time and skills for the full scope. Teams that have run Linux servers, reverse proxies and certificate renewal usually cover the core install. The harder parts are authentication design, sizing and testing videobridges, SIP gateway work through Jigasi, and evidence for security or compliance reviews. Many organizations split the work: internal staff own operations, while an implementation partner handles design, hardening and documentation under a fixed-scope agreement. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own environment, and is available on a fixed-scope basis or as a retainer.
Does Jitsi Meet replace Webex room devices and SIP endpoints?
Not directly. Webex room devices and Webex Video Mesh are part of Cisco's ecosystem, and Jitsi has no drop-in equivalent for those hardware endpoints. Jitsi can reach SIP systems through the optional Jigasi gateway, so room systems that dial a SIP address may still join a meeting, but you must test the audio and video quality, dial plans and any features your room hardware depends on. Make an inventory of every room device and its role before deciding. Confirm with each vendor which SIP or standards-based options they support.
How do we keep and archive our Webex recordings?
Export recordings from Webex before the contract ends, because a self-hosted Jitsi deployment does not import Webex archives. Jitsi records meetings with Jibri when you enable it, so new recordings are stored on your own servers, and you must size disk space and set a retention policy for them. Old recordings should be downloaded and stored in an archive that your records and legal teams approve. Confirm the export formats and any retention obligations with your legal and records teams, and ask the migration provider how they will verify each archived file.
Is hosted Jitsi as a Service an alternative to self-hosting?
Yes, it is a different option with a different responsibility split. 8x8 offers JaaS, which the Jitsi project describes as the team that builds Jitsi running it for you, and the free public instance is meet.jit.si. JaaS removes much of the server work, but meetings then run on a vendor's infrastructure, so you must review its data location, retention and access terms against your residency and compliance needs. If your requirement is that meeting media stays in your own network or cloud accounts, self-hosting is the relevant path. Compare the two options in writing before deciding.
How DeployOpen helps evaluate and implement Jitsi Meet
DeployOpen plans, implements, hardens, backs up and supports self-hosted Jitsi Meet inside your own cloud accounts, data centers or air-gapped network. For a Webex replacement, the first piece of work is usually an evaluation of what your meetings actually need: how many concurrent participants you host, which users join from SIP room systems, whether you record, and whether any Webex Video Mesh or Control Hub dependencies must be replaced rather than moved. The output is a written scope that names the components to deploy, including the web front end, Prosody, Jicofo, Jitsi Videobridge and, if needed, Jibri and Jigasi, along with the HTTPS certificate approach, the authentication model (JWT tokens, LDAP or Matrix verification) and the sizing assumptions. Work is typically fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts, and a quote follows from that scope rather than from a published price list.
After go-live, the ongoing work is what most open-source meeting projects underestimate. DeployOpen can harden the deployment, run security testing against the web application and its exposed services, and set up backups and upgrade procedures so that the platform keeps pace with new Jitsi Meet stable releases. Ongoing support, upgrades and continuous testing are available as retainers, which suits organizations that do not want to staff a video platform team in-house. On compliance, DeployOpen can help prepare system configurations, access controls and evidence for an assessment, but it does not issue audit reports, attestations or certifications. Ask any implementation partner, including DeployOpen, to confirm in writing which of these items sit inside the fixed scope and which fall under a retainer, and confirm with your auditor which evidence they will accept.
