Webex Video Mesh vs self-hosted Jitsi: which one fits a media-on-premises requirement
Jitsi can replace the media path of a Video Mesh deployment, but it cannot replicate the Webex control plane, so the answer depends on whether your requirement is about where media flows or where the service is managed. A buyer who already runs Video Mesh on Cisco UCS servers and needs audio and video to stay inside the building can run self-hosted Jitsi Meet with its own Jitsi Videobridge media routers on their own servers. Video Mesh is software installed on an on-premises Cisco UCS server, registered to the Webex cloud and managed in Control Hub, and it keeps meetings local while overflowing to the cloud when local capacity runs out. Jitsi has no equivalent registration or cloud overflow path unless you build one, so the overflow behavior you may rely on today has to be designed or accepted as a gap.
Video Mesh keeps the media local, but the node still depends on the Webex cloud for registration, configuration, licensing, meeting scheduling and administration through Control Hub. Confirm with your Cisco account team which of these functions would stop if the link to the Webex cloud were cut, because that determines whether the deployment meets an air-gapped or disconnected requirement at all. A self-hosted Jitsi stack has no such dependency: the web front end, Prosody, Jicofo and the videobridges run inside your network, and its authentication can be tied to your own systems through internal XMPP accounts, JWT tokens or LDAP, as described in the Jitsi Docker guide. The trade-off is that you take on the server operation, certificate management and capacity planning that Cisco and Webex currently carry.
The short answer is that self-hosted Jitsi fits a media-on-premises requirement well when meetings are internal or partner-facing and the organization can run its own infrastructure, but it does not replace Control Hub administration, Webex's room device ecosystem or cloud overflow without additional design work. Jitsi requires HTTPS with a proper domain certificate, and the handbook warns that self-signed certificates cause problems, especially on mobile clients. Before you commit, ask Cisco to confirm in writing what Video Mesh needs from the cloud during normal operation and during an outage, and map each Webex dependency to a Jitsi component or an accepted gap, a step DeployOpen can scope with you in a fixed-scope assessment.
What an on-premises media requirement actually demands
An on-premises media requirement usually covers three things: where audio and video are processed, which control plane may touch meetings, and who keeps the stack running. Webex Video Mesh and self-hosted Jitsi answer these questions differently, so the cards below are the points to settle in your own policy before comparing features.
Where media is processed
Video Mesh is software installed on an on-premises Cisco UCS server, so meeting media can stay inside your network when local capacity is available. A self-hosted Jitsi deployment places its videobridges in the infrastructure you choose, including data centers or air-gapped segments. Confirm whether your policy covers signaling, media, recordings and logs separately, because each may land in a different place. Ask Cisco which of these traffic types leave your network in your configuration.
Which control plane may touch meetings
Video Mesh nodes stay registered to the Webex cloud and are managed in Control Hub. Your policy must state whether a cloud control plane that schedules, authenticates and administers meetings is acceptable, even if media stays local. With self-hosted Jitsi, the web front end, Prosody, Jicofo and the videobridges all run in your environment, so no vendor control plane is in the path. Map each Control Hub function you use today against this question before you decide.
How capacity overflows
Video Mesh keeps meetings local and moves them to the cloud when on-premises capacity runs out. That behavior may be useful for peak days, but it means some sessions can leave your infrastructure without a manual decision. A Jitsi cluster has no cloud fallback unless you build one, so overflow becomes a sizing decision you own. Ask Cisco what triggers overflow and whether you can disable it for regulated meetings.
Who supports the stack
With Video Mesh, Cisco supports the Webex service and Video Mesh software, while your team maintains the UCS hardware, network paths and certificates. With self-hosted Jitsi, your team or an implementation partner carries patching, upgrades, monitoring and incident response for every component. Write down who answers for a failed media node at 2 a.m., and whether that person can get vendor support for the underlying platform. Confirm the support terms in your contract rather than assuming them.
Certificates and network prerequisites
Jitsi needs HTTPS with a proper domain certificate for audio and video to work, and self-signed certificates cause problems, especially on mobile clients. Its Debian and Ubuntu quick start also requires ports 80/TCP, 443/TCP and 10000/UDP open. Check how your firewall and certificate authority handle these before committing to a design. Video Mesh has its own network and certificate requirements, which your Cisco team should document for you.
What still depends on the Webex cloud and Control Hub
Webex Video Mesh keeps media on premises, but it is not an independent system. The software is installed on an on-premises Cisco UCS server, yet it is registered to the Webex cloud and managed in Control Hub. That registration means the node's configuration, lifecycle and administration still run through Webex, and meetings that exceed local capacity overflow to the cloud. For a buyer whose requirement is that meeting traffic and control stay inside their own network, this dependency is the first thing to map before comparing options.
Before planning a move, ask Cisco to document which account, licensing and telemetry paths remain active in your environment with Video Mesh deployed. Confirm which Control Hub administrators can change node settings, whether the nodes need continuous connectivity to the Webex cloud to keep serving local meetings, what happens to on-premises meetings during a cloud outage, and what usage or diagnostic data the nodes and cluster report back. Get the answers in writing, tied to your contract and the specific Video Mesh version you run, because licensing terms and reporting behavior can change between releases.
A self-hosted Jitsi deployment removes this control plane dependency. The web front end, Prosody, Jicofo and Jitsi Videobridge run inside your infrastructure and are administered with your own tooling, so there is no Control Hub account to keep current. The trade-off is that you become the operator for everything Webex currently handles, including certificates, updates and monitoring. Decide early who owns those duties and whether your current Webex administrators have the skills to take them on.
How self-hosted Jitsi and other open-source options compare on media control
Jitsi Meet keeps media on your infrastructure because the Jitsi Videobridge media routers run on servers you provision in your own data center or cloud account. Signalling runs through the Prosody XMPP server and Jicofo, which you also host, so the conference control plane sits alongside the media. The official Docker setup runs separate web, prosody, jicofo, jvb, jigasi and jibri containers, and the Debian and Ubuntu packages deliver the same components on a host you manage.
- Media path: Videobridges handle audio and video on hosts you control. The default install is already configured for horizontal scaling, so you add bridges as concurrency grows.
- Sizing: 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. Treat these as starting points and validate them against your own peak load.
- Recording and SIP: Jibri records and streams on hosts you run, and Jigasi bridges SIP endpoints, so recordings stay in your storage unless you copy them out.
- Operational duties: You own TLS. The handbook says HTTPS with a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially with mobile clients. You also own UDP 10000 reachability, upgrades and monitoring.
- Identity options: Internal XMPP accounts, JWT tokens, LDAP and Matrix verification are available, set through the .env file.
Before sizing the bridge tier, confirm with your network team how UDP 10000 passes through your firewalls and load balancers, and read the self-hosting guide against your certificate process.
BigBlueButton keeps media and recordings on the server you install, using the bbb-install.sh script on Ubuntu 24.04. Greenlight, its room manager front end, handles room creation and sign-in on the same estate. The project is licensed under LGPL-3.0, and its v4.0.0 release was published on October 14, 2026. Because the platform is built around a single virtual classroom, media control depends on how much of the session load one server can carry and how you place it on your network.
- Install footprint: BigBlueButton 4.0 needs at least 16 GB of memory, 8 CPU cores and 500 GB of disk for recordings. It also needs UDP ports 16384 to 32768 open and 250 Mbit/s of symmetrical bandwidth.
- Session tools: Presentation, whiteboard, polling and breakout rooms run on the same server as the media, so the trust boundary for a session stays inside your environment.
- Scale planning: The published requirements describe a single host. Confirm whether your target version supports multi-node media before you plan capacity beyond one server.
- Front end security: Greenlight and its sign-in configuration sit outside the media path, so you secure, patch and back them up as a separate service.
- Recording storage: The 500 GB figure is a disk requirement for recordings, so retention policy drives the storage you buy and how long recordings remain on your systems.
Check the bandwidth requirement against your busiest scheduled session, not your average day. The install documentation lists the full host and network prerequisites.
Matrix with Element Call moves voice and video into the same self-hosted stack as your messaging. Element Server Suite Community includes Element Call for Matrix-based voice and video alongside Synapse, under the AGPL licence. When you host the whole stack in your own infrastructure, meeting media stays under your control. The trade-off is that a Matrix meeting platform has more moving parts than a single conferencing server, and each part adds an operating duty.
- Shared identity and rooms: Meetings and chat run on one Synapse homeserver, so access to rooms and calls follows the same accounts and policies.
- Additional services: Confirm which media and authorization components your Element Call version requires and where each one runs, since they sit beyond the Synapse server in your design.
- Licence obligations: AGPL terms apply. Review them with counsel before you modify the software or offer it to users outside the organization.
- Paid tier: The Pro edition is a separate paid option. Check the Element pricing page to see which features you would need from it.
- Federation controls: Decide whether outside Matrix servers can join rooms and calls before rollout, because federation determines who can reach your users.
Ask Element for the component list for the exact version you plan to deploy, then map each component to the hosting zone and network segment that your data residency rules require.
Scaling, hardware and support differences side by side
This table sets Webex Video Mesh against a self-hosted Jitsi deployment across control plane, media location, scaling, hardware, recording, identity and support. Read the Video Mesh column as the parts that stay tied to the Webex cloud, and the Jitsi column as the parts you own. Confirm Video Mesh sizing with Cisco documentation before you buy hardware.
| Area | Webex Video Mesh on Cisco UCS | Self-hosted Jitsi |
|---|---|---|
| Control plane | Registered to the Webex cloud and managed in Control Hub; meeting scheduling and policy stay with Webex | Prosody, Jicofo and the web front end run in your environment; you set policy and accounts |
| Where media flows | Meetings stay on premises while capacity lasts, then overflow to the Webex cloud | Media is routed through your videobridges; no overflow to a vendor cloud unless you build one |
| Horizontal scaling | Add nodes under Control Hub; overflow behavior depends on Webex cloud capacity | Add Jitsi Videobridge instances; the default install is already set up for horizontal scaling |
| Sizing reference | Confirm node sizing and supported UCS models with Cisco documentation before purchase | Illustrative guide sizing: 4 CPU and 8 GB for the central server; 4 or 8 CPU with 8 GB RAM per videobridge |
| Hardware ownership | Cisco UCS hardware you buy or lease, plus Webex subscription licenses | Virtual or physical servers you provision; no vendor appliance required |
| Recording | Recording is handled through Webex services; on-premises recording depends on your Webex configuration | Optional Jibri containers record and stream; storage and retention are your decision |
| Identity options | Sign-in through Webex identity and SSO configured in Control Hub | Internal XMPP accounts, JWT tokens, LDAP or Matrix verification, set in the .env file |
| Support model | Cisco and Webex support contracts; Cisco publishes the product documentation | Open-source community plus whatever support contract you buy from a vendor or partner such as DeployOpen |
How to deploy Jitsi videobridges under a media-on-premises rule
This sequence produces a Jitsi deployment whose media paths stay on hosts you control, with HTTPS, token-based access and videobridges you can add as load grows.
Confirm the network path and firewall rules
Before any host is built, your network and security team agrees which sources can reach the Jitsi edge and which media paths stay inside your perimeter. Jitsi needs 80/TCP and 443/TCP for the web application and HTTPS, and 10000/UDP for media through the videobridge. 5349/TCP (TCP fallback) and 3478/UDP (STUN) are optional and should only be opened if your design calls for them. The output is a signed-off rule set and a note on whether any traffic leaves your network, which matters for a media-on-premises requirement. Confirm these rules with your security team before you start, because the ports listed in the vendor quick start are a starting point, not a substitute for your own review.
Prepare Debian 12 or Ubuntu 24.04 hosts
Your platform team provisions the central server and each videobridge host on a supported release: Debian 12 (Bookworm) or newer, or Ubuntu 24.04 or newer. Hosts should have DNS records and time synchronization in place, because certificate issuance and the browser handshake depend on both. Choose the deployment method at this point: the Debian and Ubuntu packages or the official Docker setup. Both are supported, and the Docker setup runs separate web, prosody, jicofo, jvb, jigasi and jibri containers. The output is a patched host on which you can log in and resolve your Jitsi domain name. Confirm the sizing for each role with the Jitsi scalable setup guide and your own load tests rather than relying on the suggested minimums.
Install OpenJDK 17 and the Jitsi packages
The engineer installs OpenJDK 17 on each Jitsi host, as the Debian and Ubuntu quick start requires, and then installs the Jitsi Meet packages for the central server. On the videobridge hosts, the engineer installs the videobridge component so that it can register with the central services. Docker users pull the official images and configure the .env file instead. The check at the end of this step is that each service starts cleanly and that the web application answers on the server name. At this stage the deployment is still reachable only over HTTP or an untrusted certificate, which is why the next step matters.
Obtain a trusted certificate and enable HTTPS
Your PKI or certificate team issues a certificate for the Jitsi domain from a certificate authority your users' devices already trust. The Jitsi handbook states that HTTPS is necessary for audio and video to work, and warns that self-signed certificates cause problems, particularly with mobile clients. The engineer installs the certificate and key on the web server, then confirms that the site loads over HTTPS with no browser warning. Test from a mobile device on the same network as well, because that is where self-signed certificates most often fail. The output is a working HTTPS address that a test user can join from a laptop and a phone.
Configure JWT token authentication and a guest domain
The security engineer sets up JWT token authentication in place of the deprecated secure domain method, which relies on username and password room creation. Tokens are issued by your identity or meeting-scheduling service and checked by Jitsi, so only authorized users can start rooms. The guest path uses a separate anonymous domain, so external participants join without an account and do not share the authenticated domain. Settings are made in the environment or configuration files for the chosen method. The output is a test in which a token-bearing user can create a room and an anonymous guest can join only through the guest domain. Confirm the token claims and signing key handling with your identity team before rollout.
Add videobridges for horizontal scaling
Once the central services work, the engineer adds further videobridge hosts. The Jitsi scalable setup guide says videobridges scale horizontally by adding more, and that the default install is already configured for it, so new bridges register with the central server without a redesign. Each new bridge is placed on a host within your premises, and the engineer confirms that its UDP port is reachable from the participants' network paths. The check is a multi-participant test call in which media is routed through each bridge, and a load test that shows where CPU and bandwidth become the limit. Ask the vendor or your partner to confirm how the bridges are balanced before you commit to a count.
Validate media locality and document the evidence
The team tests the deployment against the media-on-premises rule. Engineers capture traffic and confirm the media endpoints that participants connect to, and they record which components, if any, reach outside your network. They also check that recording, if enabled, writes to storage you control. The output is a dated evidence pack with the configuration, the firewall rules, the certificate chain and the test results, which your compliance team can use in its own assessments. DeployOpen can prepare this evidence, but independent auditors and certification bodies make any formal determination.
What buyers ask before moving off Video Mesh
How much effort does it take to run Jitsi videobridges yourself?
Running Jitsi videobridges is ongoing platform work, not a one-time install. A self-hosted Jitsi deployment is made of a web front end, the Prosody XMPP server, Jicofo, Jitsi Videobridge and optionally Jibri and Jigasi, and each component needs patching, certificate renewal, monitoring and upgrades. The Jitsi scalable setup guide says videobridges scale horizontally by adding more, and the default install is already configured for that. The effort grows with the number of bridges, the number of regions and how often you need recording or SIP access. Ask any implementation partner to write down which components they will operate, which they will hand over, and how upgrades will be tested before they reach production.
Can our own team run the videobridges without outside help?
Yes, if your team already runs Linux servers, DNS, TLS certificates and network firewalls well. The Jitsi Debian and Ubuntu quick start supports Debian 12 or newer and Ubuntu 24.04 or newer, requires OpenJDK 17, and needs ports 80/TCP, 443/TCP and 10000/UDP open, with 5349/TCP and 3478/UDP as optional fallbacks. The harder work is operational: keeping bridges sized as meeting load grows, watching media quality across networks, and handling incidents at the same hours Webex support would have covered you. Teams with those skills often run the platform in-house and bring in outside help for hardening, backup design, upgrades or a retainer for periodic support. A written scope makes the split clear before work starts.
What drives the cost of moving off Video Mesh up or down?
Cost has four main parts: server hardware or cloud instances, bandwidth, staff time and support. 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, so the number of bridges and their size set most of the hardware line. Bandwidth depends on how many participants are in video at once and whether you carry traffic between sites. Staff time is the largest recurring item if you run everything yourself. Retainers for upgrades, testing and support are optional and recur. Existing Cisco UCS hardware may lower the hardware line, but only if it fits the Jitsi sizing and you accept the extra operations. Ask every quote to separate one-time setup from monthly operations and to state the assumed concurrent participant count.
What happens to Control Hub-managed room devices after a Jitsi move?
Room devices that register to Webex Control Hub will not move with Video Mesh. Video Mesh is registered to the Webex cloud and managed in Control Hub, so any device, calendar integration or policy that depends on Control Hub stops working when you leave Webex. Jitsi does not provide a direct equivalent of Webex's room device ecosystem, and the Jitsi Docker guide covers SIP access through Jigasi rather than vendor-managed endpoints. Make an inventory of every room system, its certification, its sign-in method and its scheduling path before you commit. Some rooms may be replaced with browser-based joins or SIP endpoints, and others may keep their Webex service until the contract ends. Confirm each device's replacement path with its vendor and with the platform team.
How long does a pilot of self-hosted Jitsi usually take?
The length of a pilot depends on scope, not on a fixed period this page can give. A useful pilot covers one or two bridges in a staging network, one real meeting pattern, your identity and authentication choice, recording needs and a test of the failure path. The Jitsi handbook says HTTPS with a proper domain certificate is necessary, so DNS and certificate issuance must be ready early. Pilot length also depends on how quickly your network team can open the required ports and how many room systems must be tested. Scope and timelines are agreed in writing before work starts, so ask for a fixed-scope proposal that lists the test cases, the exit criteria and who signs off.
Is HTTPS and certificate management required for self-hosted Jitsi?
Yes. The Jitsi self-hosting guide states that HTTPS is necessary for multimedia to work, and the Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video. The handbook warns that self-signed certificates cause problems, especially with mobile clients, so plan a public or internal certificate authority that all clients trust. You will need to renew certificates on a schedule, automate renewal where possible and monitor expiry, because an expired certificate stops meetings. Treat the certificate process as a recurring operational task with a named owner. Confirm with your security team how keys are generated, stored and rotated before the pilot begins.
Does moving off Video Mesh change what our security team must evidence?
It shifts evidence from the Webex cloud to systems you run. Webex relies on its own cloud controls and a Video Mesh node you install and register, while a self-hosted Jitsi stack puts access control, logging, patching and network segmentation in your hands. The Jitsi Docker guide lists authentication options including internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid mode, and the Jitsi handbook recommends JWT token authentication over the deprecated secure domain method. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Ask your assessor which evidence they will expect before the design is frozen.
Evidence that shows media stays where policy requires
A policy claim that media stays on premises is only as good as the records behind it. The cards below list the artifacts that show where media flows, what the platform can reach, how users authenticate and how the system is kept current. DeployOpen prepares this evidence, but independent auditors decide whether it satisfies a specific requirement.
Network flow diagrams
Diagrams should show every path a call takes: browser to the web front end, signaling to Prosody and Jicofo, and media from clients to each Jitsi Videobridge. Mark which segments sit inside your network and which, if any, leave it. For Video Mesh, the equivalent question is which Webex cloud connections remain open during a meeting. Ask the reviewer to trace one meeting from start to end on the diagram.
Outbound endpoint allowlist
List every destination the Jitsi servers may reach, including update sources, container registries, DNS, time sources and any SIP or recording targets. Compare that list with the Webex side, where Video Mesh nodes must stay registered to the Webex cloud and Control Hub. Ports such as 10000/UDP for media and 443/TCP for HTTPS should appear with their direction and purpose. Firewall rule exports are stronger evidence than a summary written by hand.
Environment and component configuration
Keep versioned copies of the .env file and the component settings for the web front end, Prosody, Jicofo and Jitsi Videobridge. Redact secrets before sharing, but keep the keys that govern where media and recordings go, such as the Jibri output path and any disabled external services. Store these files in a change-controlled repository so a reviewer can see what changed and when. Confirm which settings your team must review after each upgrade.
Authentication configuration
Document how users and guests join rooms. The Docker setup supports internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid mode, all set through .env. Jitsi's handbook deprecates the older secure domain method for new installations and recommends JWT token authentication with a separate anonymous domain for guests. Record the chosen method, who can issue tokens and how that setting was tested.
Maintenance and upgrade records
Keep a dated log of deployed Jitsi Meet builds, operating system patches, certificate renewals and videobridge changes. Jitsi publishes stable releases tagged by build number, and the Docker setup runs rootless with read-only filesystems from stable-11146 onward, so note any deviation from that baseline. Records of restores and test calls show that the platform is maintained, not just installed. Ask your reviewer which retention period applies to these logs.
When Video Mesh is still the right choice
Keeping Video Mesh is the right call when your meetings depend on Webex room devices and Control Hub policy that you cannot easily replace. If most of your meeting rooms run Webex-registered endpoints, and your admins manage calling, device provisioning, meeting templates and security settings from Control Hub, moving media to Jitsi also moves a set of controls that have no direct open-source equivalent. Jitsi covers browser and desktop meetings well, but room systems, SIP-based room integration through Jigasi and centralized policy will each need their own design and testing. Before deciding, list every room device model, every Control Hub policy that applies to meetings and every integration that calls Webex APIs, then ask Cisco which of these remain supported if Video Mesh is retained as a hybrid component.
The licensing position also matters. If your Webex subscription is already paid for, Video Mesh servers are in place, and the renewal date is far off, a near-term migration may add cost without removing risk. Confirm with your Cisco account team the current Video Mesh licensing model, whether node capacity is tied to your subscription, what support terms cover on-premises nodes, and whether they still require registration to the Webex cloud. Ask them to put the answers in writing, because that registration dependency is the main difference from a Jitsi deployment that you operate without an outside control plane.
The third case is staffing. Running Jitsi means owning the web front end, Prosody, Jicofo, Jitsi Videobridge and, if used, Jibri and Jigasi, along with HTTPS certificates, patching, monitoring and capacity planning. If your platform or network team cannot commit ongoing time to this, or you have no one who can respond to a media quality incident at short notice, a managed Jitsi service or staying on Video Mesh may be the safer option for now. Ask your operations team to estimate, in their own terms, the hours per month they can give to videobridge upkeep and who covers it during holidays and incidents. If that answer is uncertain, a fixed-scope implementation partner can document the operating model before you commit.
How DeployOpen deploys Jitsi under an on-premises media constraint
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the media path your on-premises requirement depends on. We start from the written scope, so the cloud dependencies that stay with Webex and the parts you move to Jitsi are agreed before any build work begins.
How we scope
- Inventory which Video Mesh functions, Control Hub policies and cloud-side services your meetings currently use today.
- Agree in writing which meeting types, room systems and user groups move to Jitsi and which remain on Webex.
- Record network, certificate and firewall requirements for the media ports and HTTPS domain Jitsi needs.
- Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before work starts.
How we build
- Deploy the web front end, Prosody, Jicofo and Jitsi Videobridge in your data center or cloud account.
- Size videobridge count and hardware against your measured concurrent meeting load, then test horizontal scaling.
- Configure authentication, such as JWT tokens with a separate guest domain, and test it against your identity sources.
- Run security testing of the deployed meeting service, including its web and API surfaces, before handover.
How we hand over
- Document the architecture, network flows, configuration keys and certificate renewal steps for your operations team.
- Provide runbooks for adding videobridges, backing up configuration and upgrading Jitsi releases.
- Deliver compliance-readiness evidence, such as configuration records and test results, for your independent auditors to review.
- Walk your staff through operations and confirm they can run the platform without DeployOpen present.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Jitsi release upgrades, certificate monitoring and capacity reviews as your meeting volume changes.
- Ask any provider to confirm in writing which operations tasks sit with your team and which sit with the retainer.
- Confirm with your Webex account team which Video Mesh and Control Hub dependencies you need to keep during the transition.
