Can a Zoom alternative run on an air-gapped network?
Yes, with planning. Jitsi Meet and BigBlueButton can both run fully disconnected from the internet, but only if you plan for certificates, TURN, ports and offline updates before the first install. Neither product needs a vendor cloud to start meetings, so the real work is in the surrounding infrastructure. The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for audio and video to work, and it warns that self-signed certificates cause problems, especially with mobile clients. Inside an isolated boundary, that means running your own certificate authority and distributing its root to every client device. BigBlueButton also needs a valid hostname for SSL, and its install docs recommend a TURN server for users behind restrictive firewalls. Confirm the port list with each project's current documentation, since the Jitsi quick start and the BigBlueButton install docs name different sets of ports for different roles.
Zoom Node does not meet a strict disconnected requirement. It is deployed on your premises, but the product page describes it as managed from the Zoom cloud, with hosting modules such as Zoom Meetings Hybrid and Meeting Connector. If your policy forbids any management path that leaves the boundary, that dependency alone decides the question, regardless of where the media traffic flows. Ask Zoom directly which management, licensing and update functions require outbound connectivity, and get the answer in writing before you rely on it for an isolated network. For offline updates, both platforms need a documented procedure. Jitsi packages and Docker images must be mirrored into your internal repository or registry, and BigBlueButton 4.0 installs on Ubuntu 24.04 with bbb-install.sh, which expects packages from the internet by default. Plan a repeatable transfer process with checksum and signature verification at the boundary, and check each release's notes for dependencies that change. Choose BigBlueButton for structured training, classes and presenter-led sessions that need a whiteboard and breakout rooms, and choose Jitsi Meet for ad hoc team meetings where lighter components and quick joining matter more.
What an air-gapped video deployment has to meet
A fully disconnected Jitsi or BigBlueButton deployment has no Zoom cloud to fall back on, so every dependency has to be built, reachable or carried in by hand. The five requirements below set the network, certificate, identity and update decisions that shape the rest of the project.
Valid HTTPS certificate for the domain
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 with mobile clients. In an isolated network, your internal certificate authority must issue the certificate, and every client device must trust that authority before the first meeting. BigBlueButton also needs a valid hostname for SSL. Confirm how certificates will be issued, renewed and distributed to managed devices, since renewal is the step most often forgotten.
Reachable ports on the internal network
Jitsi needs 80 and 443 over TCP and 10000 over UDP. BigBlueButton needs 80 and 443 over TCP and UDP 16384 to 32768 reachable by its users. Both platforms depend on those UDP ranges for media, so a firewall rule that allows only TCP will produce meetings with no audio or video. Map every port to a segment and rule, and test from a client on each user subnet, not only from the server's own network.
TURN server for restrictive firewalls
Users behind strict firewalls or proxies may not be able to open direct UDP paths to the media server. A TURN relay gives them a fallback path over TCP or TLS. Jitsi lists 5349 over TCP as its TCP fallback port, and the BigBlueButton install docs recommend a TURN server for the same reason. Because the relay sits inside your network, it must be deployed, certificated and monitored like any other service. Confirm which users, such as remote staff on restricted links, will depend on it.
No dependency on external services
A disconnected deployment fails silently if a component reaches out to the internet. Check fonts, scripts, avatars, map or analytics calls, and any default identity provider in the web front end. Plan the identity source as well: Jitsi's Docker guide supports internal XMPP accounts, JWT tokens and LDAP, and Greenlight can use OpenID Connect. Document every outbound call that the platform attempts, then confirm each one is served from inside the network or removed.
Offline path for updates with integrity checks
Updates must be carried across the boundary as tested, signed or checksummed artifacts, not pulled by the servers. Confirm how each container image, Debian or Ubuntu package and BigBlueButton release will be fetched, scanned and verified before it enters the enclave, and keep a record of what was approved. Plan for a clean rebuild path too: BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so migrations start from a new server. Ask your standards owner which supply chain control applies to vendor software and patches.
Which open-source option fits a disconnected network
This table compares Jitsi Meet, BigBlueButton and Element Call on Matrix for fully disconnected networks, covering how each runs without internet access, its server footprint, recording and authentication, and its trade-offs. Read each row against your own network rules, and treat Element's air-gapped terms as something to confirm with Element before you choose it.
| Criterion | Jitsi Meet | BigBlueButton 4.0 | Element Call with Element Server Suite |
|---|---|---|---|
| Running without internet access | Self-hosted from Docker containers or Debian and Ubuntu packages. You must mirror those packages and images into the enclave and keep HTTPS on a domain certificate your internal CA issues. | Installed with bbb-install.sh on Ubuntu 24.04. Plan an offline package mirror, and confirm how the Docker sandbox for LibreOffice conversion behaves with no registry access. | Air-gapped deployment is described as part of the Sovereign edition, not the free Community edition. Confirm current terms and delivery method with Element before planning. |
| Server footprint | Central server plus one or more videobridges. The scalable setup guide suggests 4 CPUs and 8 GB for the central server, and 4 or 8 CPUs with 8 GB RAM per videobridge. | At least 16 GB RAM with swap, 8 CPU cores with high single-thread performance, 500 GB disk with recording (50 GB without), and 250 Mbit/s symmetrical bandwidth. | Depends on the Synapse, Element Call and supporting services you deploy. Ask Element for its sizing guidance for your user count and call load. |
| Recording | Jibri records or streams from a dedicated instance, one recording per Jibri instance. Plan storage and extra capacity for each Jibri host. | Recording is built in, and the 500 GB disk figure above assumes recordings are kept on the server. Plan archiving to internal storage. | Confirm with Element whether call recording is included in the Sovereign edition and how it is stored. |
| Authentication | Internal XMPP accounts, JWT tokens, LDAP, Matrix user verification or a hybrid mode, set in the .env file. The handbook deprecates the older secure domain method for new installs. | Greenlight v3 supports OpenID Connect through environment variables. The docs suggest Keycloak for SAML and other login methods, which you must host inside the enclave. | Identity comes from the Matrix homeserver. Confirm how it integrates with your directory and whether it supports your authentication policy. |
| Network and certificates | Ports 80 and 443 over TCP and 10000 over UDP are needed, with 5349 TCP and 3478 UDP optional. Self-signed certificates cause problems, especially on mobile clients. | TCP 80 and 443, UDP 16384 to 32768, a valid hostname for SSL, and a TURN server recommended for users behind restrictive firewalls. | Confirm the TURN, certificate and federation requirements in the Element documentation for an isolated network. |
| Main trade-off | Lightest footprint and the most flexible deployment, but the operator owns scaling, recording and integration work. | Strongest fit for training and structured sessions, with the heaviest hardware and the clean-install requirement for 4.0. | Suits organizations already standardizing on Matrix chat, but it is a commercial edition question, so confirm cost and terms before design work. |
| Choose it when | Meetings are the main need, your team can run containers, and you can host a certificate authority inside the enclave. | Classes, webinars or presenter-led sessions need whiteboard, polls and breakout rooms, and you can dedicate a server. | You need Matrix-based chat and calls together and have confirmed Sovereign edition terms for an air-gapped deployment. |
Where Zoom Node stops short of a disconnected network
Zoom Node is on premises, but it is not independent of Zoom. The product page describes it as deployed on customer premises and managed from the Zoom cloud, with hosting modules such as Zoom Meetings Hybrid, Recording Hybrid, Meeting Connector and Recording Connector. Media and recording processing for meetings hosted on the appliance can stay on the local network, but the control plane that configures, monitors and updates the node is hosted by Zoom. For a network with no outbound path, that is the first point to test rather than assume.
Before you scope a Zoom Node deployment for a disconnected site, separate three flows. Local meeting media and local recording storage can stay inside the perimeter. Management, licensing and update traffic to the Zoom cloud is the part that depends on an outbound connection. Anything that requires a Zoom account, a web portal or a cloud-side license check will fail or stall without that path. Ask Zoom in writing which of these functions still work when the node has no route to the internet, how licenses are validated and renewed, whether the vendor can deliver updates by offline media, and who signs and verifies those packages.
Those answers feed directly into your supply chain and boundary controls. NERC CIP-013-2, the supply chain risk management standard, expects procurement to address verification of software integrity and authenticity for vendor software and patches, so an offline update path needs a documented verification step. If the vendor's update model assumes cloud delivery, your team will own that gap. Request the written answers before purchase, and compare them with the offline installation and update paths of Jitsi Meet and BigBlueButton, where your own team controls the versions that enter the network.
How to deploy and update Jitsi or BigBlueButton offline
This sequence takes a fully disconnected network from an empty server to a tested video meeting service, and sets up a repeatable way to carry each update across the isolation boundary.
Confirm target OS and hardware
The network architect and the platform team confirm the operating system, hardware and network path before any software moves. For BigBlueButton 4.0, the install documentation calls for Ubuntu 24.04 64-bit, at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. For Jitsi, the Debian and Ubuntu quick start supports Debian 12 or newer and Ubuntu 24.04 or newer and requires OpenJDK 17. Confirm that the internal network allows TCP 80 and 443, UDP 16384 to 32768 for BigBlueButton or UDP 10000 for Jitsi. Done when the team has a written host specification signed off by the owner of the network.
Build the offline bundle on a staging host
On a connected staging host that matches the target OS, the platform team downloads the operating system packages, the Jitsi or BigBlueButton packages, and the container images, including the images for LibreOffice conversion and any TURN server. Keep a manifest listing every package and image with its version and digest. The same pattern applies to other disconnected platforms: the Kubernetes documentation shows how control plane images can be pulled in advance, and the GitLab offline guidance describes a comparable bundle for self-managed instances. Done when the manifest and the bundle can be reproduced from the staging host's records.
Verify checksums and signatures before import
The security team checks each file in the bundle against the published checksums and package signatures before it crosses into the isolated network. Record the verification result next to the manifest, and reject any file that fails. Ask the vendor or project which signing keys apply to each artifact and store those keys through the same change process. This step addresses the software integrity and authenticity controls that NERC CIP-013-2 describes for vendor software and patches, and the same review fits other frameworks your organization is assessed against. Done when every artifact has a recorded verification result and a named approver.
Mirror images to the internal registry
The platform team loads the verified container images into an internal registry and points the deployment configuration at that registry instead of a public one. Packages are placed in an internal repository or mirror that the server can reach. Confirm that the server cannot resolve or reach public registries, so a misconfigured pull fails visibly rather than quietly reaching the internet. Done when a test host inside the isolated network pulls each image from the internal registry and none of the pulls use an external address.
Install and issue certificates from the internal CA
The platform team installs the chosen method, either the Docker setup or the Debian and Ubuntu packages for Jitsi, or bbb-install.sh for BigBlueButton, using the offline repositories. Certificates come from the organization's internal certificate authority for a valid hostname. Jitsi's handbook states that HTTPS is necessary for audio and video to work and warns that self-signed certificates cause problems, especially with mobile clients, so install the internal CA root on every managed client. BigBlueButton also needs a valid hostname for SSL. Done when the service loads over HTTPS in a browser on a managed device with no certificate warning.
Configure TURN and firewall rules
The network team configures a TURN server for users behind restrictive firewalls, which BigBlueButton recommends, and opens only the ports the chosen platform requires between the defined network zones. For Jitsi, check 10000/UDP for media and the optional 5349/TCP fallback and 3478/UDP for STUN. Confirm the firewall denies all other traffic and that the server has no default route to the internet. Confirm with the team that owns the firewall whether the TURN relay is reachable only from the intended user segments. Done when a test client on a restricted segment joins a meeting and media flows through the expected path.
Set authentication for the deployment
For Jitsi, 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. Token issuance should come from the internal identity system. For BigBlueButton, Greenlight v3 supports external authentication through OpenID Connect configured with environment variables, and the documentation suggests Keycloak as a broker for SAML and other login methods. Set the shared secret for BigBlueButton API calls on the server side only, because the documentation warns never to embed it in a web page. Done when a user signs in through the intended identity path and an unauthenticated request to create a room is refused.
Test with the real client set
The service desk and a pilot group test the deployment on the same browsers, operating systems, managed laptops and mobile devices that staff use, inside the isolated network. Test audio, video, screen sharing, chat, recording where enabled, and joining from a restricted segment. Log every failure with the client, version and network zone. Retest after each fix. Done when the pilot group signs off on a written test list and every failure has a recorded resolution or an accepted workaround.
Define a repeatable offline update cycle
The platform team writes a procedure that repeats the earlier steps for every release: build the bundle on staging, verify it, import it, mirror the images, test on a non-production host, then apply to production. BigBlueButton 4.0 documents that direct upgrades from 2.6, 2.7 or 3.0 are not supported and that a clean installation is recommended, so plan the migration path with the vendor before a change window. Keep the change record, the manifest and the verification results together so an auditor can trace each update. Done when a dry run of the full cycle completes in a test environment and the procedure has an owner.
Certificates, TURN and ports for each option
Jitsi Meet needs a valid HTTPS certificate on a proper domain name before audio and video work reliably. The Jitsi handbook says HTTPS is necessary for multimedia to work and warns that self-signed certificates cause problems, especially with mobile clients. In an air-gapped network this means you need an internal certificate authority that clients trust, or a certificate issued for the internal domain and installed on every device that joins meetings. Install paths are either the official Docker setup or Debian and Ubuntu packages, and the Debian and Ubuntu quick start supports Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer, requires OpenJDK 17.
- Certificates: Plan an internal CA or a domain certificate that browsers and mobile clients trust without exceptions.
- Ports: Keep 80/TCP and 443/TCP open for the web app, and 10000/UDP open for media. Open 5349/TCP for TCP fallback and 3478/UDP for STUN only if your design calls for them.
- Install path: Choose Docker, which runs separate web, prosody, jicofo, jvb, jigasi and jibri containers, or Debian 12 or Ubuntu 24.04 packages with OpenJDK 17.
- Container model: Since release stable-11146, the Docker containers run rootless with read-only filesystems, which narrows what a compromised container can change.
- Mirrors: Stage packages, container images and JDK builds on an internal repository before cutover, because the host cannot reach public mirrors.
Confirm the exact port list and the certificate chain with the Jitsi quick start for your chosen operating system before you write firewall rules.
BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit using the bbb-install.sh script. It requires TCP ports 80 and 443 reachable, a valid hostname for SSL, and Docker for sandboxed LibreOffice document conversion. Media flows over UDP ports 16384 to 32768, so that range must be open between clients and the server. The project recommends a TURN server for users behind restrictive firewalls, which matters for any air-gapped site where client networks filter UDP. Direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a clean server installation and migrate content deliberately.
- Hostname and SSL: Assign a valid hostname that the internal certificate covers, since the installer and clients depend on it.
- Ports: Open TCP 80 and 443 plus the UDP range 16384 to 32768. Firewalls that block UDP will force users onto TURN.
- Docker: Install Docker on the host for sandboxed document conversion, and stage its images in advance.
- TURN: Deploy a TURN server inside the network for users behind restrictive firewalls, and size it for your concurrent user count.
- Clean install: Build a new 4.0 server rather than upgrading 2.6, 2.7 or 3.0, and move recordings and Greenlight data as a separate task.
Confirm TURN sizing for your user count, expected concurrent sessions and recording load with the BigBlueButton install documentation before you commit to a server specification.
Both products expose the same kinds of network paths: a web entry point, a media path over UDP and a fallback path over TCP when UDP is blocked. Security teams should treat these as a single design exercise, because each open port is a boundary decision. Inside an air-gapped network, there is no public DNS or public certificate authority, so names and trust must come from your own infrastructure. Document each flow, its source and destination, and who approves it, so the firewall policy can be reviewed against your controls.
- Internal DNS: Publish the meeting hostnames in your own DNS zone so clients resolve them without internet access.
- Trust store: Push the internal CA root to managed devices, including mobile devices that enrolled meetings apps.
- Flow inventory: List every web, UDP media and TCP fallback path per product, with source, destination and owner.
- Segmentation: Place media servers in a zone that only the meeting clients and TURN or STUN services can reach.
- Time sync: Keep all servers on an internal time source, because certificate validation fails when clocks drift.
Check your intended flows against each product's current port guidance and your segmentation standard before you request firewall changes.
Verification is where most air-gapped meeting projects find gaps. Test each option from the networks your users really occupy, not only from the server rack. Use a client on the most restrictive segment, check that the certificate chain validates on every device class, and confirm that media still flows when UDP is filtered and the fallback path is used. Record the results as evidence, because they feed change records and any assessment you prepare for.
- Certificate test: Join a meeting from a managed laptop, a browser on a second device and a mobile client, and confirm each trusts the chain.
- UDP test: Run a session with UDP blocked on one segment to confirm the TCP fallback or TURN path works.
- Port scan: Verify that only the documented ports answer on each server.
- Load test: Run a session sized to your expected concurrent users and watch CPU, memory and bandwidth.
- Evidence: Keep configuration files, firewall rules and test results in your change system.
Ask your implementation partner or internal team to write the test cases from the vendor requirements before you schedule the cutover window.
Evidence that auditors and regulators ask for
An isolated video deployment is only as defensible as the records that show what runs, where the boundary sits, and how software entered the network. The five items below connect the architecture to the certificates, packages, changes and recordings that assessors will sample. DeployOpen prepares these systems, controls and evidence for assessment, while independent auditors and certification bodies issue any audit report or attestation.
Architecture diagram with trust boundary
Draw every Jitsi or BigBlueButton component, the web front end, signaling, media, recording and TURN hosts, and mark where the air gap and any approved transfer point sit. Show which ports are open inside the enclave, such as UDP 10000 for Jitsi media or UDP 16384 to 32768 for BigBlueButton, and which hosts can reach them. Assessors use this diagram to decide which systems are in scope, so it must match the running configuration. Confirm the diagram with a network scan taken from inside the enclave.
Certificate inventory and issuing CA records
List every certificate that the meeting platform uses, with its subject, issuer, serial number, expiry date and the host it protects. Jitsi's handbook warns that self-signed certificates cause problems, especially with mobile clients, so the issuing internal CA must be documented, its root and intermediate keys held under separate control, and its issuance log retained. Record who approved each certificate and the renewal procedure, since an expired certificate on an offline system can stop meetings with no external alert.
Software bill and package integrity records
For each imported bundle, keep a bill of materials that lists package names, versions, licenses and cryptographic hashes, plus the signature checks performed before import. Record which Docker images or Debian and Ubuntu packages came from which media, who verified them, and where the verified copies are stored. This is the record that supports supply chain requirements such as the integrity checks in NERC CIP-013-2, and it is the record most often missing when a transfer is later questioned. Confirm the hashing method with your assessor before transfer begins.
Change log of offline updates
Every update carried across the boundary should appear in a dated change record with the previous and new release, the reason, the approver and the test result. Keep the release notes and the import manifest with the change record so assessors can trace what changed on each host. BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so a version jump may require a clean install rather than an in-place change, and the log must show that decision. Ask the platform owner to confirm the upgrade path before scheduling media transfers.
Recording retention and access logs
Recordings, chat and transcripts are regulated data, so document where each file type is stored, how long it is kept and who can open it. Set a retention rule for recordings and delete on schedule, then log every download, playback and deletion with the user account and timestamp. BigBlueButton expects 500 GB of disk for recordings, which makes storage capacity and deletion records part of the same evidence set. Access controls for recording storage should map to the identity source your organization already audits.
What does an air-gapped Zoom replacement cost and take?
What drives the total cost of an air-gapped Jitsi or BigBlueButton deployment?
The main cost drivers are hardware, bandwidth, TURN infrastructure, recording storage and staff time, and no software license fee applies to either open-source platform. Hardware scales with concurrent users and whether you record. Bandwidth is a recurring cost on your own links, though an air-gapped site may carry it on internal networks only. Staff time covers installation, hardening, backups, upgrades and user support, which recur every year. Ask any implementation partner to price each component separately so you can see what is one-time and what recurs.
What server hardware does BigBlueButton 4.0 need for an air-gapped install?
The BigBlueButton 4.0 install documentation lists at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. The 4.0.0 release installs on Ubuntu 24.04 64-bit, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan for a clean server. Recording storage grows with meeting hours, so size it from your expected usage. Confirm these figures against the current install page before you order hardware.
How long does an air-gapped video conferencing deployment take?
Duration depends mainly on how many platforms are involved, whether the site is greenfield or has existing hardware, how many users need to be migrated and how long your change windows and approvals take. Staging a complete offline package, installing servers and validating certificates and TURN are separate steps, and each has its own lead time. Ask for a written timeline tied to a fixed scope and dependencies, such as when the certificate authority and network access will be ready. Avoid timelines that do not list their assumptions.
What does the client need to provide for an air-gapped project?
You typically need a staging network with internet access to build and verify offline packages, a certificate authority that can issue certificates for a valid hostname, DNS entries for the service names, and a plan for TURN for users behind restrictive firewalls. You also need the air-gapped network's firewall rules for TCP 80, TCP 443 and UDP 16384 to 32768 for BigBlueButton, plus change windows for installation and updates. Confirm early who approves media transfers across the isolation boundary.
Can our own team deploy and run Jitsi or BigBlueButton without outside help?
Yes, if you have Linux administrators who can manage Docker or Debian and Ubuntu packages, TLS certificates, firewall rules and backups. Both platforms publish installation guides, and the Jitsi handbook recommends a proper domain certificate because self-signed certificates cause problems, especially on mobile clients. The harder parts are sizing for peak concurrency, hardening, testing failover and keeping an offline update process current. Assess those skills honestly and decide whether ongoing operations will sit with your team.
How do updates work when the network stays disconnected?
Updates are not pulled from the internet, so each release must be downloaded on a connected staging system, verified and carried across the boundary under your change control. This includes operating system packages, container images or Debian packages, and the platform itself. Check the release notes for upgrade paths, because BigBlueButton 4.0 does not support direct upgrades from earlier branches. Run a documented test on a copy of the environment before each production update, and keep a rollback path.
What should a written quote for an air-gapped deployment include?
Ask for a fixed scope with the platforms, number of servers, expected concurrency, recording needs and integrations listed. The quote should separate one-time work (design, staging, installation, hardening, certificate and TURN setup, testing, user migration) from recurring work (backups, upgrades, monitoring, support). It should name the client dependencies, the assumptions behind the timeline, the acceptance tests and what documentation is delivered. DeployOpen works on fixed-scope engagements agreed in writing, with ongoing support available as a retainer.
How DeployOpen deploys under an air-gapped constraint
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own networks, including air-gapped ones. For a disconnected Jitsi or BigBlueButton deployment, the work starts with the certificate, TURN, package and update path that the isolated network must carry.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the platform, the server and network layout, the certificate authority and the recording storage to be deployed.
- Scope also records how packages, container images and updates cross the isolated boundary and who approves each transfer.
How we build
- We install the chosen platform inside your cloud account, data center or air-gapped network, using the vendor's documented install path.
- We configure HTTPS with certificates issued by your internal authority, plus TURN relay and the UDP media ports the design requires.
- We test sessions from inside the isolated network, including clients behind restrictive firewalls, and document the results.
How we hand over
- Handover includes installation, configuration and operations documentation, plus a record of every package and image brought into the network.
- We document backup, restore and the offline update procedure so your own staff can repeat each step without internet access.
- Compliance evidence is prepared for your assessors, and independent auditors or certification bodies remain responsible for any assessment outcome.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing like the original engagement.
- Upgrades are planned as offline transfers, verified before import, and tested in a staging environment first.
- Security testing of the deployed platform, including its TURN and certificate setup, can be scheduled as part of a retainer.
