Running document collaboration with no internet access: offline installation, dependency handling, updates, identity and the tradeoffs involved.
An air-gapped deployment is the strictest form of self-hosting and the least forgiving. There is no package repository to reach, no certificate authority to validate against, no time server to trust by default, and no vendor telemetry to tell you something is wrong.
It is also the deployment where a document platform earns its place most clearly, because in a disconnected environment collaboration is hardest and most valuable.
Five things that a connected deployment takes for granted.
| Dependency | Connected | Air-gapped |
|---|---|---|
| Installation | Package manager pulls dependencies | Every artefact transferred on removable media |
| Updates | Downloaded and applied | Transferred through a controlled process, often weeks behind |
| Time | Network time protocol | Local time source, and it must be reliable |
| Certificates | Public certificate authority | Internal authority, and its root must be distributed |
| Container images | Registry pull | Pre-loaded into an internal registry or side-loaded |
| Telemetry and support | Streaming | None, unless explicitly engineered |
The practical consequence is that installation becomes a supply chain exercise. Every artefact needs to be obtained, verified, transferred and recorded, and the record is what makes the next installation possible.
An installation set is not just the application package. It is everything needed to reach a running system, assembled while you still have the access to do it.
What belongs in it:
The verification step is not bureaucratic. Removable media is a real attack vector, and a set that cannot be verified cannot safely be used in the environments where such deployments live.
Two dependencies that are invisible until they break, and broken in an air-gapped environment they are painful to diagnose.
Time. Authentication assertions have validity windows measured in minutes. If the platform’s clock drifts from the identity provider’s, sign-in fails intermittently — the worst kind of failure to investigate. A reliable local time source, and monitoring that alerts on drift rather than on absolute time, is worth configuring before the first user signs in.
Certificates. With no public authority, the internal authority’s root has to be trusted by every client. This is straightforward in a managed fleet and awkward with a mix of devices. It also means certificate renewal is a manual process with a real outage risk, so expiry dates belong in a monitored calendar rather than in someone’s memory. Our monitoring article covers the alerting pattern.
The update process is the operational burden that surprises teams. It is not difficult, and it is slow, and it needs to be scheduled rather than fitted in.
A workable process:
The cadence will be slower than a connected deployment. Being deliberate about it — quarterly, say, rather than whenever someone has time — is what keeps an air-gapped deployment from falling years behind.
Most air-gapped sites have a directory on the internal network, and the platform integrates with it normally. Where that is not available, the identity implications are covered in our identity and SSO article: the short version is that local accounts require a documented joiner and leaver process and a periodic access review, because no directory will catch mistakes on your behalf.
Being clear about this is more useful than pretending the tradeoffs away.
Vendor support is limited to what you can describe. No remote session, no telemetry, no logs uploaded. Diagnostics happen over the phone or through exported bundles, and the quality of support depends on the quality of your own instrumentation.
Diagnosis is slower. In a connected deployment, an engineer can reproduce a problem against the same version. In an air-gapped one, they cannot see your environment at all.
Security patching is delayed. The gap between a vulnerability being published and a patch reaching a disconnected network is measured in weeks, and it is the strongest argument for maintaining a strict internal change process to compensate.
AI features need local infrastructure. An assistant that calls an external model endpoint will not work. Inference has to run inside the boundary, which means GPU capacity, a locally hosted model, and the operational responsibility for it. Our AI agents article covers what to configure; in this environment, the inference target is not a choice between vendors but a decision about local capacity.
Beyond installation, three operational realities shape day-to-day running.
Diagnostics need local instrumentation. With no telemetry leaving the network, the only view of platform health is what you collect yourself. That makes the monitoring setup more important than in a connected deployment rather than less, because there is no vendor-side view to fall back on. Logs, metrics and synthetic checks all have to be local, retained locally, and reviewed by someone.
Support bundles become the primary support channel. Most vendors provide a diagnostic export precisely for this case. Knowing how to produce one, what it contains, and how to review it for sensitive content before it leaves the boundary is a procedure worth writing before it is needed. That last step matters: a support bundle frequently contains configuration, identifiers and sometimes content fragments.
Change windows are longer because nothing can be fetched. A connected deployment can recover from a missing artefact by downloading it. An air-gapped one cannot, so a missing dependency at the wrong moment means abandoning the window and waiting for the next media transfer. Over-provisioning the installation set slightly is cheaper than the alternative.
An air-gapped network is a claim about network behaviour, and claims about networks are worth testing.
Two checks that catch the common failures:
Attempt outbound connections from the platform hosts and confirm they fail. A host with an unexpected route, a proxy configuration inherited from an image, or a dual-homed interface can quietly have the access everyone believes it does not.
Inspect the application’s own configuration for endpoints it may call: update checks, telemetry, certificate revocation lookups, and any AI inference target. These are frequently left at defaults and fail silently when unreachable, which is usually harmless and occasionally a surprise during an incident.
Both checks are worth repeating after any upgrade, since a new version may add an outbound call that the previous one did not make.
An air-gapped deployment is justified when the content genuinely cannot leave the boundary — classified material, regulated research, or environments where the network isolation is the primary control.
It is badly suited to organisations that want the isolation without the operational commitment. The burden is real, permanent, and concentrated in a small number of people. Where the requirement is data residency or sovereignty rather than isolation, a conventional self-hosted deployment is usually the better fit, as covered in our data residency guide.
For what running the platform involves day to day, see backup and restore and upgrading safely.