Why air-gapped document editing needs a different build
If you must give staff browser editing of Word, Excel and PowerPoint files on a network with no internet route, the platform decision comes first. Collabora Online is the usual fit where WOPI integration with your file platform and a LibreOffice-based engine matter most. ONLYOFFICE is the stronger candidate where Office Open XML fidelity is the priority for templates and forms that must round-trip cleanly. In both cases, the edition you choose will be driven less by features than by support terms and by which offline capabilities the vendor documents for that edition. Confirm those in writing before you select a platform, because air-gapped support is often a paid-edition feature rather than a default.
On a connected network, the editor pulls fonts, images and updates from the internet, and your team rarely thinks about where they came from. On an isolated network, every one of those pieces must be carried in by hand: the container images for the document server and the file platform, their base images and dependencies, the font set your templates need, and the signed update packages. The build therefore has to start with an inventory of what the editor will fetch at runtime, then a repeatable transfer process with checksum or signature verification at the boundary. NERC CIP-013-2 makes the verification step concrete for some operators by requiring procurement processes that address software integrity and authenticity, and the same discipline applies to any regulated environment.
Integrations need the same attention. The WOPI traffic between your file platform and the editor must be restricted to known internal hosts, and every external call the editor, the file platform or any optional AI feature could make must be identified and disabled or confirmed as unreachable. Collabora's optional AI assistant is off by default, and ONLYOFFICE's settings for plugins and telemetry should be reviewed the same way. Write these decisions down as a build specification with an owner for each item, and test the result from a host with no route to the internet. A reader who can answer which packages, fonts and endpoints the editor needs, and who signs off each transfer, is ready to scope the build.
Which requirements change when the network has no internet
This table maps each requirement that applies to an air-gapped editing deployment to its source and to what it changes in the build. Read it as a checklist for architecture decisions: each row names the evidence an assessor or auditor will expect to see, and the main takeaway is that the offline transfer procedure and editing-session logs become part of the system, not afterthoughts.
| Requirement or pattern | What it changes in the build | Evidence to keep |
|---|---|---|
| Records retention under 17 CFR 240.17a-4 (broker-dealers) | Where edited documents are business records, versions and comments must be preserved for at least three years, so the storage behind the editor needs retention rules, not only the document server. | Retention schedule, version history export and proof that deleted or overwritten versions are still recoverable |
| ePHI transmission and audit controls under 45 CFR 164.312 | Clinical documents edited in the browser need encrypted editor-to-storage traffic and audit controls that record access and activity in systems holding ePHI, including WOPI calls and edit sessions. | Logs of document opens, edits and saves tied to user identity, plus configuration evidence for TLS between components |
| NERC CIP-005-7 Interactive Remote Access | If the editing host sits in a BES Cyber System perimeter, vendor and engineer access for updates must pass through an Intermediate System with encryption and multi-factor authentication, and active vendor sessions must be detectable and disableable. | Access path diagram, MFA records for remote sessions and a documented procedure to end vendor sessions |
| NERC CIP-013-2 software integrity and authenticity | Every image, font pack, and update package carried across the boundary must be checked for integrity and provenance before it is loaded, which makes signature verification a required step in the transfer procedure. | Vendor verification records per package, checksums or signatures checked on the inside, and a record of who approved each import |
| Kubernetes offline images and private registry | Control plane and workload images are pulled in advance on a connected staging host, then pushed to an internal registry, and kubeadm init points at that registry through its image repository setting, so nodes never reach public registries. | Image manifest with versions and digests, registry import log and a list of images that were rejected or not imported |
| Editor pod sizing and manual replica control | Collabora's Helm chart disables autoscaling because scaling breaks collaborative editing, so replica counts are set by hand and routing must keep all editors of one document on one pod by WOPISrc, which is also a change-control item. | Documented replica settings, load balancer rules by WOPISrc and change records for each manual scale event |
| Offline fonts and file format fidelity | Fonts and templates must be packaged and tested inside the boundary because no public font service is reachable, which affects how documents render for users. | Font inventory, rendering test results on sample Office files and sign-off on the font set |
| Telemetry and external AI features | Outbound calls for telemetry, updates or optional AI assistants must be disabled or routed to internal endpoints, and the configuration itself becomes audited evidence. | Configuration export showing disabled outbound services and a network test showing blocked egress |
How the air gap changes images, fonts and updates
An air-gapped editor cannot pull images from a public registry at deploy time or at restart, so every image the platform needs must be staged in advance and served from a private registry inside the boundary. For Kubernetes, the kubeadm tooling documents a way to list and pull control plane images ahead of time and to point the installer at a private registry. The editor images themselves follow the same pattern: each image and tag is pulled on a connected staging system, scanned, and pushed to the internal registry under a fixed tag that the deployment manifests reference.
- Build the image manifest: list every image the editor, its ingress and its supporting services need, including sidecars and init containers, and record the exact tag and digest.
- Stage on a connected system: pull the images outside the boundary and record the digests so the internal registry can be checked against them.
- Point the installer at the private registry: use the
--image-repositoryflag inkubeadm initso control plane images resolve inside the network. - Avoid floating tags: a
latesttag in an offline cluster means you cannot tell which build is running, so pin versions in the Helm values. - Plan for the free edition: Collabora's free CODE image (
collabora/code) is a rolling release that Collabora does not recommend for production, so a production build should use a supported edition.
Confirm with your vendor which image tags are supported for your edition and how they are published for offline use.
Browser editing depends on fonts on the server as well as in the browser. When a document references a font the server cannot find, the editor substitutes a different face, and pagination, line breaks and table widths can shift. Online deployments often hide this gap because teams assume a public font source exists, but an isolated network has none. Fonts used by your templates, including corporate and licensed typefaces, must be packaged, licensed for server use, and installed into the editor image or mounted from an approved store.
- Inventory the fonts in your documents: scan a representative set of templates and exports for embedded and referenced fonts.
- Check licences before carrying them: confirm each font permits server-side rendering and redistribution inside your organization.
- Build a font layer: add the approved font packages to a versioned image layer so the same fonts appear on every replica.
- Test rendering on the same build: compare page breaks, headers and tables in the browser editor against the desktop originals.
- Repeat the test after every image update: a new base image can change the default fonts or the font configuration.
Ask your implementation partner which font families are in the approved layer and who signs off on rendering tests before each release.
Updates reach an air-gapped network on physical or controlled media, not through a live package feed. The procedure therefore has to verify what crosses the boundary. Each update package should be checked against the publisher's signature and a published hash before it enters the staging area, then checked again on the inside before it is loaded into the internal registry. Vendor support terms matter here, because a signed security update is only useful if your procedure can actually receive and apply it.
- Verify on the outside: check the publisher signature and the SHA-256 hash of each package on the connected staging system and record the result.
- Transfer through a controlled path: move media through a documented, logged process with a named approver for each transfer.
- Re-verify on the inside: repeat the hash and signature checks before anything enters the internal registry or the update repository.
- Keep a release record: store the version, digest, approver and test result for every image so an auditor can trace what ran in production.
- Confirm portal access: Collabora's Business plan includes signed security updates and customer portal access, so confirm with Collabora whether the portal can be used from your staging system and how its packages are delivered to a disconnected network.
NIST SP 800-82 Rev. 3 and the NERC CIP-013-2 supply chain requirement both point to verifying software integrity before it enters a controlled network.
Many editor deployments make outbound calls that are easy to miss in a connected test lab: fonts or assets loaded from a content delivery network, license or activation checks, usage telemetry, and calls to an AI service if an assistant is enabled. In an air-gapped network these calls either fail silently, slow down page loads, or leak information if a route exists. Each outbound path should be identified, blocked at the network layer, and proven blocked during acceptance testing.
- Map every outbound destination: capture DNS queries and egress connections during a full editing session, including file open, save and co-authoring.
- Disable telemetry and external AI: Collabora's optional AI assistant is off by default, but confirm that it stays off and that no provider endpoint is configured.
- Remove external asset references: check the editor and file platform configuration for hard-coded public URLs, font sources and script includes.
- Block egress by default: enforce deny-all outbound rules for the editor pods and prove the block with a failed test connection.
- Record the evidence: keep the egress test results with the change record for audit purposes.
The Collabora Online Helm chart and your file platform's admin settings are the first places to check, and your vendor should confirm every setting that controls external calls.
Which editing platform fits a disconnected environment
Both Collabora Online and ONLYOFFICE Docs can run inside an isolated network, but their licensing, update channels and support terms differ in ways that change the build. The cards below separate the production options from the test-only build and flag what to confirm with each vendor before you commit to an offline design.
Collabora Online for production
Collabora Online's server code is licensed under MPL-2.0, and it integrates with file platforms through WOPI, including Nextcloud, Seafile and Mattermost. It can be deployed from Docker images, system packages or Kubernetes, so you can match the install method to what your isolated network already supports. For air-gapped work, confirm with Collabora which edition carries the signed security updates and long term support you need, since the Business plan is the paid tier that includes them. Ask how offline images and signed packages are delivered across the boundary.
ONLYOFFICE Docs for Office formats
ONLYOFFICE Docs is licensed under AGPL-3.0 and is built around the Office Open XML formats, which matters if your archive is mostly .docx, .xlsx and .pptx files. The AGPL terms place source obligations on modified versions that users interact with over a network, so legal review should happen before you alter the server. Confirm with ONLYOFFICE whether offline installation, signed update packages and clustering are included in the edition you plan to run, because clustering is tied to licence terms that you need to verify in writing.
CODE as a pilot build
The Collabora Online Development Edition is free and released roughly once a month as a rolling release. Collabora describes it as suited to testing, home use or small teams and not recommended for production. In a disconnected environment, it is useful for rehearsing the image transfer, font loading and WOPI wiring before you buy support. Do not promote a CODE build into production, because you would lose the long term support and signed security update commitments that a supported edition provides.
Air-gap support in paid editions
Several vendors place air-gapped deployment in a paid tier rather than the free one. Mattermost lists it in Enterprise Advanced, Rocket.Chat excludes it from the free Starter plan, and Metabase offers it only on its Enterprise plan. Element and Plane also separate community and airgapped editions. Treat this as a pattern to test for each editor, and ask any vendor whether offline use, offline updates and offline support are covered before you assume a free build is supportable in your network.
Keeping WOPI and update traffic inside
Whichever editor you choose, the file platform and the document server must reach each other over a path you control, and the editor must not call out for fonts, updates or telemetry. Plan the WOPI host list, the offline font set and the process for carrying each signed package across the gap as one design, and verify every package against its published signature before it enters the network. Confirm with the vendor which update and telemetry settings can be disabled in the version you run.
Disabling AI features, telemetry and external calls
The goal of this section is proof that the editing stack makes no outbound connections, and that every feature which could reach an external host is either removed or switched off. Start with an inventory of what the deployment can reach: telemetry and update checks in the document server, the plugin and font download paths, remote image fetches inside documents, and any optional assistant. Each of these needs an owner, a setting or a removal step, and a test that shows it is inactive. Confirm the exact configuration keys and defaults for your release with the vendor documentation rather than relying on memory or on an older install guide, since defaults change between versions.
Collabora Online 26.04 adds an optional AI assistant across Writer, Calc and Impress, and it is off by default. Administrators choose the provider and decide whether it runs externally or on their own infrastructure. Treat it as disabled unless a self-hosted model endpoint has been reviewed, approved by the security owner and documented in the change record. If it is ever enabled, log which users invoke it, restrict the feature by group, and confirm that the endpoint resolves only to an address inside the enclave. Check that the assistant setting is still off after every upgrade, because a new release can change defaults or add settings that an older configuration file does not contain.
Test the result with egress blocked. Place the editor, the storage platform and a test client on a segment whose firewall drops all traffic to the internet and to any host outside an approved list. Open, edit, save and co-edit documents that include external image links, embedded fonts and a macro-free template, then review firewall and DNS logs for any attempted resolution or connection. Repeat the test after each update and after each configuration change. Record the test date, the software versions, the destinations attempted, the result for each, and the name of the person who reviewed the logs. That record becomes evidence for the next assessment and shows whether a regression has appeared.
How an air-gapped editing rollout runs, phase by phase
The sequence moves a document editing platform from requirements to a production-ready, offline deployment in which every image, font and update is verified before it crosses the gap. Each phase closes with a written output that the next phase depends on.
Set requirements and confirm the platform
Document the file formats you must open and save, the expected number of concurrent editors, the file platform that will call the editor through WOPI, and whether the enclosed network allows any outbound path at all. Decide between Collabora Online and ONLYOFFICE Docs against those requirements, and confirm the edition and support terms your security team will accept. The output is a signed requirements record and a platform decision. Ask the vendor in writing which edition permits air-gapped operation, because that is often a paid-edition feature and the free builds may not be the right fit for production.
Build offline images and fonts in staging
On a connected staging network, pull the editor container images, pin their versions and digests, and collect the fonts your documents depend on, including any corporate or licensed typefaces. Build the internal image set and a font bundle, then record a manifest listing every image, hash and font file. The output is a versioned offline bundle and its manifest, reviewed by the security team before anything leaves staging. Confirm that the fonts you rely on for pagination and fidelity are present in the bundle, since missing fonts change how documents render on the isolated side.
Transfer and verify the bundle across the gap
Move the bundle through your approved cross-domain process, such as a controlled media or data diode procedure defined by your own policy. On the isolated side, recompute the hashes and compare them with the manifest, verify each signature you can check, and load the images into the internal registry only after every check passes. The output is a transfer record showing who carried the bundle, what was verified and what was rejected. Failed items return to staging for investigation rather than being loaded partially.
Integrate the editor with the file platform
Configure the file platform to discover the editor through WOPI and point it at the internal editor endpoint, using only addresses that resolve inside the enclosed network. Test view and edit sessions for each supported file type, including saving back to the file store and version creation. The output is a passing test matrix recorded against the exact image versions in the offline bundle. If your file platform expects an external discovery or telemetry endpoint, confirm the behavior with its vendor before go-live.
Restrict WOPI hosts and test egress
Limit which hosts may call the editor and which hosts the editor may reach, so that WOPI traffic runs only between known internal systems. Disable external AI features, telemetry and any update checks in the editor configuration, and confirm each setting in the admin interface and configuration files. Then run egress tests from the editor network, attempting outbound connections to external addresses and DNS names, and record that every attempt fails. The output is a signed egress test report and a configuration baseline that the change process must preserve.
Size editor replicas manually
Set the number of editor replicas by hand, because the official Collabora Online Helm chart disables horizontal pod autoscaling: scaling breaks collaborative editing and copy and paste. Use the chart's recommended production reference of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB, as the baseline, then confirm the load balancer routes all sessions for one document to the same pod using the WOPISrc parameter. The output is a documented replica count, a load test result and a runbook for adding pods during a planned change window. Confirm with your architect whether the reference values fit your own concurrency profile.
Run the pilot and accept the platform
Run a pilot with a bounded group of real users on representative templates, including the Office files your partners send and the fonts your organization uses. Track rendering defects, save failures, session drops and any attempt to reach external hosts, and log each issue with an owner and resolution. Acceptance is complete when the agreed criteria in the requirements record are met and the security team signs the evidence pack. The output is an acceptance record and a go-live decision, both stored with the configuration baseline.
Run an update cycle with signed packages
Repeat the staging, transfer and verification steps for every security update and feature release, so that each change crosses the gap as a signed, hashed and tested bundle. Re-run the egress tests and the WOPI integration matrix after each update before restoring production traffic. The output is a repeatable change record for each release, which also supports the supply chain evidence your assessors may request. Agree on the cadence and the emergency path for critical fixes in the support terms, and confirm how the vendor delivers signed packages for offline use.
Integration points and deployment pattern for isolated networks
A browser editor in an isolated network depends on a small set of components that all sit inside the enclave. Each one must work without a route to the internet, and each one changes how the editor behaves under load and during audits.
WOPI host and file storage
The WOPI host is the platform that holds the documents and tells the editor who may open and edit them. In an air-gapped build this is usually Nextcloud or another file platform inside the enclave, and it must be reachable by the editor server while the editor server stays unreachable from outside. Check that the host's WOPI discovery and callback URLs resolve to internal addresses, that the wopi_url and allowed host settings match the enclave DNS names, and that file locks and version history are tested through the gap. Confirm the WOPI host version supports your chosen editor edition before you commit.
Load balancer and ingress
Collabora Online pods sit behind Nginx, HAProxy or the OpenShift Router, and the Helm chart supports all three. The ingress must route every request for one document to the same pod by the WOPISrc parameter, because collaborative sessions live in one process. Test that sticky routing survives pod restarts and that websocket connections are not dropped by idle timeouts. Ask the partner to show the routing rule in the running configuration, not only in the design.
Private image registry
Nothing in an air-gapped cluster can pull from a public registry, so the editor image, its base layers and the Kubernetes control plane images must come from a registry inside the enclave. Kubernetes documents pre-pulling control plane images with kubeadm config images pull and pointing installs at a private registry with --image-repository. Mirror the editor image by digest, record the digest in your change log, and confirm the free CODE image is not used in production unless Collabora's guidance for your use case allows it.
Font and template repository
Document layout depends on fonts that the editor can read at render time. An offline build needs an internal font and template store, populated with licensed fonts your organization is entitled to use, and the editor must be configured to load them. Missing fonts cause reflowed pages and broken tables that users only notice after a document leaves the system. Ask for a test set of your own templates rendered in the enclave, and keep the font set under the same change control as the editor images.
Logging and audit sink
Access to documents, edit sessions and administrative changes should be recorded inside the enclave, not sent to an external log service. The WOPI host and the editor each generate logs that must reach a sink you control, such as a SIEM or log store in the same network. This supports audit control expectations, including the HIPAA audit controls under 164.312(b) where ePHI is involved. Confirm retention periods with your records owner, because they are set by your policy and regulation, not by the editor.
Manual replica control
The Collabora Online Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, so replica counts are set by hand. Capacity planning becomes an operational task: someone must size replicas for expected concurrent editing, review them on a schedule, and change them through a controlled procedure. Document the peak load, the change window, and who may change the replica count. Ask the partner how they will measure per-pod load inside the enclave, since no cloud metrics service will be available to trigger scaling.
Evidence an auditor or regulator will ask for
This table lists the records an assessor is likely to request for an air-gapped document editing deployment, what each one proves, and which component usually produces it. Read it as a checklist to agree with your auditor before the environment goes live. DeployOpen prepares this evidence, but independent auditors and certification bodies assess it and issue any opinion.
| Evidence item | What it proves | Which component produces it |
|---|---|---|
| Image manifests and hashes | Every editor, document server and dependency image in the isolated registry matches the set approved for transfer | Private container registry, image signing and digest records kept by the transfer team |
| Transfer log for each update | When each package crossed the gap, who approved it, and which media or channel carried it | Change ticket, transfer record and media handling log kept on the high side and the low side |
| Signed update verification records | Signatures and checksums on each package were checked before installation, as expected under supply chain controls such as NERC CIP-013-2 | Verification scripts, the vendor's signing key record and the output of each check |
| WOPI host allow-list configuration | Only named storage hosts can call the editor, so unknown hosts cannot open or save documents | Document server configuration file and the allow-list reviewed in each change record |
| Egress test results | The editor, document server and fonts service cannot reach external addresses, and telemetry and external AI endpoints are disabled | Firewall and network policy logs, plus scripted connection tests run after each change |
| Access and edit logs for ePHI or records | Who opened, viewed, edited or saved a document, supporting audit controls such as those in 45 CFR 164.312(b) or records retention under 17 CFR 240.17a-4 | Storage platform audit log, editor session log forwarded to a central log store |
| Version and support status per release | Each deployed release is supported, patched and recorded, so the environment does not drift into unsupported code | Release register kept by the platform team, plus the vendor's published support dates for the edition in use |
Questions to ask an implementation partner about offline editing
Start with how the partner builds and verifies the offline bundle. Ask which exact image tags, digests and font packages go into the transfer set, who builds it, and how the partner proves that nothing was pulled from a public registry during assembly. Ask how each image is scanned and how the checksums are delivered across the gap, separately from the bundle itself. For fonts, ask how they test rendering offline: whether they compare the fonts shipped with the editor against the fonts your users rely on in Word-formatted templates, and whether they check for font fallback that changes pagination. Ask for the test documents and the results, not a summary.
Next, ask how signed updates are verified before import. The partner should explain who holds the signing keys, where the signature check runs (on the transfer media, in the isolated network or both), and what happens when a signature fails. Ask how the release is staged in a non-production editor pool first, and how a rollback works if the new document server version breaks co-authoring. For WOPI, ask which host allow-list the partner configures on the document server and the file platform, how the proof key validation is set, and whether the editor can reach any address outside the file platform. Ask them to show the resulting rules in a test environment, and to list every outbound destination they found and disabled.
Then ask how replicas are sized and routed. Collabora's Helm chart disables horizontal autoscaling because scaling breaks collaborative editing, so the partner should state the replica count they chose, the peak concurrent editors they assumed, and the source of that assumption. Ask how the load balancer routes by the WOPISrc parameter so every editor of one document reaches the same pod, and how they test that routing with two users on one file. Ask which edition gives you signed security updates and long-term support for an offline estate, and what support they provide during the gap between releases. Finally, ask what your team must run after handover: the import procedure for each update, the monthly or per-release verification steps, the checks on outbound blocks, the font and template regression set, and who signs off on each import. Get those responsibilities into the written scope before work starts.
Questions buyers ask before an air-gapped editing project
What does an air-gapped document editing project cost, and what drives it?
The cost is mostly the engineering work of building and testing a disconnected stack, plus any recurring subscription you choose. Open-source Collabora Online and ONLYOFFICE Docs can be run without an edition fee, but production support, long term maintenance and signed security updates are paid services or subscriptions, and the vendor pages list them by plan. Collabora's public pricing page, for example, lists a Business plan at 3 euros per user per month for up to 99 users, with long term support, an SLA and signed security updates. The main cost drivers are the number of users, the staging hardware needed to rehearse image and update transfers, the size of the font and format test set, and how many rounds of transfer procedure you need to document. Ask any partner for a quote that separates one-time build work from recurring support and edition fees.
How long does an air-gapped editing rollout take?
The duration depends on your network approval process, how many environments you run, and how much fidelity testing your templates need, so no fixed timeline applies across organizations. The fastest path is usually a written scope that fixes the editor edition, the file platform integration, the transfer procedure and the test cases before work starts. Clarify with the partner which phases are included, such as a staging build, a dry-run transfer across a real or simulated gap, and cutover to production. Your own change board and any security assessment in your environment often set the critical path, so ask for a milestone plan rather than a single date.
What must our team provide for an air-gapped editing project?
Your team supplies the decisions and access that only your organization can give. Typically that includes a network owner who approves the transfer path and the boundary rules, an internal container registry that holds the editor images, an identity administrator who connects the platform to your directory and single sign-on, and a file platform administrator who configures WOPI between the editor and your file storage. You will also need a test document set drawn from real templates, a named owner for font licensing, and someone who approves each signed update before it crosses the gap. Confirm these roles in writing during scoping so the project does not stall waiting for access.
Can our own team run an air-gapped editor without a partner?
Yes, if you have staff who can operate containers, Kubernetes or system packages, manage a private registry, and follow a documented transfer and verification procedure. Collabora's Helm chart and Docker images can be installed and run by a capable platform team, but the skills needed include WOPI configuration, TLS between components, and manual replica management, since the Helm chart disables autoscaling. A retainer from a partner typically covers ongoing support, upgrades, monitoring reviews and documentation maintenance, while a fixed-scope engagement covers the initial build. Ask each partner to list exactly which tasks a retainer includes and which are billed separately.
How are editor updates applied across an air-gapped boundary?
Updates are downloaded on a connected system, verified, packaged and then carried across the gap through an approved transfer path, after which they are loaded into the internal registry and deployed in a staging environment first. Verification should check the publisher's signatures and checksums on every image and package before it is accepted, which is the kind of supplier integrity control NERC CIP-013-2 asks utilities to address for vendor software and patches. Plan for a rollback path, a documented release note review and a test pass against your document set after each update. Confirm with the vendor which artifacts are signed and how signatures are verified, because the update method depends on the edition you run.
Which editor edition should we buy for an isolated network?
Choose the edition that gives you offline deployment support, the update and security patch commitments your risk team requires, and the support terms your auditors will review. Free community builds can be used for testing, but Collabora states that its free CODE edition is not recommended for production, so production deployments usually need a paid plan or an accepted support path. Confirm in writing whether the edition you select includes the offline artifacts you need, the signed security updates, and the support hours and response targets. Do not assume that a feature available online is included in the offline build.
How do we test fonts and document fidelity before going live?
Build a test set from your real templates, contracts, financial models and presentations, then render them in the offline editor and compare the output with the desktop application you still use. Include the fonts your organization licenses, because a missing font changes pagination and can break formatting in shared documents. Repeat the test after every update, since a new editor release can change layout behavior. Ask the partner for the list of test cases, the owner who signs off each result, and how font files are carried across the gap and installed in the offline container image.
How DeployOpen scopes and supports an air-gapped editing build
DeployOpen, a Chainscore Labs company, delivers an air-gapped editing build under a fixed-scope written agreement. Before work starts, the scope document should name the editor (Collabora Online or ONLYOFFICE Docs), the file platform it connects to through WOPI, the exact WOPI hosts allowed to reach the editor, the number of editor pods and their resource settings, the offline transfer procedure, and the acceptance tests. Ask for the deliverables list and acceptance criteria in writing, including who signs off on the offline image set and fonts. DeployOpen implements inside your own isolated network, whether that is your cloud account, data center or air-gapped enclave, so documents and editing sessions never leave the boundary you define. No price is published. A quote follows from the written scope, so the more precisely the scope describes your user counts, file formats, integrations and change control, the more precise the quote can be.
DeployOpen hardens the editing path and documents the offline procedure so your own staff can repeat it. Hardening covers the WOPI and ingress configuration, disabling external AI and telemetry features, restricting outbound and inbound routes, and recording the manual steps used to scale editor pods, which must be planned rather than autoscaled. Documentation should include the step-by-step transfer of container images, fonts and signed updates across the gap, the checks run on each package before it is accepted, and the rollback path. DeployOpen also runs security testing against the editing path, including the WOPI endpoints, the document server API and the ingress, and reports findings with owners and fixes. Confirm which test scope, tools and retest rounds are included in the agreement.
Ongoing support and upgrades are available as retainers, which matter because offline environments turn every vendor release into a planned transfer. Ask for the retainer terms in writing: which releases are covered, how security updates are carried across the boundary, how often the offline set is refreshed, and who responds to incidents and at what hours. DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, access logs and offline update logs, but it does not issue audit reports, attestations or certifications. Your assessor or certification body makes those determinations, so agree early on which evidence they will expect. Confirm the license edition you need for production support, since vendor support terms are set by the vendor and are outside DeployOpen's scope.
