Why an air-gapped digital workplace suite is a different build
A regulated or critical organization can run files, office, mail, chat, video, wiki and projects on a network with no internet path, but every image, Helm chart, external service and monthly update must be carried across the boundary and verified before it runs. The suite itself is not the hard part. The build changes because nothing in the environment fetches anything on its own: container images, chart packages, vulnerability data, mail relays, TURN servers and antivirus signatures all need an internal source, and each artifact needs a documented integrity check before it enters the enclosure. Plan that transfer process as a standing operating function, not a one-time copy. For most teams the short answer depends on how much integration they want from one vendor. openDesk is the integrated option for Kubernetes: it bundles Element, Nextcloud, OX App Suite, XWiki, OpenProject, Jitsi and Collabora under one deployment automation, so the offline bundle, the component versions and the upgrade sequence come from one project. A Nextcloud-centred stack suits teams that want component-level control, choosing their own mail, chat and video servers and accepting more integration work in exchange. Confirm which Kubernetes platform, database and object storage your enclosure already operates before choosing either path, because openDesk expects a specific set of external services to exist inside the network. Licensing must be checked before the build starts, not after the first offline install fails. Air-gapped deployment is often a paid-edition feature: Mattermost lists it under Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, and Element offers a separate Sovereign edition for air-gapped use. Ask each vendor in writing whether the offline installation, offline updates and offline security content are included in the edition you plan to run. For openDesk, confirm with ZenDiS which parts of the offline path belong to the community release and which depend on Enterprise Edition support.
Which requirements shape the air-gapped build
This table maps each requirement or constraint to its source and the build decision it forces on an isolated openDesk or Nextcloud-centred deployment. Read it as a checklist to settle before procurement, since several rows (registry, external services, upgrade path) determine cost and staffing as much as they determine technical design.
| Requirement | Source of the constraint | What it means for the build |
|---|---|---|
| Offline Kubernetes image pulls | Kubernetes kubeadm docs: config images list and pull fetch control plane images in advance | Pull and stage every control plane and add-on image on a connected staging host, then transfer them across the boundary before any cluster build begins. |
| Private registry for all workloads | Kubernetes kubeadm init supports a custom --image-repository flag | Run an internal registry that serves every openDesk image by pinned digest, and confirm with ZenDiS which image set each release needs. |
| Signed charts and pinned images | NERC CIP-013-2 requires verification of software integrity and authenticity for vendor software and patches | Verify signatures and checksums on each Helm chart and image at the boundary, record the results, and deploy only pinned versions. |
| External production services | openDesk production expects PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server | Each service must run inside the enclave, with its own backup, patching and sizing. Confirm which team operates each one before scoping. |
| Internal TURN, SMTP and antivirus | openDesk requirements list TURN, SMTP relay and ClamAV over ICAP as external services | Calls, outbound notifications and file scanning need internal endpoints. Confirm that no component falls back to a public relay or update service. |
| Audit and access evidence | HIPAA 164.312(b) requires audit controls for systems holding ePHI; SEC 17a-4(b)(4) requires retention of business communications for at least three years | Keep logs from every component in the enclave, and check retention settings for mail and chat against the rule that applies to your sector. |
| No-internet update path | openDesk ships monthly minor releases, supports only the latest minor, and may need intermediate steps when several minors are skipped | Plan a repeatable transfer, verification and staging cycle each month, or accept a planned lag with documented risk. Rehearse upgrades on a copy before production. |
| Major release and skip limits | Nextcloud does not allow skipping major releases; openDesk does not guarantee in-place upgrades between majors | Schedule major upgrades as projects with full backups, one step at a time, and third-party apps disabled until confirmed compatible. |
Which platforms fit a disconnected workplace
A disconnected workplace needs every component to install, update and authenticate without reaching the internet. The platforms below differ in how much of that work the vendor has already designed, and in which air-gap features sit behind a paid edition. Confirm offline behavior for each component in writing before you commit to a stack.
openDesk as an integrated suite
openDesk is a Kubernetes-based workplace suite provided by ZenDiS and deployed with Helmfile and Helm, so the whole stack is one release set to mirror across the boundary. Its releases follow a cadence of monthly minor versions with only the latest minor supported, which makes an offline upgrade rehearsal a recurring task rather than a one-time one. Confirm which bundled components accept offline package and image sources, and whether the Enterprise Edition support you need covers your disconnected design.
Nextcloud-centred stack
Nextcloud Server is licensed under AGPL-3.0 and can be assembled from your own mirrored images and packages, with Nextcloud All-in-One as the official installation method if you prefer a packaged deployment. Office, talk and search are separate choices that each need their own offline source and update path. Plan for the major-release rule, since Nextcloud does not allow skipping major versions, and confirm with Nextcloud which apps you can install without contacting the app store.
Stalwart for mail
Stalwart is an all-in-one mail and collaboration server that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV under AGPL-3.0, with an optional Enterprise License from Stalwart Labs. In a disconnected network it still needs a relay path, DNS and certificate sources, and an antivirus integration you control. Confirm with the vendor which features depend on outbound connectivity, such as DKIM or reputation lookups, and whether any of them require the paid license.
mailcow for mail
mailcow-dockerized is a GPL-3.0 Docker-based mail stack that bundles SMTP, IMAP, webmail, and anti-spam and antivirus components in one compose project. Its images and update scripts pull from the internet by default, so an offline build means mirroring the images, the release tag and the update tooling, then pinning them. Check how the bundled spam and antivirus components update their signatures without outbound access, and plan a manual process for each release.
Chat with paid air-gap editions
Mattermost lists air-gapped deployment in its Enterprise Advanced plan, and Rocket.Chat excludes it from the free Starter plan, so budget for a paid tier if the disconnected design is a hard requirement. Element Server Suite offers a free AGPL Community edition, a Pro edition and a Sovereign edition built for air-gapped deployments. Compare the plan terms, the update channels and the offline license handling for each, because license validation can fail if the license server is unreachable.
Jitsi Meet or BigBlueButton for video
Jitsi Meet (Apache-2.0) and BigBlueButton (LGPL-3.0) are both self-hostable and run on your own servers, but each needs TURN and media relay design that works inside the boundary. Confirm whether the media path can stay on internal addresses, which TURN service you deploy, and how recording storage is handled. Choose BigBlueButton when you need a heavier teaching or webinar feature set, and Jitsi when you want a lighter meeting service with fewer moving parts.
Which internal services the suite needs inside the boundary
openDesk expects several production-grade services that sit outside the suite itself. On a disconnected network each one must run inside the boundary, be patched from mirrored media, and be sized for the workload. Plan ownership and offline behavior for each before the first chart is deployed.
TURN server for calls
openDesk expects a TURN server so that video calls and conferencing can traverse NAT and firewalls between users and the media services. Inside an air-gapped network, the TURN service must be reachable by clients on the internal network and must not depend on any external relay or public STUN service. Confirm with ZenDiS documentation which TURN implementation and version the release you are deploying expects, how credentials are issued, and which ports must be open between segments. Your network team typically operates it, with the platform team owning the configuration that the suite references.
SMTP relay for mail flow
The suite sends notifications and some mail flow through an SMTP relay that you run or approve. On a disconnected network there is no outbound path to public mail providers, so the relay has to deliver to internal recipients and to any gateway that handles external mail. Confirm with the vendor whether the relay must support specific authentication methods, TLS settings and sender domains, and how bounces and queue monitoring are handled. The messaging or mail team usually operates the relay, and the security team should review its logs for retention.
ClamAV over ICAP for file scanning
The suite expects antivirus scanning of uploaded and shared files through ClamAV reached over ICAP. In an isolated network, the ClamAV signature database cannot be fetched directly, so it must be updated from a mirror that your team imports through the approved transfer process. Each signature update is software content entering the boundary, so record its source, hash and import date. Confirm with ZenDiS how the ICAP endpoint is configured, how scan failures are handled and how much scanning capacity peak uploads require. The security operations team usually owns signature updates, and the platform team owns the scanning service.
Object storage for files
Production openDesk deployments expect object storage for file and document data, which is separate from the cluster's block volumes. Inside the boundary this is usually an S3-compatible service that you operate, and it must be sized for growth, replication and backup. Confirm which S3 API features the suite components need, such as versioning or lifecycle rules, and whether the Enterprise Edition's OX S3 storage option changes the requirement. Backups of this storage must be captured in the same offline transfer plan as the databases so that restores stay consistent.
Production databases and caches
openDesk expects externally managed production services, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached and Cassandra, rather than in-cluster test instances. Each engine must be patched and backed up under your own runbook, and the versions must match the release notes for the openDesk version you run. On an air-gapped network, database packages and upgrade images come through the same signed transfer path as the charts. Your database platform team typically operates these services. Confirm the supported versions, replication model and backup tooling with ZenDiS before sizing.
Private container and chart registry
The deployment is Helmfile and Helm based, so every chart and every container image must be served from a registry inside the boundary. Mirror the exact chart versions and image digests for the openDesk release you have approved, and verify signatures before import, as the supply chain control in NERC CIP-013-2 expects for vendor software. Keep the mirror pinned to a release, so an unverified upstream tag cannot reach production. The platform engineering team operates the registry, and the security team signs off on each import. Confirm with the vendor how the release artifacts are signed.
How mirrored charts and pinned images stay trustworthy offline
An air-gapped network cannot simply pull the latest release, because nothing it runs can be trusted to match what the vendor published unless every artifact was checked at the boundary. A connected cluster resolves a chart version and then fetches whatever image tags the chart references at that moment. On a disconnected network, that same pull-on-deploy behavior either fails or, worse, reaches a mutable tag that changed upstream after your last review. The fix is to decide, in writing, which exact chart versions and image digests the suite may run, mirror only those, and refuse anything that does not match. For openDesk, that means recording the Helmfile and Helm chart versions alongside the image references, not just the release name. The openDesk release cadence (monthly minor releases, as described elsewhere on this page) makes this list change often, so the pinned set must be a versioned input to your change process, not a folder someone refreshes by hand.
Before anything crosses the boundary, verify each chart and image against the publisher's signatures or provenance data, and keep the result with the artifact. Confirm with ZenDiS and each bundled component's maintainer which signing method they use, where the signing keys are published, and whether the chart and image signatures are checked by a tool you can run inside the isolated network. Do not assume that a checksum file next to a download is a signature. Record each import in an import register: artifact name, version, digest, signature verification result, the person who approved it, the date it entered the enclave and the destination registry path. This register is the evidence an assessor will ask for. NERC CIP-013-2 is the control to cite for a bulk electric system operator, because it expects supply chain procurement processes to address verification of software integrity and authenticity of vendor software and patches. The same record supports supply chain expectations under NIS2 and the software provenance questions in defense and public procurement, which ask how you know what was installed and who accepted it.
Treat the mirror as a product with its own owner. Name who approves a new pinned set, who runs the verification, and who can roll back to the last known-good set when a monthly release breaks a workload. Confirm with the implementation partner how the import register is generated, whether it can be exported in a format your GRC or ticketing system reads, and how long the previous chart and image sets are kept so a rollback is possible without reaching the internet. Because openDesk supports only the latest minor version, your rollback path and your upgrade rehearsal (covered in the upgrade section) depend on the same mirrored sets. If a component's release process does not publish verifiable signatures for every artifact, record that gap as a named risk with a compensating check, such as a hash comparison against a copy obtained through a second channel, and confirm the approach with your assessor before the first production import.
How the air-gapped rollout runs in phases
The sequence moves from a licensed component list to a connected staging zone, then into the disconnected network, so each phase hands over a verifiable artifact before the next one starts. The end state is a production openDesk or Nextcloud-centred suite with pinned versions and a rehearsed upgrade path.
Scope components, licenses and support model
The client's architecture lead and DeployOpen agree the components in scope, the edition for each (community or enterprise, such as openDesk Enterprise Edition where the client chooses it), the identity source, and which external services the suite needs. Each license is recorded alongside its own terms, because openDesk's deployment automation is Apache-2.0 while bundled components keep their own licenses. The output is a scope document and a component and license register. Done means the client has signed off the list and knows which vendor support contracts apply.
Build the connected staging zone and mirror
In a connected staging zone, the team pulls the Helm charts and container images for the chosen release, pins every version, and records checksums and signatures. Each artifact is copied into a controlled transfer set, and the team confirms the signatures before anything crosses the boundary. The output is a mirror manifest listing each chart, image digest and source, plus the verification log. Done means a second person has reviewed the manifest and every entry verifies.
Prepare the Kubernetes cluster from a private registry
The platform team prepares the cluster using the kubeadm image list and pull steps run during staging, then points kubeadm init at the internal registry with the image repository option. The cluster must meet the openDesk requirements for version, ingress controller, cert-manager, storage and Helm and Helmfile versions, which the team checks against the current requirements page. The output is a cluster build record and a registry inventory. Done means the cluster starts with no outbound pulls and every control plane image resolves from the internal registry.
Deploy the external services inside the boundary
The operations team brings up the services that openDesk expects in production, including PostgreSQL, MariaDB, Redis, Memcached, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each service is configured to resolve only internal names, and TURN is reachable only where the design needs it. The output is a service inventory with owners, versions and backup settings. Done means each service passes its own health check and an internal test message or file scan completes.
Integrate identity with the directory
The identity team connects the suite to the client's directory, either through the identity provider or the directory importer documented for the chosen stack, and maps user attributes. Test accounts from a small pilot group are used to confirm sign-in, group membership and access to each component. The output is an identity mapping document and a sign-in test report. Done means every in-scope component authenticates through the one identity layer and disabled accounts stop working.
Run the evaluation deployment
The team installs the pinned release into a non-production namespace and runs functional checks for files, office editing, mail, chat, video, wiki and projects. Failed checks are logged with the fix applied and the release is rebuilt from the mirror, not patched by hand. The output is an evaluation runbook and a defect log. Done means the acceptance checklist passes with no open critical defects and the team has confirmed the runbook reproduces the install from the mirror alone.
Deploy production with pinned versions
The production install uses the same mirror, the same pinned chart and image digests, and the same configuration values reviewed during evaluation. Access controls, logging, backups and the restore procedure are enabled before users are onboarded. The output is the production runbook, the configuration baseline and signed acceptance test results. Done means the restore test completes and the acceptance tests are signed by the client owner.
Rehearse the first upgrade and document it
Before go-live is considered complete, the team runs the first upgrade in a copy of production, taking the next version from the mirror and following the vendor's release management guidance on supported paths and intermediate steps. The rehearsal records the steps, rollback points and any manual changes. The output is a documented upgrade rehearsal report that becomes part of the runbook. Done means the rehearsal completes, the rollback path is tested, and the client has agreed who runs the next upgrade and how new artifacts are brought across the boundary.
How to keep an offline suite patched without falling behind
openDesk publishes minor releases monthly, and only the latest minor version is supported. That means a disconnected deployment that stays on an older minor drops out of support, so the monthly cycle is the baseline rhythm rather than an optional project. For illustration, the latest release at research time was v1.19.1, published on 2026-10-06, after v1.19.0 on 2026-10-01. Your team would pull the signed chart and pinned images for the target minor through a controlled transfer, then run the standard path of import, verify, rehearse in staging and promote.
- Import on a schedule: Set a fixed monthly window for bringing release artifacts across the boundary, so the cycle does not depend on individual requests.
- Verify before staging: Check chart signatures and image digests against the supplied release metadata before anything enters the mirror.
- Rehearse in a staging copy: Upgrade a copy of production with production-like data and confirm logins, file access, mail flow and video calls.
- Promote with a rollback plan: Keep the previous minor's artifacts in the mirror until the new minor has run cleanly in production.
- Skip with care: If several minors were missed, check the release notes for intermediate steps before attempting a jump.
Confirm with the vendor whether your target minor requires any intermediate step from your current version, and record that answer in the change ticket.
openDesk plans major releases annually, in Q3. In-place upgrades between majors are not guaranteed, so a major release is a migration project with its own design, testing and cutover, not a routine patch. Treat each major as a new environment that you prove in staging before any production change. Plan the window early, because the rehearsal often surfaces configuration changes, bundled component version jumps and data migrations that need time.
- Plan the major in the prior year: Put the Q3 major release on the roadmap so budget, staffing and change windows exist before the release lands.
- Build a parallel environment: Deploy the new major beside the current one in the offline network and migrate a copy of the data into it.
- Test every bundled component: Check mail, chat, video, wiki, project and file workflows, since each component carries its own version change.
- Document rollback limits: Confirm with the vendor whether a rollback path exists once the database schema has changed.
- Keep a cutover runbook: Record the exact steps, owners and go or no-go criteria for the production switch.
Ask the vendor or implementation partner to show the documented upgrade path from your current major to the target, including any stop points.
Patch releases arrive on demand, typically for security or critical defects, and do not wait for the monthly cycle. In a disconnected network, the delay between publication and installation is the exposure window, so the team needs a fast lane that uses the same verification steps without skipping them. Keep a standing procedure and named approvers so a security patch can move from transfer to production without a new design discussion.
- Subscribe to release notices: Watch the vendor release channel and assign one person to triage each notice against your deployed versions.
- Use an expedited import path: Transfer only the affected artifacts through the approved media process and log the transfer.
- Verify integrity first: Confirm signatures and digests exactly as for minor releases, even under time pressure.
- Run a targeted rehearsal: Test the patched components and their direct dependencies in staging before promotion.
- Pre-approve the change: Agree in advance which patch classes can bypass the monthly window and who signs off.
Confirm with your vendor or partner how quickly they publish patch notices and whether patches are tied to the current minor line only.
Nextcloud publishes a new major version every four months and supports each for one year through monthly maintenance releases. Nextcloud does not allow skipping major releases during upgrades, so an offline deployment must step through each major in order. Before every upgrade, take a backup, and disable third-party apps until their developers confirm compatibility with the target version. Plan these steps as part of the same rehearsal cycle used for openDesk, since the Nextcloud component may sit inside an openDesk deployment or a standalone Nextcloud stack.
- Upgrade one major at a time: Map the path from your current major to the target and schedule each hop as its own rehearsal.
- Back up before every upgrade: Capture database, configuration and data together, and test a restore on the staging copy.
- Disable third-party apps: Turn off non-core apps before the upgrade and re-enable each only after its compatibility is confirmed.
- Check system requirements: Confirm database, PHP and web server versions against the target release before the window.
- Track support end dates: Note when each major leaves support so the next hop is scheduled before the line ends.
Check the current release schedule and system requirements for your target version before fixing the upgrade plan.
Which evidence an offline suite produces for auditors
This table maps each piece of evidence an assessor or regulator typically asks for to the component or step that produces it and the rule it supports. Use it to plan which logs, inventories and records must exist before the first assessment, and note that DeployOpen prepares this evidence while independent auditors assess it.
| Evidence item | Produced by | Regulation or control it supports |
|---|---|---|
| Import and signature verification log | Transfer process that checks each Helm chart and image signature before it crosses the isolated boundary, with results stored per import batch | NERC CIP-013-2 (verification of software integrity and authenticity of vendor software and patches) |
| Image and chart inventory | Pinned list of every chart version, image digest and bundled component license, generated from the internal registry and Helmfile state | NIS2 supply chain expectations and NERC CIP-013-2 procurement records |
| Audit logs for ePHI access | Audit logging enabled in Nextcloud, Mattermost or Element, forwarded to a central log store that is kept inside the enclave | HIPAA Security Rule 45 CFR 164.312(b) audit controls |
| Encryption in transit records | TLS configuration for ingress, internal TURN, SMTP relay and database connections, with certificate inventory and cipher settings exported on each release | HIPAA Security Rule 45 CFR 164.312(e)(1) transmission security |
| Archived mail and chat retention | Stalwart or mailcow archive and chat retention policy exports, with proof that copies of business communications are preserved for the required period | SEC Rule 17a-4(b)(4) where broker-dealer rules apply; confirm with counsel |
| Remote access session records | Intermediate system logs for vendor access, MFA events and session termination records for active vendor sessions | NERC CIP-005-7 where the suite supports high or medium impact BES Cyber Systems |
| Upgrade rehearsal record | Staging run of each monthly openDesk minor release or Nextcloud major upgrade, with backup proof, test results and rollback notes | Change management and supply chain evidence; confirm the scope your assessor expects |
What buyers ask before an air-gapped workplace build
What drives the cost of an air-gapped digital workplace build?
The main cost drivers are the number of components in scope, the external services you must run inside the boundary, the Kubernetes platform you already operate, and the licensing model you choose. Each component adds configuration, identity integration and testing work. The external services openDesk expects for production, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, must be provided and operated by you or sourced separately. Recurring costs include staff time for offline upgrades, hardware, and any Enterprise subscriptions. Ask any partner for a quote that lists each component, each external service, who operates it, and which tasks recur monthly.
How long does an air-gapped workplace build take?
The duration depends on how many components are in scope, how quickly your network and security approvals move, how many external services you must stand up, and how many identity sources must be connected. No general timeline is given here, because a fixed scope is agreed in writing before work starts. Ask for a timeline tied to named milestones: boundary and registry preparation, first deployment in a test enclave, identity integration, data migration and one rehearsed upgrade. Plan extra time for the transfer process, since every chart and image must be verified before it crosses into the isolated network.
What does the work need from our network and security teams?
The build needs four kinds of input from your side:
- Written approval for a transfer process that moves signed Helm charts, pinned images and packages across the isolated boundary, with verification at each step.
- A private registry, package mirror and Kubernetes cluster reachable only from inside the enclave.
- Access to your identity source, such as a directory or an external identity provider, so users can sign in with their existing accounts.
- Named owners for the SMTP relay, TURN service and antivirus service, since the platform depends on them for mail, calls and file scanning.
Confirm early whether your change process allows an offline transfer media workflow and who signs off on each batch of artifacts.
Can our internal team run an air-gapped workplace suite without a partner?
A team can run the suite alone if it has Kubernetes and Helm operations experience, database administration for the external services, identity administration, and a tested runbook for each component. The skills that most often decide success are offline image and chart management, certificate handling, backup and restore, and upgrade rehearsal. Your team should also be able to read component release notes and decide which minor releases to apply. Whether to partner depends on how many of these skills you already have in-house, and on how many components you plan to run at once.
How often do updates arrive, and how do we handle them offline?
openDesk plans major releases annually in Q3, minor releases monthly and patch releases on demand, and it supports only the latest minor version. Because in-place upgrades between majors are not guaranteed and skipping several minor versions may need intermediate steps, you should plan each cycle as a transfer, a mirror update, a rehearsal in a test enclave and then production. Nextcloud publishes a new major version every four months and requires upgrading one major version at a time with a backup before each step. Build the monthly cycle into your operating calendar before go-live, and confirm the cadence of every other component in the stack.
Does air-gapped support require an Enterprise or paid edition?
It depends on the product. Air-gapped deployment is a paid-edition feature for some vendors: Mattermost lists it in Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, and Metabase offers it only on its Enterprise plan. Element offers a free AGPL Community edition alongside a Pro edition and a Sovereign edition for air-gapped deployments. Plane offers an Airgapped edition that is proprietary, while its Community edition is AGPL-3.0. For openDesk, ZenDiS recommends Enterprise Edition for production, which adds SLA-backed support and patches. Check each component's edition and license against your requirement before you commit to a stack.
Which security evidence does an air-gapped build produce for auditors?
An air-gapped build can generate evidence for supply chain and access controls, but it does not certify compliance on its own. NERC CIP-013-2 expects procurement processes that address verification of software integrity and authenticity, which maps directly to checking every chart and image before it crosses the boundary. NERC CIP-005-7 requires encrypted, multi-factor interactive remote access through an intermediate system for in-scope systems. Keep signed artifact records, transfer logs, version manifests and upgrade rehearsal reports. Independent auditors and certification bodies decide whether that evidence is sufficient for your regulator.
What to ask an implementation partner for an air-gapped suite
Start by asking for written scope and acceptance criteria before any work begins. Ask the partner to list every artifact that crosses the boundary: each Helm chart, each container image pinned by digest, each Helmfile release, and each package used for the openDesk deployment. Ask how they build the mirror, which tool generates the image list, how they verify signatures on charts and images, and where they record the checksums. Ask who signs off on the transfer and what evidence the transfer produces. For licensing, ask which components in your openDesk edition or your Nextcloud stack need a paid subscription to run disconnected. Vendor pages differ on this. Mattermost, Rocket.Chat and Metabase each place air-gapped deployment in paid tiers, and Element offers a separate Sovereign edition. Ask the partner to confirm in writing which license covers each component in your design, and which subscriptions you must buy before the first offline install.
Next, ask how the partner rehearses upgrades offline. openDesk publishes minor releases monthly and supports only the latest minor version, so your team will repeat the mirror-and-upgrade cycle often. Ask for a dry run on a copy of the environment, a rollback plan, and the exact steps for skipping versions when your installed release falls behind. Ask what they test for the external services that openDesk expects in production: the internal TURN server for calls, the SMTP relay for notifications and mail flow, and ClamAV reached over ICAP for file scanning. Ask for test cases that prove each service works with no route to the internet, and that failures are logged and visible to your operators. Finally, ask who operates the registry and chart mirror after handover, who approves new artifacts, how often the mirror refreshes, and what support covers each component, including whether the partner's support and your vendor's support both apply to each one.
How DeployOpen scopes and supports an air-gapped workplace
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For a disconnected workplace suite, the work starts with a written scope that fixes which components, mirrors, internal services and upgrade steps are in play before any build begins.
How we scope
- Confirm which suite components are in scope, such as files, office, mail, chat, video, wiki and projects, and which are deferred
- Map the internal SMTP, TURN, antivirus, database, cache and object storage services the disconnected network must provide
- Agree in writing how signed charts, pinned images and upgrade bundles cross the isolation boundary and who approves them
How we build
- Build the internal mirror for Helm charts and pinned container images, and verify signatures before anything enters the network
- Deploy and configure internal TURN, SMTP relay and ClamAV services so that video, mail and file scanning work without internet access
- Test identity federation, backups and restores on the disconnected network, then document each step as it is built
How we hand over
- Deliver the architecture, mirror procedures, configuration records and runbooks in the form agreed in the written scope
- Rehearse a full upgrade from a staged bundle on a non-production copy and record the steps, timing and rollback point
- Walk operations staff through the transfer process, evidence collection and the change record for each imported release
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing
- Review each new minor release and its bundle before it is imported, and document any intermediate steps the vendor requires
- Prepare the controls and evidence that a compliance assessor will ask for, while leaving the audit or certification to independent bodies
