Microsoft 365 alternative for air-gapped networks

Microsoft 365 alternative for air-gapped networks: what an isolated network requires

Self-hosted openDesk, or Nextcloud with Collabora Online and OX App Suite, can run fully offline on Kubernetes, and the harder work is the workflow that carries every container image, Helm chart, package and vulnerability feed across the boundary and verifies each one. Cloud Microsoft 365 cannot run in a network with no internet path, so the Microsoft options to compare are Microsoft 365 Local and Sovereign Private Cloud. Confirm with Microsoft which workloads, update channels and connectivity each one requires, because those details decide whether either fits an isolated enclave. Then choose on three factors: the workloads you must keep, the team that will operate the stack, and how often your change process can accept updates.

The cluster comes first. kubeadm can fetch control plane images in advance with kubeadm config images list and kubeadm config images pull, and the --image-repository flag points kubeadm init at a private registry. openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. Its production guidance also expects external PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each of these must be mirrored or hosted inside the enclave, so ask the vendor for a complete image and package manifest before procurement closes.

Updates and scanning set the operating load. openDesk plans annual major releases, monthly minor releases and on-demand patches, supports only the latest minor version, and does not guarantee in-place upgrades between majors. Nextcloud forbids skipping major releases and requires a backup before every upgrade and a check that third-party apps are compatible. Each cycle therefore needs a signed transfer process, a staging copy and a scan of every artifact, with ClamAV over ICAP or the ClamAV service bundled in Nextcloud All-in-One. If the enclave serves energy or other critical infrastructure, NERC CIP-013-2 expects you to verify the integrity and authenticity of vendor software and patches, so document that check as a control.

What an air-gapped network demands from an office suite

An office suite on an isolated network has to be installed, updated, accessed and supported without reaching the internet. The four requirements below connect because each one moves a dependency inside the enclave, and each one needs a documented control that your own regulator or framework can review.

Offline cluster and image installation

Kubernetes can be built without internet access by pulling control plane images in advance with kubeadm config images list and kubeadm config images pull, then pointing kubeadm init at an internal registry through the image repository flag. Every openDesk or Nextcloud container image, chart and base image must also be mirrored into that registry before cutover. Ask the vendor for the complete image and chart manifest for the release you plan to install, and confirm that your registry holds every digest it lists.

Verified updates across the boundary

Updates arrive as media that you inspect and carry across the isolated boundary, so each package needs an integrity and authenticity check before it reaches production. NERC CIP-013-2 is one example from energy: it requires supply chain procurement processes that address verification of vendor software and patches. In other sectors, your framework will set the equivalent expectation. Document who verifies each transfer, how hashes or signatures are checked, and how a rejected package is handled.

Vendor remote access controls

Vendors who support the platform need a path into the enclave that is brokered, not open. NERC CIP-005-7 illustrates the pattern for high and medium impact systems: interactive remote access passes through an Intermediate System with encryption and multi-factor authentication, and active vendor sessions can be detected and disabled. Confirm with your deployment partner which access paths they need, how sessions are recorded, and how you cut access off at the end of a support window.

Services hosted inside the enclave

Production openDesk expects external services that a connected deployment would normally reach on the internet, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each one must run inside the isolated network, with its own patching and backup plan. Mail delivery is the most often missed item: an SMTP relay that can only reach an internal gateway needs routing and allow-list decisions before go-live.

Malware scanning for imported files

Every file that crosses the boundary, and every upload made by users, should pass through a scanner hosted inside the enclave. openDesk expects ClamAV reachable over ICAP, and Nextcloud All-in-One bundles ClamAV for its own deployment. Decide where scanning happens for media imports, confirm that signature databases can also be updated offline, and log scan results so an auditor can trace which file was rejected and why.

How openDesk, Nextcloud with Collabora and OX, and Microsoft 365 Local meet the constraint

openDesk arrives as one bundled suite, deployed with Helmfile and Helm under the Apache 2.0 license. The deployment automation can be mirrored into an isolated network, but each bundled component keeps its own license, so the offline mirror must carry those components as well.

Cluster base: a CNCF-certified Kubernetes cluster at v1.33 or later. Offline, you can pull control plane images in advance with kubeadm config images list and kubeadm config images pull, then point kubeadm init at an internal registry with --image-repository.
Cluster add-ons: an ingress controller (haproxy-ingress or the deprecated Ingress nginx), cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4, and Helmfile 1.0.0 or later.
Evaluation sizing: 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk. ARM is not supported yet.
Bundled stack: Element, Nextcloud, OX App Suite, Collabora, XWiki, Nubus, OpenProject, Jitsi and CryptPad, each under its own license such as AGPL-3.0 for Nextcloud and Nubus, GPL-3.0 for OpenProject and MPL-2.0 for Collabora.
Platform fit: openDesk is tested on kubespray clusters, not on OpenShift.

Confirm that your offline image and chart mirror covers every bundled component at the exact versions a release pins.

Deploying the stack offline on Kubernetes step by step

This sequence takes an empty enclave to a running openDesk instance with its external services, directory integration and acceptance tests verified inside the isolated network.

Build the cluster from images staged offline
On a staging host with internet access, run kubeadm config images list to get the control plane image names, then kubeadm config images pull to download them. Transfer the images into the enclave on approved media. Inside the enclave, run kubeadm init with the --image-repository flag pointing at your private registry, so the control plane pulls only from inside the network. Done when every control plane pod reaches the Running state and kubectl reports the node as Ready. Confirm the cluster version meets the openDesk requirement of v1.33 or later before going further.
Mirror container images and Helm charts into the enclave
Build an inventory of every container image and Helm chart that the openDesk release and its bundled components need, using the release files from the deployment repository. Pull them on the staging side, scan them with your own malware and vulnerability tooling, sign or hash them, and carry them across the boundary. Load them into the private registry and a local chart repository, then point the deployment at those locations. Done when a test pod pulls every image from the internal registry and no deployment step attempts an external address.
Install the cluster prerequisites
Install the components openDesk requires in the cluster: an ingress controller (haproxy-ingress, since Ingress nginx is deprecated), cert-manager with an internal certificate authority, and an RWO volume provisioner. Install Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later on the administration workstation. Done when each component reports healthy and a test certificate issues from the internal authority. Confirm that the cluster is a kubespray build, because openDesk is tested on kubespray clusters and not on OpenShift.
Stand up the external production services
For production, openDesk expects services outside the cluster: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV reachable over ICAP, object storage and a TURN server. Deploy each inside the enclave, or confirm that an existing internal service meets the stated versions, and record the connection endpoints and credentials in your secrets store. Done when each service accepts connections from the cluster network and the ClamAV ICAP endpoint returns a response to a test file. Ask the ZenDiS documentation and your Enterprise support scope which of these you must supply yourself.
Deploy the suite with Helmfile
From the deployment repository, set the environment values for your domain, the internal registry and chart locations, and the external service endpoints. Run Helmfile against the target environment to apply the releases, starting with a dry run to review the rendered manifests for any external URL. Apply the release and watch the pods come up. Done when all releases report deployed, the pods are Ready, and the web entry points load over the internal certificate. Record the release version so later upgrades follow the supported minor-version path.
Integrate the directory with LDAP, OpenID Connect or SAML
Connect the suite to your authoritative directory. openDesk includes Nubus for portal and identity management, and its federation documentation covers connecting an external identity provider. Nextcloud supports LDAP and Active Directory with directory credentials, and also documents OpenID Connect and SAML backends. Agree the attribute mapping and group rules with the directory owners before enabling sign-in. Done when a pilot user signs in with directory credentials, appears with the expected groups, and a disabled account loses access.
Run acceptance tests inside the enclave
Write acceptance tests that cover mail send and receive through the internal SMTP relay, file upload and sharing, opening and saving a docx, xlsx and pptx file in the web office, chat, video through the TURN server, and calendar invitations. Include a malware test file that ClamAV must block. Run the tests from a host inside the enclave and keep the results, configuration versions and image digests as evidence. Done when every test passes or has a documented, approved exception, and the signed-off results are stored with the deployment record.

How updates and malware scanning cross the air gap

Every update to an air-gapped openDesk or Nextcloud stack should follow one path: packages and container images are built or pulled on a staging side, scanned, signed off by a named approver, and only then carried across on media. The staging side is where the software supply chain is checked, so it needs its own change record. NERC CIP-013-2 is a useful reference for the verification step even outside the energy sector, since it asks procurement processes to address the integrity and authenticity of vendor software and patches. Confirm with your own security team which signature and checksum method they will enforce, and keep the approval evidence with each media batch.

Plan the cadence before the first transfer. openDesk plans major releases annually in Q3, minor releases monthly and patch releases on demand, and it supports only the latest minor version, so your enclave will need a standing monthly intake unless you accept an unsupported version. In-place upgrades between majors are not guaranteed, and skipping several minor versions may require intermediate steps, so ask ZenDiS or your DeployOpen contact for the upgrade path before you commit to a schedule. Nextcloud does not allow skipping major releases, so each upgrade moves one major version at a time, with a backup taken before every step and third-party apps disabled until each is confirmed compatible. Treat the backup as a gate in the transfer checklist, not an optional task.

Every file that enters the enclave, including email attachments and documents uploaded by users, needs malware scanning at the boundary and again on the platform. openDesk expects ClamAV to be reached over ICAP as an external production service, and Nextcloud All-in-One bundles ClamAV, so confirm which scanner your chosen deployment actually runs and where scan results are logged. Monitoring the enclave is a separate control: Security Onion ships full offline installs with its own rule updates delivered through airgap media, and Wazuh publishes an offline installation guide with an offline vulnerability repository. If your team hosts its own code, the GitLab offline environment documentation covers running self-managed instances and the security scanners without internet access.

Evidence assessors ask for in an air-gapped office deployment

Assessors reviewing an offline office deployment want proof of what was built, what crossed the isolation boundary, how it was kept current, and who touched it. The cards below cover the records that answer those questions. DeployOpen prepares this evidence, but independent auditors and certification bodies draw any conclusions from it.

Offline build record and image manifests

Record how the Kubernetes control plane and every application image were pulled before the isolation boundary was closed. For clusters, the kubeadm image list and pull steps give a reproducible starting point, and the private registry path used by kubeadm init should be documented. Keep an image manifest listing each image by digest, so an assessor can match what runs in the cluster to what was approved. Confirm with your assessor which build evidence they expect.

Transfer log with package integrity checks

Every package, image, rule set and chart carried across the isolated boundary needs an entry in a transfer log. Each entry should show the source, the reviewer, the checksum or signature verified before import, and the time of transfer. Unlogged media is the most common gap assessors find. Map this log to the software integrity and authenticity expectations in NERC CIP-013-2 if your organization is subject to it.

Upgrade and backup records

Keep a dated record of each upgrade, the version moved from and to, the backup taken beforehand, and the restore test result. Nextcloud requires upgrading one major version at a time and a backup before every upgrade, so the record should show that sequence was followed. openDesk expects in-place upgrades between majors are not guaranteed, so the record should note any intermediate steps. Ask your vendor or integrator to confirm each step against the release documentation for your version.

Vendor remote access logs

Where a vendor needs to reach the environment, assessors look for session logs that show who connected, through which intermediate system, when, and under what authentication. CIP-005-7 expects encrypted, multi-factor access through an intermediate system and the ability to detect and disable active vendor sessions. Test that a session can be terminated and record the test. Confirm the log retention period your regulator requires.

SBOM and component license inventory

A software bill of materials lists each component, its version and its license, so the license of every bundled piece is known before the deployment is accepted. openDesk, for example, is licensed Apache-2.0 at the deployment level, while bundled components keep their own licenses, such as AGPL-3.0 for Nextcloud and GPL-3.0 for OpenProject. Assessors also check that the inventory matches the images in the build record. Ask for the inventory in a machine-readable format and confirm it is generated for the exact versions you run.

Questions buyers ask before an air-gapped office deployment

What does an air-gapped office deployment cost, and what drives it?

Costs fall into one-time work and recurring work, and the split depends on who carries each piece. One-time items include design, integration with your identity and directory services, migration, hardening and the offline image pipeline that moves software across the boundary. Recurring items include infrastructure, storage and backup, staff or retainer time for patching, and any enterprise subscriptions you choose. The main drivers are user count, mail and file volume, the number of components, hardware in the isolated network, and how much of the work your own team performs. Ask every bidder for a line-item quote that separates software licensing, hardware, implementation, migration and support, and state which items are one-time and which recur. DeployOpen issues quotes only from a written scope.

How long does an offline Kubernetes office deployment take?

The timeline depends on the scope agreed in writing before work starts, so no fixed duration applies to every network. The schedule is shaped by the number of components, how many external services you must supply (such as PostgreSQL, Redis, an SMTP relay and ClamAV over ICAP), the readiness of the target Kubernetes cluster, the size of the mailbox and file migration, and the time your security review takes for each transfer into the enclosure. Evaluation deployments are faster than production rollouts because production expects supported, production-grade services and enterprise-level support choices. Request a phased plan with milestones for cluster readiness, offline image transfer, pilot users, migration waves and cutover, and confirm each one against your change calendar.

What must our team provide before a deployment starts?

Your team supplies the environment and the decisions that only your organization can make. Typical inputs include the isolated network design, a CNCF-certified Kubernetes cluster at the version the chosen openDesk release requires, storage classes, the ingress controller, certificate authority material, an SMTP relay and database hosts inside the enclosure, and access to the identity source you want to federate. You also define the accepted transfer procedure for software and updates, the named approvers for each transfer, the data classes in scope and the retention rules for mail and files. Confirm the exact hardware and version requirements with the vendor documentation for the release you plan to use, because these change between releases.

Can our own staff run an air-gapped office suite after go-live?

Yes, many organizations run the platform with internal staff, but the question is whether your team has the skills and capacity for the whole cycle. Day-to-day work includes monitoring, backup and restore tests, user administration, certificate renewal, and handling security findings. Upgrades require a planned transfer of new packages, testing in a staging enclosure and a rollback plan. Consider three options: a fully internal team, an internal team backed by a retainer for upgrades and specialist incidents, or a vendor-run model. DeployOpen offers implementation, hardening, backup, upgrade, documentation and support as separate scopes, and ongoing support is available as a retainer. Ask for the operating runbook and training as deliverables in any proposal.

Is Microsoft 365 Local or openDesk cheaper to operate offline?

Neither option has a universal answer, because cost depends on your existing licenses, hardware, staff and the components you need. Microsoft 365 Local runs Exchange Server and SharePoint Server on Azure Local, so you carry the hardware and the licensing for each server product and the operational work of keeping that stack current. openDesk is open-source with Apache 2.0 deployment automation, while each bundled component keeps its own license, so cost comes from infrastructure, required external services, the operating team and any Enterprise Edition subscription that ZenDiS recommends for production. Build a five-year model for both options with the same user count, storage, data volume and support level, then compare the recurring lines side by side. Ask each vendor to confirm which items are included in the price.

What do the Nextcloud Enterprise tiers and 100-user minimum mean?

Nextcloud Server is free to self-host under AGPL-3.0, so the minimum applies to the paid Nextcloud Enterprise subscription, not to the software itself. Nextcloud sells Standard, Premium and Ultimate tiers, and according to its pricing page each tier has a 100-user minimum. Standard includes one year of maintenance, Premium adds a maintenance lifecycle of five or more years, extended support hours and clustered instance support, and Ultimate adds support up to 24/7 with response times down to one hour. Organizations with fewer users can compare community operation with Nextcloud One managed hosting, which the pricing page limits to organizations under 100 users. Confirm the current tiers and per-user rates on the pricing page before you budget.

How are security updates and malware scanning handled offline?

Updates arrive as packages you verify and carry across the boundary, so the transfer process is a control in its own right. Plan for a staging enclosure where each release is installed and tested before production. For software integrity, check signatures and checksums against the vendor's published values and record each transfer under your supply chain process, which is the purpose of control CIP-013-2 in the NERC standards for energy sector organizations. Malware scanning of inbound files and mail should run inside the enclosure, for example with ClamAV connected over ICAP as openDesk expects for production. Nextcloud publishes a new major version every four months and supports each for one year, so the upgrade path is one major version at a time with a backup before each step. Ask the vendor how long each release is supported before you commit.

Sequencing the cutover from Microsoft 365 data

This sequence moves mail, files and sites into the air-gapped enclave in an order that keeps the source data intact until the target has been verified. Each stage ends with a check the migration owner signs off before the next one starts.

Confirm licensing and export rights in the source tenant
The migration lead, working with the Microsoft 365 global administrator, confirms which accounts hold the E3 or E5 license that Purview eDiscovery export requires. Without that license the mailbox and document exports described in the following steps are not available, so the check comes first. Record which accounts can run exports and who will review the output. The check is complete when a named exporter has run a small test search in the source tenant and the export completes.
Inventory mailboxes, sites and files to move
The migration lead and data owners list every mailbox, SharePoint site, OneDrive account and Teams file location in scope, and mark items that carry legal hold or retention requirements. This inventory sets the export scope and tells you which items must be proven in the enclave before the source is cut off. The output is a signed inventory with one row per workload and an owner for each. Confirm the list against the organization's records retention schedule before any export starts.
Export mailboxes to PST in scoped batches
The eDiscovery administrator creates Purview search jobs for each mailbox batch and exports the results as PST or .msg files. Export packages expire 14 days after creation, so the team downloads and copies each package to the staging area within that window and records the package name and creation date. Each batch is complete when the file count and size in the staging area match the export report. Failed or expired packages are rerun and logged rather than patched by hand.
Export files with version history
The eDiscovery administrator exports SharePoint and OneDrive content as native documents and selects version history where the retention policy requires it. The staging team checks that folder structure, file names, metadata and version counts survive the transfer, because later audits depend on them. Transfer the packages to the enclave media through the approved cross-domain process, and record a hash for each package. The step closes when hash checks pass on the enclave side for every batch.
Import and verify data in the enclave target
The platform team loads mail into the target groupware, such as OX App Suite, and places files in Nextcloud or openDesk, then runs reconciliation scripts or sampling against the export inventory. Mail counts, folder trees, file counts and version histories are compared with the source reports. Mismatches are recorded as exceptions with an owner and a fix. The step is complete when the data owner signs the reconciliation report for each workload.
Run parallel access and user acceptance tests
Pilot users in the enclave test sending and receiving mail, opening and editing documents, sharing files and confirming that directory-based sign-in works. The team runs these tests before any user is moved, and it records defects in a tracked list. Where the identity provider or directory is federated, the identity team confirms the login path inside the enclave. The step closes when the pilot group signs off on each core task and no open defect blocks cutover.
Freeze source changes and cut over users
The change board sets a freeze window in which no new mail or file changes are made in the source, and the migration lead runs a final delta export for items created after the first snapshot. The delta is imported, reconciled and signed off before users are switched to the enclave. Once users are moved, the source tenant is kept read-only until the retention and legal hold obligations are confirmed. The output is a cutover record with timestamps, delta counts and the approver for each workload.
Retain source evidence and close the migration
The compliance lead keeps the export packages, hash records, reconciliation reports and cutover record under the organization's retention rules, since packages in the source tenant do not persist beyond their expiry. The team confirms with legal and records staff which copies must be held and for how long before any source license is ended. The migration closes when the evidence set is filed and the data owners confirm their workloads are live in the enclave.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For Microsoft 365 alternative for air-gapped networks, the work starts with a written scope that fixes which workloads move offline and how updates and malware scanning enter the network.

How we scope

Written, fixed-scope agreement covering which mail, file and office workloads move into the isolated network
Inventory of Kubernetes version, storage, database and SMTP needs against the openDesk requirements
Decision between openDesk, Nextcloud with Collabora Online and OX, based on user count and identity sources

How we build

Offline Kubernetes cluster and private image registry set up so every container image is staged before cutover
Production-grade PostgreSQL, Redis, object storage, SMTP relay and ClamAV integration configured inside your boundary
Import path for approved update bundles, with each package checked for integrity before it crosses the boundary

How we hand over

Documented deployment, configuration and upgrade runbooks written for your own operations staff
Evidence pack of configuration, access controls and update records for your compliance assessors, which DeployOpen prepares but auditors certify
Backup and restore tests run and recorded before the environment is accepted

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Upgrade planning follows the one-major-version-at-a-time path that Nextcloud and openDesk require
Confirm with your vendor which enterprise edition, support level and patch channel your environment needs