Which self-hosted Webex alternative works on an air-gapped network?
On a network with no route to the internet, Webex Video Mesh cannot be the answer, because each Video Mesh node must stay registered to the Webex cloud and is managed from Control Hub. Self-hosted Jitsi Meet or Matrix with Element Call can both be deployed fully offline, with the media, signaling, accounts and certificates all kept inside the enclave. The constraint is the one that matters most: every component the meeting service needs, including container images or packages, TLS certificates, time sources and authentication, has to be available inside the isolated boundary. Anything that phones home at startup or during a call breaks the design.
Jitsi is the shorter path for ad hoc and scheduled meetings. Its self-hosting guide states that HTTPS is necessary for multimedia to work, and the Jitsi handbook warns that self-signed certificates cause problems, especially with mobile clients. For an enclave that means running an internal certificate authority that clients already trust, and confirming that your devices accept it before go-live. The component set is the web front end, Prosody, Jicofo and Jitsi Videobridge, with Jibri and Jigasi added only if you need recording or SIP room systems. Confirm with your Jitsi support contact or the handbook which optional containers or packages you must mirror into the enclave.
Matrix with Element Call fits organizations that also need persistent chat, but it brings more to plan: a Synapse homeserver, PostgreSQL, and the Element Call stack, which Element documents separately from the Community edition. Verify with Element which components of Element Server Suite Community you can run without outbound access, and whether licensing terms require any check-in. In both cases, plan an offline update path, since the Synapse upgrade notes warn that rolling back can be difficult because of database schema changes. Decide early whether the enclave will federate at all; with an empty federation domain whitelist, federation is disabled.
What an air-gapped video deployment has to satisfy
An air-gapped video service fails at the first hidden dependency, so the requirements below are the ones to verify before any platform is chosen. Each card names a dependency that can block a disconnected deployment and what to confirm about it in your own environment.
No cloud registration or callbacks
Video Mesh is software on an on-premises Cisco UCS server, but it stays registered to the Webex cloud and is managed in Control Hub. That registration is the blocking point for a disconnected network, because the node cannot be fully operated without the cloud service. For a self-hosted option, check that the platform starts, authenticates users and records meetings with no outbound licensing or telemetry call, and test that with the egress path closed.
Verified packages and container images
Every package, container image and rule set crosses the boundary on media you control, so each one needs a recorded source, a checksum or signature check and a version record. NERC CIP-013-2 expects supply chain procurement to address verification of software integrity and authenticity, and that is the control this step supports. Jitsi's Docker setup runs separate web, prosody, jicofo, jvb, jigasi and jibri containers, so the mirror must include every one of them, and the upgrade path needs the same checks.
Internal CA certificates for HTTPS
Jitsi's handbook states that HTTPS is necessary for multimedia to work and warns that self-signed certificates cause problems, especially with mobile clients. In a closed network this means running an internal certificate authority, issuing a certificate for the meeting domain and distributing the CA root to every managed client and browser. Confirm the CA chain is trusted on the devices users actually join from before cutover.
Bandwidth and UDP port planning
Media runs over UDP, so the firewall rules between user segments and the video servers must allow the required ports. The Jitsi quick start needs 10000/UDP open, with 5349/TCP for TCP fallback and 3478/UDP for STUN optional. BigBlueButton 4.0 needs UDP ports 16384 to 32768 and 250 Mbit/s symmetrical bandwidth. Confirm these paths on the internal network, not only on the internet edge.
Server sizing and recording storage
BigBlueButton 4.0 requires at least 16 GB of memory, 8 CPU cores and 500 GB of disk for recordings. Jitsi's scalable guide suggests a 4 CPU, 8 GB central server and 4 or 8 CPU with 8 GB RAM for each videobridge, and that bridges scale horizontally. Because no external storage or cloud service is available, plan local disk for recordings and their retention, and size the hardware for peak concurrent meetings rather than average use.
Internal identity and directory integration
A disconnected site cannot rely on a hosted sign-in service, so room access has to come from a directory inside the network. Jitsi's Docker guide supports internal XMPP accounts, JWT tokens, LDAP and Matrix user verification, configured in the .env file. Decide which of these matches your directory, and confirm that the JWT signing key and the anonymous guest domain are managed inside the perimeter.
Which options meet the disconnected constraint and what each one costs you
This table compares Webex Video Mesh, Jitsi Meet, BigBlueButton and Matrix with Synapse and Element Call on how each behaves without internet access, what must cross the boundary and what it asks of your operations team. Read the rows as a checklist: only the self-hosted options can run disconnected, and the cost differences come mainly from staff time and hardware.
| Option | Disconnected behavior | Carried across the boundary and operating trade-offs |
|---|---|---|
| Webex Video Mesh | Not a disconnected option. Nodes stay registered to the Webex cloud and are managed in Control Hub. | Media stays on premises, but the registration, management and overflow to cloud depend on the Webex cloud. Confirm the exact dependencies with Cisco before scoping. |
| Jitsi Meet (Docker or Debian packages) | Can run with no internet route once images or packages are mirrored in advance. Confirm which external calls the web app and any optional features make in your build. | Carry Docker images or Debian and Ubuntu packages, and the OpenJDK 17 dependency, through a reviewed transfer. Requires HTTPS with a proper domain certificate, so plan an internal CA. Needs UDP 10000 open inside the network. |
| BigBlueButton | Can run on a disconnected network if the install packages and dependencies are staged ahead of time. Confirm the install path with the BigBlueButton install documentation. | Minimum 16 GB memory, 8 CPU cores and 500 GB disk for recordings on Ubuntu 24.04, plus UDP 16384 to 32768 and 250 Mbit/s symmetrical bandwidth. Plan the offline repository and storage growth for recordings. |
| Matrix with Synapse and Element Call | Can run disconnected, but federation must be turned off or restricted to internal domains. Confirm each component's external calls before launch. | Synapse production use needs PostgreSQL 14 or newer and Python 3.10 or newer. Scaled deployments add Redis for worker replication. Element Call also needs its LiveKit media and authorization services, which must be mirrored too. |
| Element Server Suite licensing | Community edition is AGPL and includes Element Call with Synapse. Pro and Sovereign editions are paid, with Sovereign aimed at air-gapped deployments. | Ask Element for the written terms of Pro and Sovereign, including support and update delivery to an isolated network, before relying on either edition. |
| Patch and update flow | Every update must be imported from media you have checked, whatever platform you choose. | Verify software integrity and authenticity of each package before it crosses the boundary, as CIP-013-2 expects for supply chain controls. Keep rollback steps, since Synapse warns rollbacks can be hard after schema changes. |
How to deploy Jitsi Meet on a disconnected network
This sequence takes a Jitsi Meet deployment from packages staged outside the boundary to a tested call between clients on an isolated segment, with every component installed from verified, internally hosted sources.
Build an internal mirror of packages and images
Your platform team builds the package and container sources on a connected staging network, then transfers them across the boundary. Stage the Debian 12 or Ubuntu 24.04 operating system packages, OpenJDK 17, nginx or Apache, and the Jitsi packages or Docker images for web, prosody, jicofo, jvb and, if you need them, jibri and jigasi. Host them in an internal apt repository and container registry. Done when a clean build host can install every dependency without reaching the internet and each artifact has a recorded checksum.
Install Jitsi from the internal sources
Your platform engineers install Jitsi either from the Debian or Ubuntu packages or from the official Docker setup, pointing the package sources or image references at the internal mirror. The Docker option runs separate web, prosody, jicofo and jvb containers, and since stable-11146 those containers run rootless with read-only filesystems. Confirm the Jitsi version against the release you validated in staging. Done when every service starts and the web front end answers on the internal host name.
Issue HTTPS certificates from an internal CA
Your PKI team issues a certificate for the Jitsi domain from your internal certificate authority and installs it on the web front end. The Jitsi handbook states that HTTPS is necessary for audio and video to work and warns that self-signed certificates cause problems, especially with mobile clients. Distribute the internal root certificate to every managed client and confirm that the trust chain validates on each browser you support. Done when the browser shows a valid lock with no warnings on a client on the isolated segment.
Configure JWT or LDAP authentication
Your identity team sets the authentication mode in the .env file. The Jitsi handbook marks the older secure domain method as deprecated for new installations and recommends JWT token authentication, with a separate anonymous domain for guests. The Docker guide also lists LDAP as an option, so confirm which directory your environment uses before choosing. Store the JWT signing secret in your secrets manager, not in the file itself. Done when a user with a valid token can create a room and an unauthenticated guest is limited to the anonymous domain.
Size videobridges and scale horizontally
Your platform engineers size the central server and add videobridges according to expected concurrent participants. 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, and notes that the default install is already configured for horizontal scaling, so new bridges join by configuration. Validate sizing with a load test on the isolated network rather than trusting the minimum figures. Done when load testing shows acceptable media quality at your target participant count.
Lock down ports and restrict media paths
Your network team allows only the required ports on the segment and blocks everything else. Keep 443/TCP for the web and signaling path and open 10000/UDP for media to the bridges. Add 5349/TCP for TCP fallback only if clients need it, and 3478/UDP for STUN only if your design uses it. Block outbound internet access from the Jitsi hosts and confirm that no service attempts a public lookup. Done when a port scan from the client segment shows only the approved services and the hosts cannot reach external addresses.
Add Jibri and Jigasi only if needed
Jibri (recording and streaming) and Jigasi (SIP gateway) are optional add-ons. Deploy them only if your use cases require recordings, live streams or SIP room systems, since each adds components to patch and monitor. Jibri requires its own host capacity and storage planning, and Jigasi requires a SIP trunk or gateway inside your boundary. Done when each optional component you chose passes a test session, or when you have documented that you are not deploying it.
Test a call and set the update path
Your operations team runs a test call with clients on the isolated segment, covering screen sharing, audio, video and a multi-party room across at least two videobridges. Record the results and the configuration baseline. Define the update path: new packages and images are validated in a connected staging environment, checksummed, reviewed under your supply chain controls, and then carried across the boundary to the internal mirror. Done when the test call completes and the update procedure is written down and signed off by the owner of the boundary.
When Matrix with Element Call fits better than Jitsi
Choose Matrix with Element Call only when the air-gapped network also needs persistent messaging with controlled federation. Jitsi covers meetings well, but it does not store chat history as a messaging system, so a team that needs rooms, history and offline-capable conversations alongside video is taking on a second product either way. Matrix combines both, but it is a larger system to run. Synapse, the most widely documented homeserver, is developed by Element and is licensed under AGPL-3.0 (with commercial licenses also available from Element). Plan for PostgreSQL 14 or newer, which Synapse 1.143.0 and later require, and Python 3.10 or newer for 1.142.0 and later. Confirm the versions your chosen Synapse release needs before you stage the offline packages.
Federation is the control that most changes the security posture. Set federation_domain_whitelist in the Synapse configuration to an empty list if the network must not talk to any other homeserver, or to a fixed list of approved domains if specific partners need access. The configuration manual also recommends firewalling the federation listener, which defaults to port 8448, so the setting and the network rule should be reviewed together. Synapse scales with workers that connect through Redis, which relays replication between processes, so a larger deployment adds Redis to the set of components to patch, back up and keep inside the boundary.
Element Call is not a standalone feature you switch on. It depends on additional services, including a LiveKit SFU for media and an authorization service, and each one must be deployed, monitored and upgraded inside the enclave. Treat that as a separate build item in the scope. Also plan rollbacks carefully: the Synapse upgrade notes warn that rolling back can be difficult because of database schema changes between releases, so take a verified database backup before every upgrade. Element Server Suite has a free AGPL Community edition, while the Pro and Sovereign editions are the paid options that Element offers for air-gapped deployments. Confirm the current scope of each edition on the Element pricing page before you assume offline support is included.
Evidence an assessor will ask for on an isolated network
An assessor reviewing a disconnected video deployment will want to see what crossed the boundary, how the traffic is locked down, and how the system has changed over time. The cards below cover the artifacts that answer those questions for a Jitsi or Matrix and Element Call deployment. DeployOpen prepares this evidence, but auditors and certification bodies draw the conclusions.
Inventory of carried images and packages
Every container image, Debian or Ubuntu package and Synapse or Jitsi release brought across the boundary should appear in one inventory with its source, version and digest. Record who imported each item, when, and which verification step passed, such as hash comparison or signature checks against the publisher's keys. Ask the implementation partner to show this list before the first import, because a missing entry is hard to reconstruct later.
Signature and hash verification records
For each transfer batch, keep the checksum output and the signature verification result, stored with the media that carried it. Assessors use these records to confirm that the software running inside the enclave matches what the publisher released. Pair them with the supply chain control in NERC CIP-013-2 if the platform supports a bulk electric system, since that control asks how software integrity and authenticity are verified.
HTTPS certificate chain from the internal CA
Jitsi's handbook says HTTPS with a proper domain certificate is necessary for working audio and video, and warns that self-signed certificates cause problems, especially on mobile clients. Keep the full chain from the internal certificate authority, the root and intermediate certificates, the expiry dates, and the renewal procedure. Confirm that clients on the isolated network trust the internal root through managed devices rather than manual exceptions.
Network diagrams showing no outbound routes
Diagrams should show every segment of the video platform, the firewall rules, and the absence of default routes to the internet or to any Webex or Zoom cloud endpoint. Mark the ports in use, such as 443/TCP and 10000/UDP for Jitsi, and document any intentional path, such as a one-way update transfer station. An assessor will test these diagrams against the firewall configuration, so confirm they were produced from the live rule set.
Authentication configuration and access logs
Retain the .env settings that choose the authentication method, such as JWT tokens, LDAP or the Matrix user verification mode, together with the configuration files that set authentication for Synapse. Access logs from the web, Prosody and Synapse services should show who created rooms, who signed in and from which address. Ask how long logs are kept on the local host and where they are copied, because a disconnected system still needs a retention plan.
Upgrade and rollback records
Each upgrade should have a change record listing the old and new versions, the test results, the backup taken beforehand, and the rollback procedure. Synapse's upgrade notes warn that rolling back can be difficult because database schema changes between releases, so the backup and rollback plan must be specific to the release being installed. Ask the implementation partner for these records for every change, including the ones made during the first deployment.
Questions buyers ask before choosing an air-gapped video platform
Can Webex Video Mesh run with no cloud connection at all?
Video Mesh is installed on an on-premises Cisco UCS server, but it is registered to the Webex cloud and managed in Control Hub, so it depends on that cloud relationship for registration and management. Media can stay local when on-premises capacity is available, but meetings can overflow to the cloud when local capacity runs out. Confirm with Cisco, in writing, whether any supported Video Mesh configuration operates with no cloud connection, what happens to registration and licensing when the link is cut, and how software updates reach the node. Read the Webex Video Mesh deployment guide before you ask.
What cost components drive a self-hosted air-gapped video deployment?
Costs fall into a few components: server hardware or virtual machines, bandwidth inside your network, staff time for operations and upgrades, and any paid software editions. Hardware and storage are mostly one-time, while staff time, patch intake, certificate renewal and backup testing recur. Bandwidth needs depend on participant count and layout, and recording storage grows with usage. If you choose Matrix with Element Call, Element Server Suite Community is free under AGPL, while the Pro and Sovereign editions are paid. Ask any quote to separate hardware, licensing, implementation and ongoing support so you can compare it with your current Webex contract.
How long does an air-gapped implementation take?
Duration depends on the written scope: the number of sites, whether recording and SIP room systems are included, the authentication design, and how quickly your change process approves hardware and package transfers. No timeline in this page is a fixed figure. Ask for a fixed-scope plan with milestones, dependencies on your teams, and acceptance tests for each component. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote is the place to confirm dates.
Can our own team run a self-hosted video platform after handover?
A team that already operates Linux servers, container runtimes, reverse proxies and certificate management can run Jitsi or BigBlueButton with a defined runbook. Matrix with Element Call adds more components, including the Synapse database, Redis for workers and a LiveKit media layer, so it needs staff comfortable with database upgrades. Jitsi's own guidance states that HTTPS with a proper domain certificate is necessary for audio and video, which makes certificate operations a standing task. Assess your skills against each component, then decide whether to keep operations in-house or retain support for upgrades and testing.
What does the work need from our network, certificate and identity teams?
Plan for four dependencies before the work starts:
- A controlled path for transferring installers, container images and operating system packages across the isolation boundary, with integrity checks on each package.
- Internal DNS and a certificate authority that issues trusted certificates for the video domain, because self-signed certificates cause problems, especially on mobile clients.
- Identity integration with your directory or single sign-on provider, such as OpenID Connect, SAML or LDAP, depending on the platform.
- Firewall rules for the UDP media ports and TCP fallback ports the chosen platform requires.
The mirror and transfer process should be agreed with your security team so that change records show what entered the network.
How do we verify software entering an air-gapped network?
Each package, image and update that crosses the boundary should be hashed, signed where the publisher provides signatures, scanned, and recorded in your change system. NERC CIP-013-2 is one example of a control that asks utilities to address verification of software integrity and authenticity for vendor software and patches, so the same practice applies beyond the energy sector. Keep a dated inventory of versions in use and check each upstream release notes before import. For Synapse, upgrade notes warn that rolling back can be difficult because of schema changes, so test restores before each update.
Does the platform choice change what we must keep for audit and recordings?
Yes. Recording formats and storage location differ by platform, so retention rules must be defined before cutover. Jitsi recording through Jibri and BigBlueButton recordings each need dedicated storage sized to your retention period, and BigBlueButton's documentation lists 500 GB of disk for recordings as a minimum for its 4.0 install. Ask your compliance lead which records must be kept, who may access them, and how deletion is evidenced. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or attestation.
What to confirm with vendors before you commit
Start with Webex, because the central question for this page is whether any part of the Video Mesh design can run without a live connection to the Webex cloud. Video Mesh is registered to the cloud and managed in Control Hub, and the supplied material does not establish whether Cisco offers any offline or disconnected licensing for it. Ask your Cisco account team in writing whether a Video Mesh node can keep running, and keep licensing valid, when its registration cannot reach the cloud for an extended period. Ask for the answer in the terms of your subscription, and ask what happens to meeting capacity and licence compliance during that period. Confirm the answer against the Video Mesh deployment guide before you rely on it in a risk assessment.
For Element, confirm the current feature scope of the Community, Pro and Sovereign editions before you select a Matrix path. The supplied information describes the Sovereign edition as intended for air-gapped deployments, but does not list which components, support terms or update channels it includes. Request a written scope comparison from Element, including whether Element Call, its LiveKit dependency and the authorization service are covered, and how offline licence activation works. Use the Element pricing page as the starting point, then ask for the details that the public page does not give. For Jitsi and BigBlueButton, ask how each project publishes releases, how long each release line is supported, and how you obtain signed packages or container images that you can verify inside an isolated network. Check the release notes and the project repositories for the current cadence, and ask your integrator how signature and checksum verification will be carried out at the import step, which is the control that NERC CIP-013-2 expects you to address for software crossing an isolated boundary.
Finally, confirm the Synapse and PostgreSQL versions your upgrade path needs before you build the offline mirror. Synapse publishes upgrade notes that list minimum Python and PostgreSQL versions for each release, and it drops support for versions that reach upstream end of life, so the database and runtime you install today may need replacing during the life of the system. Read the Synapse upgrade notes for every release between your starting version and your target, and record the minimum PostgreSQL and Python versions for each. Because rolling back a Synapse upgrade can be difficult, ask your team to take a tested database backup and a rehearsal upgrade in a non-production environment before each change.
How DeployOpen deploys video conferencing under an air-gapped constraint
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source meeting platforms inside your own networks, including air-gapped ones. For an air-gapped Webex replacement, we start by confirming which parts of the stack must run with no outbound connection and which can stay local.
How we scope
- We confirm which meeting features must work with no connection to any cloud service, including SIP room systems.
- We agree a fixed scope in writing covering platforms, sizing, authentication, recordings and deliverables before work starts.
- We identify the HTTPS certificate source and internal DNS names that the meeting platform will need from day one.
How we build
- We prepare an offline installation bundle of packages, container images and dependencies, and verify it before it crosses the boundary.
- We configure the chosen platform, its authentication method and its media ports to match the approved network design.
- We test join flows, screen sharing, recording and capacity on the isolated network, not on a connected test environment.
How we hand over
- We deliver runbooks for installation, upgrades from offline media, backups and restore, and certificate renewal.
- We document the update and integrity-check procedure for every package carried across the isolated boundary.
- We provide evidence of configuration and testing that your internal assessors or independent auditors can review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover scheduled offline update cycles, security patch review and capacity checks as usage grows.
- Before any quote, ask for the written scope, the named deliverables and the support terms your environment requires.
