Choosing an Exchange alternative for an air-gapped network
Several open-source groupware platforms can run on a disconnected network, but each one needs its packages, container images, appliance images and license material carried across the boundary by hand. The choice is not only about which mail server works offline. It is about which platform your site can keep patched without a live feed, which clients your users need, and whose license terms allow offline installation and updates. Exchange Server Subscription Edition and Exchange Online do not solve the disconnected case by themselves: Subscription Edition still requires licensing and updates that you must bring in through your own process, and Exchange Online needs connectivity to the cloud service.
The three candidates in this topic differ in how they fit an offline site. OX App Suite v8 is delivered as Helm charts that reference container images, so you must mirror the Kubernetes control plane, Istio, Redis 7.4.x, MariaDB and the App Suite images into a private registry before cutover, and confirm the storage tier (NFS or object storage) is local. grommunio ships as an ISO or OVA appliance, which makes the offline bundle simpler to verify, but you still need to confirm how its updates reach the appliance. Zimbra's open-source core is distributed as builds you compile yourself, so the build chain and dependencies are part of your transfer set. Ask each vendor in writing which artifacts they will supply for offline updates and whether that delivery is part of the license you are buying.
Treat the decision as a checklist: confirm license terms for offline use in writing, define how each package and image is verified for integrity and authenticity before it enters the enclave (a control that NERC CIP-013-2 addresses for supply chains in energy sectors), and test an update cycle end to end on a staging enclave. Also confirm mail relay, antivirus signature updates and any license activation method that works without internet access, because these are the functions most often missed at design time.
What an air-gapped mail deployment requires
An air-gapped mail platform has to install, update, check antivirus signatures and activate licenses without a route to the internet. Every package, signature and patch that crosses the boundary must be verified, and any vendor access must be tightly controlled. The cards below cover these constraints in the order a project team usually meets them.
No internet dependency at install time
Confirm that every component you plan to use installs from media or a private registry you control. For a Kubernetes-based stack such as OX App Suite v8, this means pre-staging container images, Helm charts, Redis 7.4.x, a supported MariaDB release and Istio or ingress-nginx in an internal registry. Ask the vendor for a complete bill of materials, because a single pull from a public repository during install breaks the isolation assumption.
Updates and antivirus signatures
Mail filtering depends on current antivirus and spam signatures, and those do not update on their own in a disconnected network. Plan a scheduled import path for signature files and vulnerability data, and confirm with the vendor whether the mail scanner can read signatures from a local source. Document who approves each import and how long a stale signature set is tolerated.
License activation and offline entitlement
Some vendors need an online check to activate a license or confirm entitlement. Ask in writing how activation works offline, whether keys are issued for an isolated environment, and what happens at renewal. Open-Xchange states that the right to use certain modules may depend on the license agreement, so confirm that the modules you need are included before you plan the network design.
Supply chain verification across the boundary
NERC CIP-013-2 requires utilities to set procurement processes that address verifying the integrity and authenticity of vendor software and patches. In practice, each package carried across the isolated boundary needs a checksum or signature check and a recorded approval. Ask the vendor how releases are signed, where the signing keys are published and whether the release process can be audited by your team.
Controlled vendor remote access
NERC CIP-005-7 requires Interactive Remote Access to high and medium impact BES Cyber Systems to pass through an Intermediate System, use encryption and multi-factor authentication, and allow active vendor sessions to be detected and disabled. Plan a jump host inside the perimeter for any vendor support, and log every session. Confirm that your implementation partner and the platform vendor accept these conditions before work starts.
Confirming which frameworks apply
The NERC CIP standards apply to utility BES Cyber Systems. Organizations in banking, healthcare, public sector or defense have their own obligations, which may include CMMC under 32 CFR Part 170 or FedRAMP scope rules for cloud services. Ask your compliance lead to map which frameworks govern the mail system before you design the boundary, because the answer changes the evidence you must keep.
How OX App Suite, grommunio and Zimbra fit disconnected networks
OX App Suite v8 is delivered as Helm charts that reference container images and is designed to run on Kubernetes. An air-gapped build therefore starts with a cluster and an image supply chain that exist entirely inside the isolated network, and the OX App Suite requirements define the components that must be staged in advance.
- Kubernetes and Helm: Kubernetes versions N-1 and N-2 are supported, and the charts require Helm 3.17.0 or newer. The kubeadm documentation shows how control plane images can be pulled ahead of time and pointed at a private registry, which is the same pattern to apply to OX images.
- Istio and ingress: Istio is required, with support for the latest release plus two prior versions. Where Istio cannot be used, a basic ingress-nginx option exists. Both the service mesh images and the chosen ingress path must be mirrored before installation.
- Redis 7.4.x and MariaDB: Redis 7.4.x handles caching and session storage, deployed by default through the littlered operator. The primary store is MariaDB with InnoDB, in versions 10.6.x, 10.11.x, 11.4.x or 11.8.x, and Galera Cluster is supported. Operator images and database packages need offline copies.
- Distributed file system: OX Drive files and PIM attachments must sit on NFS for small to mid-size deployments or on object storage such as Ceph RadosGW or Scality RING for larger ones. Storage is a platform you also operate without internet access.
Ask Open-Xchange which artifacts its offline bundle includes and how chart and image updates cross the boundary.
grommunio ships as an appliance built on openSUSE, delivered as an ISO or OVA image with a setup wizard. This reduces the number of components to stage compared with a Kubernetes build, although grommunio also documents manual and container installation for teams that prefer those paths. The grommunio documentation covers the administrator procedures you will need to verify offline.
- Appliance images: The ISO or OVA is the single artifact to transfer across the boundary. Verify its hash and provenance on arrival, since integrity checks of this kind map to the supply chain expectations in NERC CIP-013-2.
- Gromox server: Gromox is the central groupware server, licensed under AGPL-3.0. It implements RPC/HTTP, MAPI/HTTP, Exchange Web Services, IMAP, POP3 and an SMTP local delivery agent, and it can scale out across multiple hosts.
- Outlook and mobile clients: grommunio states that organizations can keep existing Outlook clients through MAPI/HTTP, EWS and Exchange ActiveSync support. grommunio-sync serves native iOS and Android clients, and grommunio-dav provides CalDAV and CardDAV.
- Bundled components: MariaDB holds user metadata and SQLite stores individual mailboxes. The chat, meet, files and office components are forks of Nextcloud, Jitsi and ONLYOFFICE, so confirm which of them you enable and which packages they pull during updates.
- Support and licensing: The free Community package is limited to 5 users and carries no manufacturer support. Paid licenses are sold through certified partners, so ask whether support covers package delivery to disconnected sites.
Confirm how updates arrive as offline repositories and how support entitlements are activated without outbound access.
Zimbra Collaboration is a different case because its open-source core is available only as FOSS builds that you compile yourself. Downloadable Zimbra 10 packages need a license key, so the air-gapped plan depends on which path you take and on who will carry its maintenance.
- FOSS build path: Compiling from source inside a controlled build environment means your team handles dependency fetching, patching and rebuilds. The cost is mainly staff time and build infrastructure, and the security fixes you apply are only as current as your own pipeline.
- Zimbra 10 packages: Installing from packages requires a license key. Confirm whether activation can be completed on a server with no route to the licensing service, and whether the key can be installed from offline media.
- Feature boundaries: Confirm in writing which Outlook integration, ActiveSync and archiving features are available in the free build and which sit in paid tiers. Make this decision before the design is fixed, because it changes the client and retention plan.
- Vendor-delivered updates: Packages for the licensed build cross the boundary on media. Ask the vendor for its offline update process, how patches are signed, and how often security fixes are issued.
- Ongoing ownership: Name the team that will track upstream changes, rebuild, retest and document each release for the isolated environment.
Request the written terms for offline installation, license key activation and update delivery before selecting Zimbra for a disconnected network.
Air-gapped support is often a paid-edition feature in this market. Mattermost lists air-gapped deployment in Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, Metabase offers it only on its Enterprise plan, and Element offers a separate Sovereign edition for air-gapped use. Buyers should not assume that a community license covers disconnected operation, and the same question applies to every option on this page.
- Edition check: Confirm in writing which edition permits disconnected operation for each option and whether the features you need are included in that edition.
- Update delivery: Ask how patches, chart updates and image bundles reach the network, how they are signed, and how long an offline bundle stays valid for installation.
- License activation: Ask whether activation or support entitlement requires outbound connectivity, and request the offline procedure in writing with the expected steps.
- Provenance evidence: For software integrity controls such as NERC CIP-013-2, request hashes, signatures and provenance records for every artifact carried across the boundary, and keep them with the change record.
- Vendor access: If the network falls under NERC CIP-005-7, remote vendor access must pass through an Intermediate System with encryption and multi-factor authentication. Confirm how vendor support sessions will be brokered and disabled.
Put these answers into the written scope before any build starts, so the design is tested against the terms that will apply in production.
Trade-offs across air-gapped mail options
This table compares OX App Suite, grommunio and Zimbra for disconnected Exchange replacements across offline installation, platform, client support, license terms, support cadence and migration. Read each row as a question to answer with the vendor before procurement, because air-gapped support is often tied to specific editions. The main takeaway is that the migration path and license activation determine how practical a disconnected deployment will be.
| Trade-off | OX App Suite | grommunio | Zimbra |
|---|---|---|---|
| Offline installation path | Helm charts reference container images; Kubernetes can be built offline by pre-pulling images and pointing kubeadm at a private registry | Delivered as ISO or OVA appliance images with a setup wizard; confirm how offline package updates are applied | Open-source core is available only as FOSS builds you compile yourself; confirm offline packaging and update steps |
| Platform | Kubernetes with Istio, Redis 7.4.x, MariaDB and NFS or object storage; Helm 3.17.0 or newer | openSUSE-based appliance, with manual and container installation also documented | Confirm supported operating systems and hosting model with Synacor for disconnected sites |
| Outlook client support | Confirm Outlook desktop options and shared calendar behavior with Open-Xchange before cutover | MAPI/HTTP, EWS and Exchange ActiveSync let existing Outlook clients connect natively | Outlook integration sits in the Professional tier; confirm what it includes |
| Mobile client support | Exchange ActiveSync connector available; confirm iOS and Android behavior in your version | grommunio-sync provides Exchange ActiveSync for native iOS and Android clients | ActiveSync sits in the Professional tier; confirm licensing and device coverage |
| License terms | UI and middleware mirrors are AGPL-3.0; certain modules may carry separate fees set in the license agreement | Gromox is AGPL-3.0; free Community package for up to 5 users without manufacturer support | Zimbra 10 downloadable packages need a license key; confirm how keys are validated without internet access |
| Support and release cadence | Standard releases supported for 12 weeks; LTS supported until the next LTS plus six months; v8.47 is the current LTS | Paid licenses are sold through certified partners; confirm support levels and offline update access | Confirm support tiers, patch delivery and how security fixes reach a disconnected network |
| Migration path from Exchange | Export and sync methods are required; IMAP alone leaves calendars and contacts behind; confirm tooling for your Exchange version | exchange2grommunio exports each mailbox to PST and imports over SSH; requires the same LDAP or Active Directory | Confirm Exchange import tooling, including calendars, contacts and archive mailboxes, with the vendor |
| Air-gapped activation and edition fit | Confirm which edition and support terms cover disconnected sites before design starts | Confirm whether offline activation applies to the paid tier you need | Confirm whether the license key and any feature tier work fully offline |
How to deploy mail on a disconnected network
This sequence moves a mail platform, its Kubernetes or appliance base, and its updates into a network with no internet path, then proves the mailbox migration works before any user depends on it.
Build and test the staging environment online
Your team builds the full stack on a connected staging network first, using the same versions you plan to run offline. For OX App Suite v8, this means a Kubernetes cluster that meets the documented version rules, Istio or the basic ingress-nginx option, Helm 3.17.0 or newer, Redis 7.4.x, a supported MariaDB release, and a distributed file system for OX Drive and attachments. For grommunio, it means one appliance image installed from the ISO or OVA with the setup wizard. Confirm each component version against the vendor's requirements page before you pull anything. The step is done when the staging stack starts, logs in with a test account, and sends and receives mail.
Mirror images, charts and packages into a private registry
Copy every container image, Helm chart, operating system package and appliance update your deployment references into a private registry or artifact repository inside the disconnected network. Build the list from the staging deployment rather than from memory, because dependent images such as operators and sidecars are easy to miss. For Kubernetes control plane images, run kubeadm config images list and kubeadm config images pull on the connected side, then keep the image archive for transfer. Ask the vendor which images and chart versions their offline guide lists for your release. The step is done when a manifest of every artifact, with its checksum, matches the registry contents.
Initialize the cluster from the private registry
On the disconnected network, point kubeadm init at the private registry with the --image-repository flag so the control plane pulls only from internal sources. Then install the Helm charts against that registry and confirm no deployment manifest refers to a public hostname. Check that nodes can reach the internal registry, the storage back end and the directory service, and nothing else outbound. The step is done when all pods report ready and a failed test pull from an external registry is blocked by the network controls you already run.
Transfer artifacts through the approved one-way process
Move the image archives, chart bundles, package sets and checksum manifests across the boundary using the transfer process your security team has approved for that enclave. Scan the media on the connected side and again after it crosses, and verify signatures or checksums against the values recorded in staging. Record who performed each transfer and when. Standards such as NERC CIP-013-2 ask that vendor software and patches be verified for integrity and authenticity before use, so keep those verification records as evidence. The step is done when the imported artifacts match the signed manifest and the transfer log is complete.
Restrict mail relay and plan antivirus signature updates
Configure the mail relay so it accepts and delivers only to internal hosts and internal domains, with no route to external recipients unless a documented gateway is in place. For antivirus, stand up an internal signature mirror, feed it from the approved transfer process, and point the mail scanner at that mirror only. Confirm the update procedure with your antivirus vendor, because signature delivery methods differ by product. The step is done when a test message to an external address is refused or held, and a test message with a known test signature is quarantined by the scanner.
Activate licenses or confirm the offline path
Check how the chosen platform licenses itself before cutover. Some vendors offer air-gapped deployment only in paid editions, so confirm the edition named in your contract includes it. Ask the vendor whether activation works offline and what file or key they issue. Note that OX App Suite's documentation says some modules or features may be subject to custom packaging or separate fees set in the license agreement, so list each module you plan to use. The step is done when you hold written confirmation of the edition and the offline activation procedure, and a test activation succeeds without internet access.
Rehearse the mailbox export and import
Run the full mailbox migration in staging before any production move. For grommunio, this means the exchange2grommunio flow: New-MailboxExportRequest writes each mailbox to PST on a shared folder, then gromox-pff2mt and gromox-mt2exm import it over SSH. Confirm that grommunio uses the same LDAP or Active Directory as Exchange, and run the script from an elevated Exchange Management Shell on a supported Windows Server version. Review the success and failure log, rerun failed mailboxes, and check folder counts and calendar items for a sample of users. For other platforms, follow the vendor's documented migration path. The step is done when a rehearsal completes with reconciled counts and each user confirms their calendar and folders in the target client.
Verify each step with the vendor's offline documentation
Before each step runs in production, check it against the offline or air-gapped guide published for your exact product version, since commands, image lists and update procedures change between releases. The Kubernetes guidance, GitLab's offline environment documentation, and grommunio's administrator documentation are examples of the sources to compare. Record any deviation in your runbook and get the vendor's agreement for it. Ask your implementation partner or the vendor to confirm the offline update method for future releases, because each update repeats the import and verification cycle. The step is done when the runbook cites the exact documentation version used and every deviation has a named approver.
Evidence that an air-gapped mail system is controlled
An assessor or regulator reviewing a disconnected mail system will ask for records that show what entered the network, how it was verified, and who changed what. The cards below list those records, with the control context that makes each one useful. DeployOpen prepares these artifacts, but auditors and certification bodies issue any opinion on them.
Software bill of materials
A software bill of materials lists every component in the mail stack, including the OX App Suite or grommunio release, container images, Helm charts, MariaDB, Redis and the operating system packages. Keep it versioned alongside each release so an assessor can match what runs in production to what was approved. Check that it covers transitive dependencies, not only top-level packages, and that it is regenerated for every offline update.
Hash records for transferred packages
Every package, image and rule set carried across the isolated boundary should have a recorded cryptographic hash, computed on the source side and verified on the receiving side before installation. This is the practical control behind verifying software integrity and authenticity under NERC CIP-013-2, where that standard applies. Store the hash ledger outside the mail network so it cannot be altered by the same people who administer the mail servers.
Transfer and media custody logs
Record each media transfer with its date, the approver, the sender, the receiver, the media identifier and the verification result. A chain of custody record shows that no unapproved media reached the mail network. Confirm with your security office which transfer steps need dual control and whether removable media must be scanned before it reaches the offline update host.
Approved offline update procedure
Write down how mail server, database, operating system and antivirus signature updates are obtained, tested in a staging environment, approved and applied without internet access. Assessors look for a documented rollback path and evidence that the procedure was followed for the last update. Ask the vendor which release notes, signed artifacts and offline repository options it provides for disconnected installs.
License activation and entitlement records
Where the chosen platform uses license keys or entitlement checks, keep the activation requests, the offline activation responses and the entitlement terms that cover each module in use. OX App Suite's license agreement may set custom packaging, limitations or separate fees for certain modules, so the record should show which features are licensed. Confirm with the vendor how activation works when the network has no route out.
Relay, access and migration logs
Keep the SMTP relay and access configuration under version control, with change records for allowed senders, network ranges, authentication settings and directory integration. For migrations from Exchange, keep the export and import logs that show each mailbox exported, imported and any failures, since the grommunio script logs successes and failures so runs can resume. Retain these logs with the same retention rules applied to other security records.
Questions buyers ask about air-gapped Exchange replacements
What does an air-gapped Exchange replacement cost to run?
The cost has four main parts: the platform, storage, a support subscription and the migration work. Software licensing varies by vendor. grommunio publishes per-user prices: a free Community package for up to 5 users without manufacturer support, Basic at 1.99 euros and Plus at 3.99 euros per user per month from 6 users, Business at 5.49 euros from 50 users, and custom Enterprise pricing from 1,000 users, sold only through certified partners (grommunio pricing). OX App Suite code is published under AGPL-3.0, but its Operations Guide says module use may carry separate fees set in the license agreement, so ask for that in writing. Recurring costs are subscriptions, infrastructure and staff time. One-time costs are migration, hardening and directory integration. Ask every quote to split these lines.
Can our own team run an air-gapped mail platform alone?
A capable team can run it alone if it already has Linux, directory and mail administration skills and can patch systems without internet access. OX App Suite v8 runs on Kubernetes and is delivered as Helm charts, which requires Helm 3.17.0 or newer, Istio or a basic ingress-nginx option, Redis 7.4.x and MariaDB. Persistent data needs a distributed file system such as NFS, or object storage such as S3, Ceph RadosGW or Scality RING for larger deployments. grommunio ships as an openSUSE appliance, which reduces platform work, but it still needs LDAP or Active Directory. Plan for ongoing operations: monitoring, backups, upgrades and security reviews. DeployOpen plans, implements, hardens, documents and supports these platforms in your network under a fixed scope agreed in writing, with retainers for ongoing work.
How long does an air-gapped Exchange migration take?
No researched source gives a duration for this work, so ask for a timeline in the written scope rather than relying on a general estimate. The pace is usually set by the number of mailboxes and their size, how long transfer media takes to approve, how many boundary crossings the plan needs, how directory integration is built, and how many test cycles the security team requires. grommunio's migration script runs mailbox by mailbox and logs successes and failures so failed runs can resume, which affects how you schedule waves. For OX App Suite, a standard release is supported for 12 weeks, so upgrade windows must fit that cadence. Ask the implementer to show milestones, dependencies and what the client must provide at each step.
Can Zimbra, grommunio or OX App Suite be updated offline?
Each product needs its own offline update path, and you should confirm it with the vendor before you commit. For OX App Suite, the Helm charts reference container images, so the images and charts must be mirrored into an internal registry and rolled out from there. Support timing matters: a standard release is supported for 12 weeks, an LTS release until the next LTS plus six months, and v8.47 (FCS 2026-03-18) is the current LTS per the OX support commitment. For grommunio, the appliance is delivered as ISO or OVA images, so ask how updates are packaged for disconnected use. For Zimbra, confirm which packages are downloadable offline and whether a license key is needed. Verify the integrity of every package before it enters the enclave.
How does license activation work without internet access?
The researched sources do not describe offline activation for these products, so ask the vendor or partner to document it before purchase. Confirm the activation method, such as an offline key file or a license server inside your network, how renewals are applied, how license state is reported, and what happens at expiry. Air-gapped capability is often tied to paid editions: Mattermost lists it in Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, and Metabase offers it only on its Enterprise plan, so the same check applies to mail platforms. For grommunio, licenses are sold through certified partners, so the activation process should come from that channel. DeployOpen is not a grommunio or OX partner, so ask the vendor directly about licensing terms.
Can mailboxes move across an air-gapped boundary safely?
Mailbox data can move through export and import, but the transfer path is the hard part. grommunio's exchange2grommunio.ps1 script exports each Exchange mailbox to PST with New-MailboxExportRequest, then imports it over SSH with gromox-pff2mt piped into gromox-mt2exm, logging results so runs can resume. It requires the same LDAP or Active Directory on both sides and a shared folder that Exchange can write to and the grommunio server can mount. In an isolated network, that share must sit inside the enclave, so PST staging needs an approved cross-boundary process. Check hashes and package integrity at each crossing, and record every transfer. The grommunio migration guide lists the script requirements.
What do NERC CIP standards require for remote access and software imports?
These requirements apply only if your organization is subject to NERC CIP for BES Cyber Systems. CIP-005-7 requires all interactive remote access to high and medium impact systems to pass through an Intermediate System with encryption and multi-factor authentication, and it requires methods to detect and disable active vendor remote sessions. CIP-013-2 requires supply chain processes that address verification of software integrity and authenticity for vendor software and patches, which applies directly to packages carried across an isolated boundary. Read both in the CIP-013-2 standard and the CIP-005-7 standard. DeployOpen prepares systems, controls and evidence for assessments, but auditors and certification bodies issue the findings.
What does DeployOpen cover in an air-gapped mail engagement?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own networks, including air-gapped ones. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Typical work covers the platform build, storage and database layout, directory integration, mail relay, offline update procedures, backups and the mailbox migration plan. DeployOpen also prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ongoing support, upgrades and continuous security testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope.
What changes for users and administrators after cutover
Plan coexistence before cutover, because an air-gapped network rarely moves every user on the same day. Old and new mail systems can run side by side only if the directory, SMTP routing and free/busy lookups between them are designed for that period. grommunio's migration documentation expects the target to use the same LDAP or Active Directory as Exchange, so user identities stay stable while mailboxes move. Confirm with each vendor how free/busy and out-of-office data behave when some users sit on Exchange and others do not. Test that behavior in a lab enclave before the first production wave.
Outlook users notice the server change only if the client protocol changes with it. grommunio states that existing Outlook clients can stay in place through its MAPI/HTTP, EWS and Exchange ActiveSync support, but the depth of that support for shared calendars and delegate permissions must be verified against your own Outlook build. OX App Suite is a different case, because its groupware is delivered through its own web client and the protocols it exposes must be confirmed for your Outlook version before you commit. Calendars and delegates are the items most likely to break. Build a test matrix with a delegate pair, a shared mailbox and a resource calendar, and check each one after the PST import or sync cutover.
Several features depend on connectivity that a disconnected network does not have, so list them before cutover. External calendar invitations need a relay path that reaches outside recipients, which in an isolated enclave usually means an approved gateway the security team has accepted. Update checks, vulnerability feeds and antivirus signatures also stop unless they arrive through an approved media process. Wazuh's offline vulnerability repository and Security Onion's airgap mode, which updates from newer ISO media, show the pattern the operations team should copy for the mail stack. If you run OX App Suite v8, its Kubernetes, Istio, MariaDB, Redis and distributed file system dependencies each need an offline update path, and the Helm 3.17.0 requirement is a version to pin in your bundle.
How DeployOpen deploys mail under an air-gapped constraint
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own air-gapped network. For mail, that means scoping the groupware, the offline update path for every package and image, and the evidence an assessor will ask for before any Exchange workload moves.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which mailboxes, directory links, relay paths and license activation steps are in or out of the air gap.
- Scope records how antivirus signatures, patches and container images are carried across the isolated boundary.
How we build
- We build the chosen groupware in your environment, whether OX App Suite on Kubernetes or a grommunio appliance, with no internet dependency.
- We set up an internal mirror for container images, Helm charts and packages, and document each transfer step for review.
- We test mail relay, directory integration, Outlook or mobile client connectivity and the migration path from Exchange before cutover.
How we hand over
- Handover includes architecture notes, runbooks for offline updates, backup and restore, and the list of accepted limitations.
- We prepare configuration, access control and logging evidence that your own auditors or certification bodies can review.
- Documentation states which steps the client repeats for each update cycle, so operations staff can run them without DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Upgrade work covers vendor release cadence, the offline transfer of each new release, and regression testing of mail flow.
- Confirm with your own security and compliance teams which controls, licenses and standards apply to your network before scoping.
