Installing Collabora Online in an air-gapped network: what changes when there is no internet
Running Collabora Online with no internet access is a deployment design task, not a configuration switch. A regulated or isolated network that must host browser-based document editing for a WOPI host such as Nextcloud has to plan how every package, image, font, dictionary and signing key reaches the server before the first install, and how each later update gets there too. Collabora Online is a collaborative office suite built on LibreOffice technology, integrated into existing platforms through the WOPI protocol. Its server code is licensed under the *Mozilla Public License 2.0* (MPL-2.0), which permits self-hosting inside your own infrastructure, so the licence itself does not block an isolated deployment.
The first design decision is which edition you are running. CODE, the free edition, is released roughly once a month as a rolling release, and Collabora describes it as suited to testing, home use or small teams but not recommended for production. That means a network that works with CODE in a lab has not yet proven the production path. Confirm with Collabora which production package source, repository keys and support terms apply to your environment, since the business plan described on the Collabora Online pricing page is the route that includes long term support, signed security updates and customer portal access. Ask how those deliverables reach a network with no outbound connection.
Plan the offline update cycle before go-live. Security fixes arrive as point releases on a branch, such as the 25.04 series that Collabora was still maintaining into 2026, and package signing keys have been rotated in the past, so a broken signature check can stop an update silently. Record which branch and point release you run, mirror each approved release into your own repository or registry, verify signatures on every package you carry across the boundary, and test the upgrade in a staging network that matches production. Confirm with your vendor how key rotations are announced and how you obtain the new keys offline.
Which install path fits an offline network
Package installs suit hosts that you already manage through an internal mirror. The main task is copying the Collabora deb or rpm repositories inside the boundary so that installs and later point releases can be served without internet access.
- Repository indexes and packages: Mirror both the repository metadata and the package files for each distribution and architecture you run, so dependency resolution works offline.
- Signing keys: Import the repository keys through a verified channel and record their fingerprints. Collabora's 25.04 release notes record that package signing keys were updated for RPM and DEB users, so add a key refresh step to every sync.
- Operating system dependencies: The coolwsd package relies on distribution packages, so your local OS mirror must cover those too.
- Fonts and dictionaries: Packages do not supply your corporate fonts or every language dictionary. Stage those files yourself and check document rendering after each update.
- Configuration changes: Keep your coolwsd.xml and coolconfig changes in version control so they survive package upgrades.
Before committing, confirm with Collabora which repositories and architectures your subscription covers and how signed updates reach disconnected customers.
Container installs move the mirroring task into an image registry. You pull the image on a connected staging host, verify it, push it into a private registry and reference that registry in every deployment. The free CODE image is published as collabora/code for x86-64, ppc64 and arm64, and CODE is not recommended for production, so use it to prove the pipeline rather than to run users.
- Image and tags: Mirror the exact tag you intend to run, along with any base images it depends on, and record the digest of each one.
- Architecture match: Confirm that the image architecture matches your hosts before you copy it across.
- Runtime settings: Settings such as allowed WOPI hosts and TLS are supplied at run time, so keep them in your deployment definitions under version control.
- Container capabilities: Ask Collabora which capabilities the image needs and check whether your runtime security policy allows them.
- Update path: Each update is a new tag to mirror, scan and test. Ask how security fixes reach offline customers.
Confirm whether the image you mirror is the free CODE build or the subscription image, because support and update terms differ between them.
The official Helm chart expects an internal registry for images and an ingress that your team controls. Mirror every Collabora image the chart references, then point the chart values at your registry. The chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB, so size your nodes for those figures before scheduling.
- Chart and images: Download the chart package and mirror all images it references, including any helper containers, then update the image repository values.
- Manual scaling: Horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so set replica counts by hand and plan capacity accordingly.
- Document routing: The load balancer must route by the WOPISrc parameter so all users editing one document reach the same pod. Confirm that your internal Nginx, HAProxy or OpenShift Router setup does this.
- Cluster prerequisites: The cluster itself also needs an offline build. Kubernetes supports this through a kubeadm image list and a private registry flag, so mirror the control plane images too.
- Chart versions: Pin the chart and image versions in your deployment repository so that each update is a deliberate, tested change.
Confirm with Collabora which chart version and image tags your subscription supports and whether the README guidance applies to your setup.
Offline configuration options and when each fits
This table compares the main ways to get Collabora Online packages, images, fonts and Helm charts into a network with no internet access. Read each row for what the option solves, what it adds to your maintenance load, and what to confirm with Collabora before you commit to it.
| Option | What it solves | Maintenance it adds | What to confirm with the vendor |
|---|---|---|---|
| Mirrored apt or yum repository | Lets package managers on isolated hosts install coolwsd and dependencies from an internal copy of Collabora's deb and rpm repositories | You sync the repository on a schedule, verify signatures, and re-mirror when point releases ship | Which repository keys and paths to mirror, and how signing key rotations are published for offline users |
| Local registry with the collabora/code image | Gives Docker or Podman hosts a pulled, tagged image without external pulls | You pull, scan and push each new tag, and track the rolling CODE release cadence | Whether CODE is permitted for your use, or whether the subscription image is required for production |
| Local registry with the subscription image | Provides a production container image that you can store and redeploy inside the network | Registry access control, image signing checks and tag promotion for each supported update | How the subscription image is licensed for offline pulls and which tags receive security fixes |
| Internal registry with the Helm chart on Kubernetes | Lets the cluster pull Collabora images and chart artifacts from inside the network | Chart version pinning, mirrored dependencies, and manual replica counts because autoscaling is disabled | Which chart version matches your target release and which ingress controllers are supported offline |
| Remote font configuration over HTTPS | Lets you serve approved corporate fonts from an internal HTTPS host instead of shipping them in images | You host and version the font files, and check rendering after each update | Whether your release supports remote font configuration and the exact configuration keys to use |
| Fonts baked into the systemplate | Makes fonts available with no network call at runtime, which suits strict isolation | Each font change requires rebuilding packages or images and retesting document fidelity | Which font installation path applies to your package or container version |
| Offline update bundles | Moves each point release into a network that cannot reach Collabora directly | Manual transfer, hash checks and a staged test environment for every release | How security advisories and signed updates are delivered to customers who cannot connect |
Setting up an offline Collabora Online server step by step
This sequence takes a Collabora Online server from a connected staging network to a working editor inside an isolated network, with each stage closed by a check that proves it is ready. The result is a server that edits documents for a WOPI host without outbound calls, with a recorded trail of what crossed the boundary.
Stage a mirror on a connected network
Build a staging host on a network with internet access and pull everything the target needs: the coolwsd packages from Collabora's deb or rpm repositories, or the Collabora Online container image, plus the base operating system packages and any fonts and dictionaries you plan to ship. Keep the staging host in the same OS release and architecture as the isolated server, since packages that match one distribution often fail on another. Confirm the exact package and image versions you pinned, and record them in a manifest that you will compare against the target later. Done means the staging repository or image store lists every artifact in the manifest and nothing is pulled on demand.
Verify signatures and image digests before transfer
Check each package against the repository signing key you have validated through a trusted channel, and record the key fingerprint. For container images, record the digest of each image and compare it with the digest published by the source before you export it. Collabora's 25.04 release notes record that package signing keys were updated for RPM and DEB users, so confirm the key your staging host trusts is the current one. Done means every package passes signature verification, every image digest matches the recorded value, and the manifest is signed or hashed for the transfer.
Transfer media across the boundary and re-verify
Copy the verified artifacts, the manifest and the checksums onto approved transfer media, and follow your organization's cross-domain procedure for the boundary. On the isolated side, recompute the hashes and re-check package signatures, because the copy is only trustworthy if it matches what you verified upstream. Load the packages into a local repository or the images into a private registry that the isolated server can reach. Done means the local repository or registry serves the same hashes as the manifest and nothing on the isolated network points to an external source.
Install coolwsd or deploy the container image
On the isolated server, install coolwsd from the local repository, or run the Collabora Online image from your private registry. Configure coolwsd.xml or the container environment with the server's internal hostname and the WOPI hosts that will call it, and set the service to start on boot. For packages, confirm the service name and configuration paths against the installation guide for your release. Done means the service runs, listens on the expected interface, and returns its discovery page to a client on the internal network.
Add local fonts, dictionaries and remote feature settings
Install the corporate and document fonts users expect into the system template, and add the spelling and hyphenation dictionaries your users need from the verified staging set. Disable or restrict any feature that fetches remote content, such as remote font configuration over HTTPS, and confirm that the AI assistant is off, since Collabora's 26.04 release made it optional and off by default. Confirm each setting against the documentation for your release because option names change between branches. Done means a test document renders with the intended fonts and no feature attempts a request to an external address.
Point the WOPI host at the server
In the host application, such as Nextcloud, set the Collabora server URL to the internal address and use the same protocol as the host. The Nextcloud administration manual recommends HTTPS for this URL, so issue an internal certificate from your own CA and trust it on both sides. Limit which groups can open the editor and which can edit, using the Nextcloud Office settings, so access follows your existing roles. Done means the host shows the editor for an authorized test user and the server URL in the host settings matches the one you tested.
Restrict WOPI requests to known host IPs
Allow only the WOPI host addresses to reach the Collabora server, both at the network firewall and in the server's allow list, following the Nextcloud guidance to restrict WOPI requests to known addresses. Use fixed addresses for the host, and document any load balancer or proxy in between. Test from an address that is not on the list and confirm the request is refused, then confirm the approved host still succeeds. Done means an unlisted client is denied and the approved host can open, edit and save a document.
Confirm editing works with no outbound calls
Run a test that opens, edits, saves and exports a document in several formats, including docx, xlsx and pptx, while you watch the egress logs of the server and the host. Block all outbound traffic at the boundary during the test and record any connection attempt that fails, because each one points to a setting or resource to fix. Repeat the test after any font, dictionary or configuration change. Done means the test passes with outbound traffic blocked, the logs show no external destination, and the results are kept with the manifest for your audit file.
Disabling remote features and proving the server makes no outbound calls
The remote dependencies you must find and close are not limited to the package repositories you used for installation. Work through each feature that can reach outside the server at runtime: remote font configuration, any remote dictionary or template sources, telemetry or update checks if your release exposes them, and the optional AI assistant that Collabora added in 26.04. The assistant is off by default, but you should confirm that it is disabled in your configuration and not assume it. If you later enable it, administrators choose the AI provider and whether that provider is hosted externally or on infrastructure they control, so an enabled assistant pointed at an external endpoint breaks your isolation requirement. Check each setting against the current Collabora Online documentation for your exact release, including the remote font and configuration options in coolwsd.xml, rather than relying on defaults you remember from an earlier branch.
Prove the result instead of assuming it. Put the host, or the container and its network namespace, on a segment where egress is blocked at the firewall and at the default route, then exercise the server with real editing sessions: open, edit, save and export a representative set of documents, use fonts that are not in the base install, and trigger any feature you have disabled. Review the coolwsd log and the firewall or proxy logs for denied outbound connections and DNS queries over the test window. Any attempt that is denied should be understood and either removed from the configuration or documented as an accepted exception. Keep the test script, the egress rules and the log extracts with your change records, because an auditor or internal assessor will ask how you established the absence of outbound calls, and a repeatable test answers that better than a statement from the installer.
Security controls that matter in an isolated network
An air-gapped deployment removes the internet as a live dependency, but it moves trust decisions into your own process. The controls below decide who can reach the server, how traffic is protected, which packages you accept, and how fixes arrive.
WOPI host allow lists
Collabora Online only accepts document requests from WOPI hosts it has been told to trust. In an isolated network, confirm that the allow list contains only your Nextcloud or other host addresses and nothing broader. The Nextcloud administration manual also recommends restricting WOPI requests to the IP addresses of the Collabora servers, so apply that restriction on the host side as well. Test the rule with a host that should be blocked, not only one that should work.
TLS between Nextcloud and the server
Traffic between Nextcloud and Collabora Online carries document content and session tokens, so it should be encrypted even on a private network. Nextcloud's guidance is to use the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Plan certificates from your internal certificate authority, and confirm that both sides trust that authority without relying on public root stores that an offline host may not have.
Signing key trust chain for offline packages
Packages copied across the boundary are only as trustworthy as the keys that signed them. Import the repository signing keys through a process you can document, record their fingerprints, and confirm that the mirror serves packages signed by those keys. Collabora's 25.04 release notes record that package signing keys were updated for RPM and DEB users, so your offline trust store needs a defined update step as well.
Verifying every transferred artifact
Each package, container image, font file and dictionary that crosses the boundary should be checked before it is installed. Compare checksums against the values published by the source, verify signatures where they exist, and keep a transfer log showing who imported what and when. This is the practical control behind supply chain requirements such as NERC CIP-013-2, which asks for verification of software integrity and authenticity for vendor software and patches.
Group limits in Nextcloud Office
Nextcloud Office lets administrators restrict which groups can use the editor and which groups can edit rather than only view. In an isolated network, this is often the simplest way to limit exposure of sensitive documents to a smaller population. Decide the groups before rollout, document them, and test that a user outside the allowed group cannot open or edit a file through a shared link.
Advisories and offline patch intake
Collabora publishes security advisories for Collabora Online. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. Without internet access, someone must still watch for advisories, decide which fixes apply to your branch, and move the verified update into the network on a schedule. Ask the vendor how advisories are announced to customers and which channel suits a network with no outbound access.
Keeping signing keys and Collabora Online patched without internet access
Keeping an air-gapped Collabora Online server patched is a recurring process, not a one-time install. Run it on a fixed cycle: a connected machine watches the Collabora Online release notes and security advisories, a new point release is mirrored into a transfer staging area, its packages are verified, it is tested on a staging copy of the offline server, and only then is it carried across the boundary. The cycle should have a named owner, a written record of each release reviewed and a rollback path for the staging copy. The exact cadence is a decision for your change board, weighed against how quickly your own policy requires critical fixes to reach production.
Signing keys need the same discipline as the packages. The 25.04 release notes record that package signing keys were updated for RPM and DEB users, so an offline host that still trusts only the old key will refuse newer packages or, worse, be tempted to bypass verification. Plan a step where the refreshed key is obtained from a connected source, its fingerprint is checked against the vendor's published information, and it is imported into the offline trust store deliberately. Record who approved the import and when. Do not disable signature checks to get an update through. This also matters for your supply chain evidence, because you will need to show how each package was verified before it entered the boundary.
Choose the branch you run in production with care. CODE is the free edition, released on average once a month as a rolling release, and Collabora describes it as suited to testing, home use or small teams and not recommended for production. A rolling monthly build is therefore a poor target for an offline estate, because every mirrored update may change behavior you have not tested. Production should follow a supported branch, such as the 25.04 line that was still receiving point releases in 2026, with support terms confirmed against the Collabora Online pricing page. Confirm with Collabora which branch and support tier fit your environment before you build the mirror.
Limits to confirm before you commit to an air gap
An air-gapped rollout fixes the software you can carry across the boundary, the hardware it runs on and how it is operated afterward. The cards below cover the limits that are easiest to miss until the install is underway, and each one should be settled in writing before you buy a subscription or build a cluster.
Subscription and image availability
Confirm that the edition you plan to use can be obtained and updated in your environment. The free CODE edition is a rolling release that Collabora does not recommend for production, so a production air gap usually depends on a supported subscription and its image or package channel. Ask Collabora how signed updates and point releases reach a disconnected network, and who delivers them. Whether a supported subscription includes offline delivery is a question for Collabora, not an assumption to build on.
Architecture support
Check that your target hardware matches a published build before you mirror anything. The CODE image is published for x86-64, ppc64 and arm64, but architecture coverage differs between images and package formats. Mirror only the artifacts for the architecture your servers actually run, and test the exact image or package on that hardware in the isolated network before it reaches production.
No arm64 RPM packages
Do not plan an arm64 RHEL-family server around an RPM install unless the current release notes say the package exists. Verify this against the release you intend to deploy, because a missing package on the wrong architecture is discovered only when the mirror is being built. If your standard is RHEL-family hosts on arm64, choose a container deployment or a supported alternative and make that choice before the bill of materials is final.
Per-pod Kubernetes resources
The Helm chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Those values drive node sizing, so an air-gapped cluster must have capacity for them on hardware you cannot expand quickly. Add the cost of every replica to the cluster plan, and confirm the figures against the chart version you mirror, since defaults can change between releases.
Manual replica management
The Helm chart README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste. Replica counts are therefore set by hand, and load balancers must route by the WOPISrc parameter so that everyone editing one document reaches the same pod. Plan capacity reviews and a documented procedure for changing replica counts, since no offline autoscaler will adjust them for you during a peak.
Questions teams ask before an air-gapped Collabora Online rollout
What drives the cost of an air-gapped Collabora Online installation?
The cost depends mainly on how much of the stack you must carry across the boundary, how many approval steps the transfer requires, and how much testing your document types need. Cost has three parts: the licence or subscription, the internal staff time to build and verify the mirror, and any outside engineering. Licensing is the easiest to estimate. Collabora's Business plan is listed at 3 euros per user per month for up to 99 users, and the pricing page says Enterprise for 100 or more users is quoted with volume discounts, so ask for a written quote for your user count. Labour recurs with every offline update cycle, so ask any partner to price the initial build and the repeat patch process separately.
Can our internal team install Collabora Online in an air-gapped network without a partner?
Yes, if your team already runs Linux servers, package mirrors and a container registry, and can keep a reviewed copy of every dependency inside the boundary. The hard parts are rarely the install commands. They are building a complete offline package set, verifying repository keys and signatures for each transfer, loading fonts and dictionaries that match what users expect, and proving that outbound calls are disabled. Check whether your team has that experience, who will own the monthly patch cycle, and whether anyone has tested rendering of your real documents. A partner can cover any of these as a fixed-scope piece of work.
How long does an air-gapped Collabora Online rollout take?
Duration is driven more by approval and transfer steps than by the software itself. The critical path usually runs through staging network access, security review of each media transfer, and the time needed to validate fonts and document fidelity. Ask for a timeline that separates these phases: mirror creation in a connected staging area, verification of signing keys and checksums, transfer and import, configuration of WOPI host allow lists, and acceptance testing with representative files. Any figure you receive should be tied to a written scope, because the number of approval gates in your organization will matter more than the install itself.
What does the work need from our organization?
Plan for four inputs before the work starts. First, network access for a staging host that can reach the Collabora package repositories and your chosen container registry, and that is isolated from production. Second, approved transfer media and a documented process for moving data across the boundary, including who signs off each transfer. Third, a set of test documents that reflects your real Microsoft Office and OpenDocument files, covering the formats your users actually open. Fourth, the fonts and dictionaries your users need, licensed for internal use and ready to install. Also name a technical owner and a security reviewer who can approve each transfer.
Do Collabora's paid plans include offline support?
Collabora's pricing page describes the Business plan as including long term support, a service level agreement, signed security updates and customer portal access, and describes Enterprise as adding integration support, customization services and roadmap input. The pricing page does not state, in the material supplied here, how support is delivered to a network with no internet access. Ask Collabora in writing whether signed updates and support can be delivered through media transfer, how long security fixes take to reach offline customers, and which plan covers that delivery method. Do not assume offline support from the plan name alone.
How are Collabora Online updates handled when the network is offline?
Each update must be fetched on a connected staging system, checked, and carried across the boundary as a complete set. The release notes show that Collabora ships point releases on existing branches, for example 25.04.7.5 fixed CVE-2026-23623, and that package signing keys were updated for RPM and DEB users. This means your process must re-verify keys and checksums each cycle, not only at first install. Plan a repeatable procedure: subscribe to release notes, test the new point release against your document set, transfer the package set, and record evidence for each step. Confirm the upgrade path between branches with Collabora before you commit to a schedule.
What should we check on the signing keys and package repositories?
Check that every package you carry across the boundary is signed by a key you have verified from a trusted source, and keep a record of the fingerprint used for each transfer. Collabora's release notes state that signing keys have been updated for RPM and DEB users, so a key rotation can happen during a maintenance window and break an offline mirror that was built before it. Store the keys inside the boundary with the packages, and document how a new key would be verified. Your supply chain procurement process should cover verification of software integrity and authenticity for patches, which is the control NERC CIP-013-2 describes for its own sector.
How DeployOpen scopes and delivers an offline Collabora Online build
DeployOpen starts an offline Collabora Online build with a written, fixed scope agreed before any work begins. The scope names the install path (Linux packages or Docker images, and whether the built-in CODE app or a dedicated server is in play), the artifacts to be mirrored into your repository or registry, the fonts and dictionaries to be staged, the WOPI host configuration, the offline patch procedure and the handover documentation. The quote follows from that document, so the scope is where your team should spend its review time. Ask for each deliverable to be listed with an acceptance check, such as a documented install that completes with no outbound connections from the Collabora host, and a named owner on your side for the network and approvals.
Because air-gapped work changes what counts as a deliverable, the scope should also say who handles each recurring step. A mirrored artifact list with checksums is the item most often left vague: it should cover the packages or images, their signing keys, and the update cadence you intend to follow. DeployOpen can run the initial mirror and the first patch cycle, then document the steps your staff repeat. Ongoing support, upgrades and continuous testing are available as retainers, which suits teams that want an outside party to carry each offline update through staging before it reaches production.
DeployOpen prepares systems, controls and evidence for compliance assessments, such as the change records, configuration baselines and patch logs that a reviewer will ask for when a regulator or customer audits your isolated environment. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early which evidence your assessor expects and build the handover package around it. Where a sector rule applies, such as supply chain verification of software carried across an isolated boundary, write that requirement into the scope so the delivered procedure matches it.
