Self-hosted email in air-gapped networks: why the build changes
Picture a team that must give users mail and calendars on a network with no internet route at all. On that network the build changes in four ways: there is no public DNS for MX, SPF, DKIM or DMARC, no outbound relay to a smarthost, patches and spam rules arrive only by physical or approved transfer, and every certificate has to come from an internal certificate authority that clients already trust. The mail protocols themselves, IMAP, SMTP, CalDAV and CardDAV, do not change. The short answer on platforms is that the candidates are the same ones used online, such as Stalwart, mailcow or OX App Suite, but the decision turns on whether each one can be installed and updated without reaching the internet. That question has to be answered per product and per edition, not assumed from the open-source license.
The hard parts are the offline supply chain and the boundary, not the mailbox server. Every container image, package, Helm chart, antivirus signature and anti-spam rule set must be pulled on a connected system, checked for integrity and authenticity, and carried across the gap under a documented procedure. The NERC CIP-013-2 standard, which addresses supply chain risk management for vendor software and patches in the electric sector, shows the kind of control auditors expect for that transfer step, even if your sector has no such rule. Plan a repeatable update cycle with a named owner, a staging copy of the mail stack and a rollback path. At the boundary, decide early which messages may cross, through what gateway, and who approves exceptions, because that policy shapes the whole design.
Air-gapped support is often a paid-edition feature, so treat it as a procurement question rather than a configuration detail. Mattermost lists air-gapped deployment in its Enterprise Advanced plan, and Plane offers a separate Airgapped edition on its own codebase. Element offers a Sovereign edition for air-gapped deployments. Confirm in writing with each vendor which edition, license terms and update channel support disconnected operation, and whether offline updates are included or billed separately. For OX App Suite, Open-Xchange states that certain modules may be subject to custom packaging or separate fees set in the license agreement, so ask for that list before scoping the build. Do not assume a free community release covers an offline deployment.
Which requirements shape an air-gapped mail build
This table maps each requirement family to the source that drives it, what it means for an internal-only mail and calendar build, and where teams most often misread it. Read it as a set of questions to confirm with your assessor and your own policy owners, because several sources set outcomes rather than prescribing products. The main takeaway is that the offline image process and package integrity checks are engineering tasks, while retention and audit obligations depend on your regulator and must be confirmed separately.
| Requirement | What it means for the mail build | Evidence an assessor will expect | Where it usually fails |
|---|---|---|---|
| Offline container images (Kubernetes kubeadm pattern) | Mirror every container image the mail stack needs into an internal registry before cut-over, and point the installer at that registry instead of a public one. | Image manifest with versions, the registry location used at install, and a record of the import process. | Images pulled on an internet-connected host are copied over without a manifest, so the build cannot be reproduced. |
| Offline self-managed pattern (GitLab offline guidance) | Treat the mail platform's own updates, licenses and dependencies as a separate offline delivery path, with a documented bundle and install procedure. | Runbook for offline install and upgrade, plus confirmation of which features need online services. | Features that call external services (license checks, remote scanners, hosted rules) fail silently or are disabled without a plan. |
| Software integrity for packages carried across the boundary (NERC CIP-013-2) | Verify the integrity and authenticity of every package, patch and signature file before it crosses the isolation point, and record the verification. | Hash or signature checks, a transfer log, and vendor procurement records covering patches. | Teams check the download once but not the copy that reaches the isolated network, or accept unsigned rule files. |
| Interactive remote access (NERC CIP-005-7) | If vendors or administrators reach the mail platform remotely, route sessions through a controlled intermediate system with encryption and multi-factor authentication, and be able to disable vendor sessions. | Access architecture diagram, MFA records, and procedures for detecting and ending active vendor sessions. | Support engineers use direct remote tools or shared administrator accounts during incidents. |
| Internal DNS and certificate authority | Run internal name resolution for mail hosts, MX-equivalent routing and client autodiscovery, and issue certificates from an internal CA trusted by all clients and servers. | CA hierarchy and root distribution record, certificate inventory, and internal DNS zone records. | Clients that expect public certificates fail, and certificate renewal depends on a CA that is not monitored. |
| Antivirus signatures and spam rules | Signature databases and filtering rule sets are delivered as offline bundles on a fixed schedule, with age and version checks before they go live. | Update logs showing source media, version and date, and a rollback record. | Signatures or rules age out because nobody owns the import step, leaving filtering blind to new threats. |
| Audit logging of mail activity (HIPAA 164.312(b), SEC 17a-4 context) | HIPAA requires audit controls that record and examine activity in systems holding ePHI. SEC 17a-4 requires broker-dealers to preserve business communications for not less than three years. Confirm which applies to your mail and where the archive sits. | Audit log retention settings, review procedures, and a documented archive or journaling design where a retention rule applies. | Teams assume the mailbox server is the record, or export logs to a host that is not itself protected or retained. |
| Transmission security for ePHI (HIPAA 164.312(e)(1)) | Inside an isolated network, confirm that mail and client traffic is encrypted and that any cross-boundary exchange has a documented, approved method. | Protocol configuration showing enforced TLS, and the approved exchange procedure. | Plain protocols remain enabled on internal listeners because nobody reviewed them after installation. |
Which open-source mail platforms fit an air-gapped network
Three open-source options cover most internal-only mail needs, but they differ sharply in footprint and in how air-gapped support is licensed. Each card sets out where the platform fits, what must be staged before the network is disconnected, and which licensing questions to settle with the vendor first.
Stalwart for lean internal mail
Stalwart is an all-in-one server for IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV, licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs. Its small component count suits an isolated network with a limited number of administrators. Before disconnecting, stage the container or binary, the spam and antivirus data you will need, and the internal certificate chain. Confirm with the vendor whether the Enterprise License is required for your support and update model, and which features sit behind it.
mailcow for Docker-based teams
mailcow-dockerized is a GPL-3.0 bundle of mail, webmail, calendar and contacts services that runs on Docker. It fits a single-site internal network where the team is comfortable operating Docker Compose stacks. Plan for an offline image registry, a local mirror of the update package and a process to carry signed updates across the boundary. Confirm which bundled components pull external resources at start-up and how the project documents running without internet access.
OX App Suite v8 on Kubernetes
OX App Suite v8 is delivered as Helm charts on Kubernetes, which is a strong fit for large or multi-site estates that already run a platform team. Helm 3.17.0 or newer is required, Istio is needed unless you use the basic ingress-nginx option, and MariaDB, Redis 7.4.x and a distributed file system must be present. Every container image, chart and database package must be mirrored into the enclosed network. Choose the LTS line deliberately, since the Support Commitment ties each release to a fixed support window.
Storage and database prerequisites
OX App Suite stores OX Drive files and PIM attachments on NFS for small to mid-size deployments, or on object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. MariaDB with InnoDB, in one of the supported 10.6.x, 10.11.x, 11.4.x or 11.8.x lines, holds primary data. Both must be sized, backed up and restored inside the boundary, because no vendor service will be available to fall back on. Confirm the supported Galera Cluster topology and the object storage product before you commit hardware.
Licensing of modules and editions
The OX App Suite Operations Guide states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Open-Xchange publishes AGPL-3.0 mirrors of the App Suite UI and middleware, but that does not decide what your contract includes. Ask for a written list of modules, support tiers and air-gapped entitlements before scope is agreed. Stalwart's Enterprise License and mailcow's GPL terms raise the same question in different forms.
How to keep mail, antivirus and spam rules current offline
Every update to the mail stack should follow one chain: pull and verify on a connected staging side, carry across an approved path, import into a private registry or repository, then test before production. Staging is where the mail server images or packages, antivirus signatures, and spam rule sets are downloaded, checked against the vendor's published hashes or signatures, and assembled into a single transfer set. Nothing reaches the isolated network unless it has passed through that staging step. For a containerized mail stack, the staging side should also hold the base images and any operator or chart dependencies, so the isolated side never needs to resolve a public registry.
For Kubernetes-based components, the pattern is well documented. The kubeadm workflow lets you run kubeadm config images list and kubeadm config images pull on the staging side to fetch control plane images in advance, then point kubeadm init at your internal registry with the --image-repository flag. The same logic applies to mail workloads: mirror every image your chart references into the private registry, and confirm that the chart's image references resolve to that registry before the cluster is ever exposed to a change. Ask your integrator to produce a list of every image tag and chart version in each transfer, so that the list, not memory, defines what is deployed.
Record a hash and an approval for every item that crosses the boundary. Each transfer should carry a manifest with file names, cryptographic hashes, source URLs, the time of download, the person who staged it, and the change approver who accepted it on the inside. Keep these records with your change tickets so an auditor can trace any signature file or rule set back to its origin. Cadence is a policy decision you should set with your security team and document, not a fixed schedule. Confirm with your vendor how often they publish signature and rule updates, and how urgent a security fix is handled, because that determines how often the transfer path needs to run.
How users exchange mail across the boundary when policy allows
The simplest and most defensible design keeps all mail inside the disconnected network. Users message each other on the internal mail server, calendars and free/busy lookups work only among internal accounts, and there is no SMTP path to or from the outside. Content inspection is then limited to internal traffic, which still needs malware and spam controls because a compromised internal host can send mail. Encryption concerns are internal, such as TLS between clients and the server and between internal mail components. Logging focuses on authentication and message flow inside the enclave. Approval is usually a decision by the security owner and the business owner of the network, recorded in the system security plan.
- Content inspection: Internal mail is still scanned for malware and for policy violations, since the sender may be an internal account that has been compromised.
- Encryption: Confirm that client connections and server-to-server connections inside the enclave use TLS with certificates from the internal certificate authority.
- Logging: Keep mail server authentication and delivery logs in the enclave's log store, and confirm retention periods with your records owner.
- Approval: Record the decision that external mail is out of scope, with a named owner who reviews it when the network's purpose changes.
- Operational side effect: Users need a documented process for reaching outside contacts, such as a physical courier or a separate approved system, so they do not improvise.
Before you commit to this model, ask the vendor or integrator to confirm that the mail server can run with no external relay configured and that it raises no errors when outbound DNS is unavailable.
A transfer gateway moves messages across the boundary through a defined point where content is checked before release. Typically one direction is allowed, or both directions are allowed under separate rules. The gateway sits between the enclave and the transfer zone, and each message is examined against policy before it is passed through. Because the gateway is a security control in its own right, its evaluation criteria matter as much as the mail platform. Approval normally comes from the security function together with the data owner, and each transfer rule should be documented so an auditor can trace it.
- Content inspection: Define which attachment types, sizes and content patterns are blocked, and whether messages are held for manual review. Confirm with any gateway vendor exactly which inspection features exist before relying on them.
- Encryption: Require encrypted transport on both sides of the gateway, and confirm how the gateway handles messages that arrive without encryption.
- Logging: Log every message crossing the boundary with sender, recipient, time, size and inspection result, and forward those logs to the enclave's monitoring platform.
- Approval: Assign approval for each transfer rule, such as who may send to which external partner, and review the list on a fixed schedule.
- Offline content updates: Anti-malware signatures and spam rules used by the inspection step must also arrive by approved offline media, with hashes checked before import.
Ask the integrator to show, for a test message, the full log record that the gateway produces, and confirm where that record is stored and who can read it.
A controlled relay connects the internal mail server to a named partner network through a restricted path. Only the listed partner domains are reachable, the relay accepts mail only from authorized internal hosts, and the partner side is configured to accept mail only from the relay. This model supports ongoing correspondence with a defined group, such as a regulator or a supplier on a parallel network, but it creates a standing connection that needs the same scrutiny as any remote access path. Approval should cover the partner agreement, the technical design and the monitoring commitments on both sides.
- Content inspection: Apply the same inspection and blocking rules as the transfer gateway, and add checks that a message is addressed only to approved partner domains.
- Encryption: Require transport encryption and mutual authentication where the partner supports it, and document the fallback behavior if it does not.
- Logging: Record connection attempts, rejected messages and delivery outcomes, and include the partner's contact for investigations.
- Approval: Obtain sign-off from the security owner, the data owner and the partner's counterpart, and state how the relay is disabled in an incident.
- Scope control: Keep the list of partner domains in version-controlled configuration, so every addition is reviewed and traceable.
Confirm with the partner what they will accept and how they will report misdelivered or suspicious mail, because a one-sided relay design often fails during the first incident.
How an air-gapped mail rollout runs in phases
The sequence turns a disconnected network into a tested mail, calendar and contacts service with a documented boundary, verified software inputs, an internal certificate chain and evidence that the update path works without internet access.
Scope the boundary and write the transfer policy
The security owner, the mail platform lead and the compliance lead agree which users, domains, client types and data classes stay inside the enclave, and whether any mail, calendar or attachment may cross the boundary. They also decide who approves each transfer and how transfers are logged. The output is a signed boundary policy that names every permitted path, such as none, a one-way data diode or a manual media process, and lists the controls each path must meet. Confirm with your assessor which controls they expect to see documented before this policy is accepted.
Build the offline artifact supply chain
The platform team builds a staging environment on a connected network, pulls the mail server, container images, operating system packages, antivirus signatures, spam rules and vulnerability feeds, then records a checksum and origin for each item in an inventory. Packages are scanned and verified against vendor signatures before they are written to approved media. The output is a bill of materials for the transfer and a signed manifest that the enclave side checks on arrival. Where your supplier obligations require it, the inventory should also support your software integrity and authenticity review for the vendor.
Stand up internal DNS and the certificate authority
The network team creates internal zones for mail hosts, MX and service records, and reverse lookups, and the security team establishes an internal certificate authority that issues server certificates for SMTP, IMAP, JMAP, CalDAV and CardDAV endpoints. Client and server trust stores are updated through the approved image or configuration channel. The output is a working test where each service resolves internally, presents a certificate that chains to the internal root, and rejects connections that fail validation. Ask the platform vendor to confirm how it handles certificate revocation when no external checks are reachable.
Install the platform from offline media
The platform engineers install the mail or groupware server from the verified bundle, pointing the cluster or host at an internal registry and package mirror rather than public sources. They configure mailboxes, storage, backup targets and the local spam and antivirus engines, and disable any feature that calls an external service. The output is a clean install with a recorded configuration baseline and a check that no outbound connection attempts were logged during first start. Confirm with the vendor which features require licensing in air-gapped mode before this step begins.
Configure identity and client access
The identity team connects the mail platform to the internal directory and any single sign-on provider that runs inside the enclave, then configures supported clients for IMAP, JMAP, CalDAV and CardDAV against internal certificates. They test mailbox provisioning, password and multi-factor policy, shared calendars and delegated access. The output is a test matrix of client types and user roles, with results recorded for each one. Where a client cannot validate the internal chain, the team documents the gap and the approved workaround instead of disabling validation.
Rehearse the offline update cycle
The platform team runs a full update on a copy of the production stack using only the media path defined in phase two. They apply a new server release, refreshed antivirus signatures and updated spam rules, then confirm that message delivery, filtering and calendar sync still work. They also record the rollback steps and time the restore from backup. The output is a rehearsal report listing each artifact applied, the verification result for each one and any issues found. Ask the vendor how security updates are published, how long they are supported, and what the upgrade path looks like between major versions.
Capture evidence and accept the service
The compliance lead and the security owner gather the boundary policy, the artifact manifests, certificate records, configuration baselines, access logs, backup test results and the update rehearsal report into one evidence package mapped to the controls your framework requires. They review gaps with the platform owner, close what can be closed, and sign acceptance for the production service. The output is an accepted service with a dated evidence set and a named owner for each recurring control. Independent auditors or certification bodies, not the implementation team, decide whether that evidence meets their requirements.
Integration points and deployment pattern in a disconnected network
A disconnected mail platform is only as good as the services it depends on inside the enclave. The cards below cover the directory, certificate authority, DNS, monitoring, backup and transfer components that each need an internal source of truth, and the failure mode to test for each one.
Internal directory integration
Mail, calendar and contact access all depend on one directory that authenticates users and resolves addresses. Inside an air-gapped network, the directory must be local, since no cloud identity provider is reachable. Check which directory the mail server binds to, how group membership maps to mailbox access, and what happens to logins when the directory replica is stale. Confirm whether the platform's group-based and shared mailbox permissions survive a directory outage, and test a password reset path that does not depend on any external service.
Internal certificate authority
Clients and services inside the enclave cannot rely on public certificate authorities or online revocation checks. An internal CA issues the certificates for IMAP, SMTP submission, JMAP, CalDAV and the web client, and the root must be installed on every managed device. The main failure mode is expiry: an unnoticed expired intermediate breaks mail for every client at once. Confirm who signs certificates, how revocation is published inside the network, and how the root reaches devices that are updated only from offline media.
Internal DNS for routing and service names
Without public DNS, MX records, autoconfiguration names and service hostnames must be resolved by an internal zone that the mail server and clients both trust. Routing between internal domains is controlled here, not by the internet. The failure mode is split-horizon drift, where a client resolves a service name to a different host than the server expects. Ask who owns the zone, how changes are signed off and transferred across the boundary, and whether a test query from each segment returns the same answer.
Monitoring and log export
Operators need queue depth, delivery failures, certificate expiry, authentication errors and disk usage from a network that cannot send data out. Metrics and logs stay inside the enclave and are read by a local collector. The risk is silence: when the collector or its storage fails, the mail server can keep running with no visible fault. Confirm which logs carry the audit trail for mailbox access, where they are exported, and who reviews them. A failed export should raise an alert on the monitoring side.
Backup to offline media
Backups for an isolated mail platform usually go to media that is physically moved, such as encrypted disks or tape, rather than a network target. Mailbox stores, directory data, database dumps and the internal CA private key all need copies, and each copy must be tested by restoring it. The failure mode is an unrestorable backup that looks complete. Ask how often media is rotated, where it is stored, how keys for encryption are escrowed, and how a full mail restore is rehearsed on a separate isolated host.
Transfer station for cross-boundary updates
Software packages, antivirus signatures, spam rules and certificate revocation data enter the enclave through a controlled transfer station. Each item is verified for integrity and authenticity before it is staged for the mail host. The control behind this step is the supply chain procurement requirement in NERC CIP-013-2, which asks entities to verify software integrity and authenticity for vendor software and patches. Confirm the scanning steps, the signing keys used for verification, the approval record for each import, and how an import is rolled back if a rule update causes false positives.
Evidence auditors and assessors ask for from an isolated mail system
This table lists the evidence an assessor typically asks to see from an air-gapped mail system, the component or record that produces it, and where teams usually fall short. Read it as a collection checklist: each row should have an owner and a storage location before the first assessment. DeployOpen prepares these records and controls, but independent auditors and certification bodies issue any attestation.
| Evidence item | What it shows | Produced by | Where it usually falls short |
|---|---|---|---|
| Offline artifact inventory with hashes | Every package, container image and rule set carried across the boundary, with checksums and source | Transfer workstation logs and a signed manifest kept by the import team | Manifests are written after the transfer or do not cover spam rules and signature files |
| Transfer approvals | Who authorized each media movement, what it contained and when it crossed the boundary | Change or ticketing system tied to the cross-domain transfer procedure | Approvals exist for software but not for rule or signature updates |
| Update and patch records | Which mail server, antivirus and spam filter versions ran, and when each was updated from offline media | Package manager history, container image tags and the offline repository mirror | Versions drift between the mail, antivirus and filter hosts with no single record |
| Certificate inventory from the internal CA | Every TLS certificate issued for mail services, its subject, expiry and the root it chains to | Internal certificate authority issuance log and the mail server configuration | Expired or untracked certificates on IMAP, SMTP and calendar endpoints |
| Mailbox and admin access logs | Who logged in, read or changed mailboxes and administrative settings, with timestamps | Mail server authentication and audit logs, forwarded to a central log store on the isolated network | Logs stay local to each host, are rotated too early or do not record administrative changes |
| Retention configuration | The retention rules, journaling targets and legal hold settings applied to business mail | Archive or journaling component and the mail server's retention and journal configuration exports | Retention is set on the mailbox server alone, with no archive copy or tested restore |
| Security monitoring coverage | Evidence that host and network activity on the mail segment is watched and alerted on | Host-based monitoring agents and a local detection platform such as Wazuh, running on the isolated network | Agents are not deployed to the mail relay or the transfer station |
| Access and change review records | Periodic review of accounts, administrator roles and changes to the mail configuration | Directory or identity system exports and the configuration management repository | Reviews are not dated or signed and do not cover break-glass accounts |
Questions buyers ask about air-gapped email
What drives the cost of running mail in an air-gapped network?
The largest cost drivers are the number of mailboxes, the storage and retention period, the number of environments you must build (production, a staging copy and recovery), and the labor to run an offline update process. Hardware or cloud capacity inside your boundary is a one-time and recurring cost. Software licensing is a separate line: a community edition may carry no fee, while supported or enterprise editions and modules are priced in their license agreements. Ask any partner for a quote that separates one-time build work, recurring operations, and each license, and that states what is included in support.
How long does an air-gapped mail deployment take?
Duration depends on scope rather than on the mail server alone. The main variables are how many integrations you need (directory, certificate authority, archive, monitoring), how many users and mailboxes migrate, whether the platform runs on a Kubernetes cluster that must also be built offline, and how many approval gates your change process requires. A single-site deployment with a small set of integrations is a much shorter project than a multi-site rollout with migration and archiving. Ask for a written timeline tied to milestones and to the agreed scope, not a generic estimate.
What does our team need to supply for an air-gapped mail project?
Expect to supply the people and the environment, not only the decisions. Typical inputs include a named mail domain and address plan, an internal certificate authority or a process to issue certificates, a directory service for accounts, the offline storage or registry where packages and images will be placed, hardware or virtual capacity, and staff who approve changes and own the system after handover. You will also need someone who can run the transfer process for software and signature updates. Ask the partner to list these inputs in the written scope so that gaps are visible before work starts.
Can our own staff run an air-gapped mail system after handover?
Often yes, if the operating model is designed for it. Your team needs skills in mail protocols, DNS and certificates inside a closed network, backup and restore, and the offline update cycle. Many organizations keep a small core team and use a retainer for upgrades, testing and incident support. Whether this works for you depends on your headcount, your on-call expectations and how often you must patch. Ask the partner what documentation, runbooks and training are included, and which tasks remain with them under ongoing support.
Does air-gapped support require a paid edition of the mail platform?
It can, so check before you choose. Some vendors reserve offline or air-gapped deployment for commercial tiers. Mattermost lists air-gapped deployment in its Enterprise Advanced plan, and Rocket.Chat excludes it from its free Starter plan. Element offers a free AGPL Community edition alongside Pro and Sovereign editions, the last designed for air-gapped deployments. For mail specifically, open-source options differ in license and support terms, and OX App Suite's use of certain modules may depend on custom packaging or separate fees set in the license agreement. Confirm in writing which features, updates and support terms your license covers in an offline setting.
How do security and software updates reach a disconnected mail network?
Updates arrive by approved transfer media or a controlled one-way path, after the package and its signatures are verified. A typical process has four parts:
- Download packages, container images and signature or antivirus definitions on a connected staging host.
- Verify checksums and signatures against the vendor's published values.
- Scan the bundle and record what was imported, with approval from the change owner.
- Import into an internal repository or registry, then test in a non-production copy before rollout.
Updates to spam rules and malware signatures follow the same path, so their age in the closed network is a risk you should measure. Ask how the partner handles emergency security releases, and whether this process is documented as evidence for change control.
How does mail cross the boundary when policy allows it?
Mail crosses the boundary only through a controlled relay or gateway that the security team owns. Common patterns are an internal relay that holds outbound messages and forwards them through an approved gateway, inbound filtering before delivery, and strict rules on which external domains and attachment types are allowed. Internal-only mail never needs external DNS, but external exchange must have its own sender authentication, TLS enforcement and logging. Confirm with your security team which traffic is permitted, how it is inspected, and how the gateway is itself patched and monitored.
Which regulations shape how we keep air-gapped mail records?
Regulation determines what must be retained and how it is evidenced, while the air gap determines where it is stored. For example, SEC Rule 17a-4(b)(4) requires broker-dealers to preserve copies of business communications for not less than three years, which means the mail server alone is usually not the record. HIPAA's Security Rule requires technical measures to guard ePHI in transit and audit controls that record activity in systems containing ePHI. Ask your compliance lead which rules apply, and ask the partner to show how archiving, audit logs and backups are built and tested in the closed network. DeployOpen prepares controls and evidence for assessments, but independent auditors issue any audit report or certification.
What to ask an implementation partner before you commit
Start with the offline artifact chain. Ask the partner to list every item that crosses the boundary: mail server images or packages, antivirus signatures, spam rule sets, operating system packages, and the Kubernetes or container images if the platform runs on them. For each item, ask how it is built, which signature or checksum it carries, where that is verified, and who approves it before import. For a platform that runs on Kubernetes, ask how the image list is generated and how a private registry is populated, since the kubeadm documentation describes pre-pulling control plane images and pointing the cluster at a private registry. Ask for the written chain of custody, not a verbal description. Where a NERC CIP-013-2 style supply chain control applies, ask how software integrity and authenticity are checked for each transfer.
Ask which licence tier the platform needs for air-gapped operation before you sign anything. Several vendors reserve offline deployment for paid editions: Mattermost places air-gapped deployment in Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, and Plane's Airgapped edition is proprietary while its Community edition is AGPL-3.0. Ask the partner to name the exact edition, the license terms that apply to it, who holds the license, and how renewals and updates are billed. For OX App Suite, ask which modules or features depend on custom packaging or separate fees, since the Operations Guide notes that these may be set in the license agreement. Confirm the tier against the vendor's current pricing and documentation, not the partner's summary.
How DeployOpen delivers self-hosted email on disconnected networks
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including networks with no internet route. For internal-only mail and calendars, we start from your classification rules, boundary design and staff workflows, then build and hand over a system your team can run without outside connectivity.
How we scope
- Map which users, domains and calendars stay inside the enclave and which cross the boundary
- Define the internal certificate authority, directory source and client access paths in writing
- Agree the offline update, signature and rule transfer process before any installation begins
How we build
- Deploy the mail, calendar and contact platform from media staged outside the enclave
- Configure internal-only routing with no external DNS, relay or public certificate dependencies
- Wire antivirus signatures and spam rule updates into a verified import path, with integrity checks recorded
How we hand over
- Deliver runbooks for installation, backup, restore and certificate renewal inside the network
- Document the cross-boundary exchange procedure, including what is reviewed, logged and approved
- Provide evidence for assessors, such as configuration baselines and audit log settings, for your compliance team to review
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build
- Plan offline upgrade cycles around each vendor release and your change approval calendar
- Retest the mail platform and its update path after changes to the boundary or the software baseline
