Video conferencing in air-gapped networks

Jitsi can authenticate against internal XMPP accounts, JWT tokens, LDAP, Matrix user verification or a hybrid Matrix plus JWT mode, all set through the .env file of the Docker setup. For most enclaves the practical choice is JWT tokens issued by an internal identity provider, because the Jitsi handbook marks the older secure domain method as deprecated for new installations and recommends JWT with a separate anonymous domain for guests. LDAP fits sites where the directory is already the source of truth. Confirm with your identity team which directory holds the accounts, how group changes reach the meeting service, and how guest access is issued without exposing the signing secret.

Greenlight v3 supports external authentication through OpenID Connect, configured with environment variables, and the BigBlueButton docs suggest Keycloak as the broker for Google, Microsoft, SAML and other login methods. Keycloak can run on the same isolated network as the BigBlueButton server, so the login flow never leaves the enclave. Confirm which login methods your Keycloak realm will expose, whether the realm connects to an internal directory, and how Keycloak certificates are issued by your internal certificate authority so that the browser trusts them.

Recordings land on the meeting server's disk unless you move them, and a BigBlueButton 4.0 server needs 500 GB of disk for recordings (50 GB without recording) according to the install docs. For Jitsi, recording runs through Jibri containers, each of which records one meeting at a time. Retention is set by your records policy, not by the platform: regulated firms often map recordings to rules such as SEC Rule 17a-4(b)(4), which requires preserving certain business communications for not less than three years. Confirm with legal and records management which recordings are business records, where they must be archived, how deletion is evidenced, and who can export them.

Calendar and learning systems connect through the meeting platform's API or embed options, and the links must resolve to the internal hostname. BigBlueButton is embedded in LMSs such as Canvas, Moodle, Sakai and D2L, and it uses API calls signed with a shared secret. Every BigBlueButton API call needs a checksum computed with that secret, so the secret must stay on the server side and never appear in a web page. Confirm which calendar service your staff use on the isolated network, whether it can reach the meeting host name, and how the shared secret is rotated after an administrator leaves.

Yes, provided the speech-to-text engine is installed and its model files are copied onto the enclave in advance, because the isolated network cannot download them at run time. The transcription service needs GPU or CPU capacity sized to the expected number of recordings, and the audio stays on storage you control. Confirm the engine and model license, which languages you need, how transcripts are stored next to the recordings, and whether speaker labels are required. Treat transcripts as personal data where participants are identifiable, and apply the same retention rules as the recordings.

Wazuh publishes an offline installation guide for systems without internet connectivity, and its vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. The offline repository must be refreshed through a controlled transfer, and each transfer is a supply chain step that needs its own integrity check. Confirm which hosts report to the monitoring server, how agent updates are staged, how alerts from the meeting servers reach your security operations team, and how often the offline data is updated.

DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks, and most engagements are fixed-scope with deliverables agreed in writing. Identity, recording storage, calendar, LMS and monitoring integrations are usually separate line items because each depends on a different owner inside your organization. Ask a partner to list each integration point, the systems on each side, the test cases that prove it works offline, and who signs off on the records policy. A quote follows from that written scope.

The main cost drivers are the number of concurrent meetings, the number of media servers, the amount of recording storage, and how many integrations (identity, LMS, chat) must work inside the isolated network. Hardware or virtual machines for the media tier are typically a one-time purchase or provisioning cost, while operations, patching and storage growth recur. Air-gapped support is also a licensing question: some vendors place it in paid editions, so confirm the edition and its license terms before you commit. Ask any quote to split one-time build work from recurring support and to list the hardware assumptions, such as the BigBlueButton 4.0 minimum of 16 GB of RAM and 8 CPU cores per server noted in the BigBlueButton install docs.

Yes, if you have Linux, container and certificate skills in-house and enough people to cover on-call and upgrades. The work that tends to stall internal teams is not the first install but the repeatable process: staging offline container images, moving packages across the boundary with integrity checks, rotating internal certificates, and testing upgrades before they reach production. Teams often start with internal staff for operations and bring in an implementation partner for the initial build, hardening and runbooks. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks, and most engagements are fixed-scope with the scope agreed in writing before work starts.

Duration depends on scope, not on a fixed figure. The variables that move the timeline most are the number of meeting rooms and concurrent users, whether recording, LMS or identity integration is in scope, how quickly your security team approves images and packages for transfer, and how many certificate authorities and network zones are involved. We do not publish standard durations, so ask for a timeline that is tied to a written scope and lists the dependencies on your side, such as approvals, hardware delivery and change windows.

Expect to provide the following before work starts:

• Current network diagrams showing the isolated segment, firewalls, DNS and any transfer points
• Access to your internal certificate authority so media endpoints receive certificates that browsers and clients trust
• Hardware or virtual machines that meet the vendor's published minimums
• Named contacts for identity, network, security and change approval
• Decisions on recording storage location and retention

The more precise these inputs are, the more accurate the written scope will be. Certificates matter in particular: the Jitsi handbook states that 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.

Yes, but updates arrive by controlled transfer, not over the internet. The enclave receives signed or checksummed container images, packages and rule sets through an approved process, and each item should be verified before import. Some platforms document offline upgrade paths; for example, Security Onion's soup tool updates from newer ISO media in airgap mode. Ask the implementation partner to define the transfer procedure, the verification steps and the upgrade calendar in writing, and to show how the team will meet NERC CIP-013-2 style expectations for verifying software integrity and authenticity when that standard applies to you.

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. What we can provide is the configuration, documentation and evidence package your assessor will ask for, such as transmission encryption settings, authentication design, logging and retention configuration. Confirm with your assessor which evidence they require before the build begins.

Go-live is the start of operations, not the end of the engagement. Plan for recurring work: monitoring capacity as meeting volume grows, applying upgrades through the transfer process, renewing certificates, testing backups and restores, and reviewing recording storage. Ongoing support, upgrades and continuous testing are available as retainers, and the scope of those retainers should be agreed in writing alongside the build.