Collabora Online in openDesk

How Collabora Online works as the web office in openDesk

openDesk bundles Collabora as its web office, so document editing is part of the suite rather than a separate product the public administration team has to procure and wire in. The openDesk deployment README lists Collabora among the bundled components and states that each component keeps its own license. For Collabora Online, that license is the Mozilla Public License 2.0 (MPL-2.0), as recorded in the server's COPYING file. Collabora Online is a browser-based editor built on LibreOffice technology, and it reaches the file layer through WOPI, the protocol that lets a host application such as the file store hand a document to the editor and receive it back. In openDesk, the file layer is Nextcloud, so the team's first question is how the editor and Nextcloud find each other and which side owns access decisions.

The openDesk deployment automation is Helmfile and Helm based, so Collabora is installed by the same release process as the other components. Installation is not operation. After the first deployment, the owner of the openDesk environment is responsible for patching the editor, watching its security advisories, sizing it for concurrent sessions and handling incidents. The openDesk release management documentation describes monthly minor releases and a supported latest minor version, but the team should confirm with ZenDiS or its own support provider exactly which Collabora version each openDesk release ships and how that version is updated between releases. Do not assume that an openDesk upgrade also upgrades Collabora to the newest Collabora Online branch.

Confirm the following in your own environment before go-live: the Collabora version pinned in your openDesk release, the WOPI addresses and TLS settings between Nextcloud and the editor, whether your ingress routes all requests for one document to the same pod, and whether your deployment uses the openDesk Enterprise Edition. The Enterprise documentation lists Collabora branding and automatic load scaling as Enterprise-only features, so scaling behavior depends on your edition. Ask your openDesk provider to document which of these settings they manage and which remain with your team, and keep that record with your runbook.

What openDesk needs before Collabora goes live

openDesk is deployed as Helm charts managed by Helmfile on a Kubernetes cluster, and Collabora Online runs inside that stack as the web office. The cards below cover the platform layer, the external services openDesk expects in production, and the evaluation hardware floor, so you can confirm your target environment before planning the Collabora rollout.

CNCF-certified Kubernetes cluster

openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later. Collabora Online is deployed as one of its components, so the cluster version sets the baseline for every chart you install alongside it. Check that your distribution is certified and that your upgrade plan keeps the cluster on a supported version. The openDesk project tests on kubespray clusters, so confirm with your platform team how your distribution differs from that tested path.

Ingress controller choice

openDesk supports haproxy-ingress or the deprecated Ingress nginx controller. Collabora Online's WOPI traffic depends on routing decisions made at this layer, so the choice affects how requests reach the editor pods. Pick haproxy-ingress for new builds, and plan a migration if your environment already runs Ingress nginx. Confirm how your controller will keep all requests for one document on the same pod before going live.

Certificate management with cert-manager

openDesk expects cert-manager to issue and renew the TLS certificates for its public hostnames. The Nextcloud and Collabora Online connection must use HTTPS end to end, so an expired certificate breaks document opening, not just the login page. Confirm which issuer your organization uses, whether it is an internal certificate authority or a public one, and that the certificate chain is trusted by the browsers and services that call Collabora.

RWO volume provisioner

openDesk needs a storage provisioner that supplies ReadWriteOnce volumes for stateful components. Confirm that your storage class is available in every zone or node pool where openDesk pods may be scheduled, and that it supports the volume expansion and snapshot behavior your backup plan assumes. Collabora Online itself keeps document state in the document store rather than in its own volumes, so storage planning for the editor is mainly about the surrounding services.

Helm and Helmfile versions

openDesk deployment is driven by Helmfile, and the requirements call for Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. Pin both versions in your deployment pipeline so that a Collabora chart upgrade does not change the tooling underneath it. Helm 4 is outside the supported range, so do not let a workstation or runner upgrade it silently.

External production services

For production, openDesk expects external, production-grade services rather than in-cluster test instances. These include PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Collabora Online's file handling depends on the storage and scanning services, so ask who operates each one, what backup and high availability they have, and how they are sized before you commit to a timeline.

Evaluation hardware floor

The minimum for an openDesk evaluation deployment is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk. This floor is for evaluation only. Production sizing depends on the number of users, the document workload and the external services listed above, so treat these figures as a starting check rather than a capacity plan. Confirm that your hosts meet the floor and plan separate capacity for Collabora editing sessions.

Confirm the target platform

ARM is not supported yet for openDesk, and the project does not test on OpenShift. If your organization standardizes on ARM nodes or an OpenShift platform, resolve that before planning the Collabora rollout, because the architecture and cluster distribution determine what can be deployed. Ask your platform team to confirm the CPU architecture and the Kubernetes distribution in writing before scope and timeline are agreed.

Evaluation or production: which openDesk edition changes the Collabora setup

An evaluation deployment shows how the Collabora editor behaves inside openDesk. It is not sizing evidence and should not hold live public administration data. The documented minimum is the floor for a single-cluster trial. Enterprise Edition uses the same open-source core licenses and adds closed-source modules, so the editing you test is built from the open-source core that production also relies on.

Hardware floor: 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk. ARM hosts are not supported yet.
Kubernetes baseline: a CNCF-certified cluster at v1.33 or later, an ingress controller, cert-manager and an RWO volume provisioner. The deployment is tested on kubespray clusters, not OpenShift.
Single Collabora replica: a trial can run with one pod, but test WOPISrc routing before relying on more replicas.
Document fidelity: open your own Word, Excel and PowerPoint templates in the editor, because formatting problems usually appear only with your files.
Production services: the trial may use stand-in services, so record every substitution you make.

Confirm with ZenDiS or your provider which trial substitutions are acceptable and which must match production before you carry any results forward.

Bringing Collabora Online up in an openDesk deployment

This sequence takes an openDesk deployment from a verified Kubernetes foundation to a tested Collabora Online web office, with each step closed by a check your team can record. It is written for platform engineers and security owners who need the editor running inside the sovereign workplace suite and provably reachable only from the expected servers.

Confirm cluster and tooling versions
The platform engineering lead checks the Kubernetes cluster against the openDesk requirements: a CNCF-certified distribution at v1.33 or later, Helm 3.17.3 or later below v4, and Helmfile 1.0.0 or later. Confirm the cluster's RWO volume provisioner and the test or production status of your distribution, because openDesk is tested on kubespray clusters and not on OpenShift. The step is done when every version is written down against the requirements page and the cluster passes a basic health check.
Confirm ingress and certificate issuance
The platform team selects the ingress controller, either haproxy-ingress or the deprecated Ingress nginx, and confirms the cert-manager issuer that will issue certificates for the openDesk hostnames. Collabora's WOPI traffic must reach the correct pods, so ask the ingress configuration to preserve the WOPISrc parameter, a point the Collabora Helm chart documentation also requires for load balancers. The step is done when a test certificate is issued by the chosen issuer and the ingress controller serves it on a test hostname.
Provision the external production services
The infrastructure team provisions the services openDesk expects for production: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Record each version and endpoint in the deployment values, and confirm each against the openDesk requirements and the deployment README, since those files govern which versions are supported. The step is done when every service accepts connections from the cluster and the version list matches the requirements.
Deploy through the openDesk Helmfile workflow
The deployment engineer clones the openDesk deployment repository, sets the environment values for your domains, identity provider and external services, and runs the Helmfile and Helm workflow described in the deployment README. Confirm which values the README requires for Collabora, including its resource settings and replica count, and record them in version control rather than in ad hoc commands. The step is done when the release completes without failed hooks and every Collabora pod reports ready.
Verify the deployed release version
The release owner compares the deployed openDesk version with the latest release on the releases page and the release management policy. The policy states that only the latest minor version is supported, that in-place upgrades between majors are not guaranteed, and that skipping several minor versions may need intermediate steps. Record the version, the date of the check and any intermediate steps the policy calls for. The step is done when the deployed version is confirmed as supported or a documented upgrade path is agreed.
Test pod reachability to the Nextcloud WOPI endpoint
The network engineer confirms that the Collabora pods can reach the Nextcloud WOPI endpoint over the address and protocol configured in the deployment, and that Nextcloud can reach the Collabora discovery URL. Use HTTPS for the Collabora server URL, matching the protocol used for Nextcloud, as the Nextcloud administration manual recommends. The step is done when both directions return successful responses from the test hostnames and the results are logged.
Confirm the WOPI allow list
The security engineer checks that the WOPI host allow list accepts only the addresses of the Nextcloud and openDesk ingress components expected in your environment. The Nextcloud administration manual recommends restricting WOPI requests to the Collabora server addresses, so compare the configured list against your network inventory and attempt a request from an address outside it. The step is done when the outside request is refused and the expected request succeeds, with both results recorded for the audit file.
Run open, edit and save tests by format family
The acceptance tester opens, edits and saves one test document in each format family: OpenDocument text, spreadsheet and presentation, Microsoft docx, xlsx and pptx, and PDF. Use documents that represent your real content, copied into a test library, and check that each edit persists after reload. Record any formatting differences as defects before users rely on the editor. The step is done when every format family passes the open, edit and save cycle and the results are signed off by the business owner.

Which identities, groups and files map between openDesk and Collabora

This table compares how a user, group, WOPI host address, file format and document version moves from the openDesk identity and file layers into a Collabora Online editing session. Read each row as a question to answer in your own environment before go-live, since the check items show where the supplied facts stop. The main takeaway is that the editor inherits access from Nextcloud and Nubus, so permission mistakes usually start upstream of Collabora.

Item	Source system	Collabora side	What to check
User identity	Nubus for portal and IAM, passed through to Nextcloud	Editor session opened from a WOPI request issued by Nextcloud	Confirm how openDesk identities reach Nextcloud and that a disabled account loses editing access in the editor.
Group permissions	Nextcloud Office group settings	Editor access limited by group, with view-only and edit rights set separately	Map which groups may open the editor and which may edit, and test a view-only user before rollout.
WOPI host URL and protocol	Nextcloud Office configuration and openDesk ingress	Collabora server URL the WOPI host calls back to	Use HTTPS and the same protocol as Nextcloud, and confirm the Collabora endpoint is reachable from the Nextcloud side.
WOPI request source restriction	Nextcloud allow list and network policy	Collabora server addresses permitted to send WOPI requests	Confirm the Collabora server IP addresses in your openDesk cluster and restrict WOPI requests to them.
File formats in scope	Nextcloud file storage	OpenDocument, docx, xlsx, pptx, PDF, RTF, CSV and Visio files	Run a fidelity test on your own sample documents, since format support is listed but layout fidelity is not confirmed here.
Documents and version history	Nextcloud file storage and versioning	Editor saves back through WOPI to the stored file	Confirm how Nextcloud keeps versions created by editing sessions and how restores behave for co-authored files.
Collabora server version and patch level	openDesk release and bundled Collabora component	Collabora Online build delivered within the openDesk release	Confirm the bundled Collabora version and the patch process, since advisories apply to the server build.

Why Collabora replicas need WOPISrc routing in openDesk

The Collabora Helm chart disables horizontal pod autoscaling, because scaling breaks collaborative editing and copy and paste. The chart's README states that replica counts are set manually and that the load balancer must route by the WOPISrc parameter, so every user editing one document reaches the same pod. In an openDesk deployment, that routing rule sits in the ingress layer that openDesk already requires (haproxy-ingress or the deprecated Ingress nginx), so the platform team has to confirm that the ingress configuration matches the Collabora service and that each replica receives the sessions for its own documents. Test this with two users opening the same file from different browsers before any capacity change goes live.

The openDesk Enterprise Edition lists Collabora branding and automatic load scaling among its Enterprise-only features. On the open-source path, that automatic scaling is not available, so the capacity plan becomes an operator responsibility. Someone must decide how many Collabora replicas run at peak, who changes the replica count and when, and what triggers a change. Those decisions need to be written into the operations runbook, with the ingress routing rule and the replica setting treated as one change set. Ask ZenDiS and your integrator which Collabora components the openDesk release you deploy includes, and confirm whether the deployment exposes replica counts as values you can set.

The Collabora 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. Treat these as chart recommendations, not a sizing promise. They describe one pod, and the number of pods, the document types your users open and the concurrency you expect all change the real footprint inside openDesk, alongside the other bundled services that share the same cluster. Validate the values against your own load tests and the openDesk sizing guidance for your release, and record the result as part of the capacity plan.

Securing the Collabora path inside openDesk

The browser editing path runs from the user through Nextcloud to the Collabora server, and each hop needs its own control. The cards below cover the WOPI, transport, access, patching, package and network controls that matter when Collabora Online is the web office in an openDesk deployment. Each control is something your team configures, verifies and keeps running, with evidence kept for assessors.

Restrict WOPI to Collabora addresses

Nextcloud's administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers. In an openDesk cluster, confirm the addresses that actually reach Nextcloud after ingress and load balancing, since the source address seen by Nextcloud may differ from the pod or node address you expect. Recheck the allow list after every change to ingress, cluster networking or the Collabora replica set, because a stale entry either blocks editing or leaves the path wider than intended.

Use HTTPS between Nextcloud and Collabora

The same protocol, preferably HTTPS, should be used for the Collabora server URL as for the Nextcloud installation. Mixed protocols lead to blocked or failing sessions and tempt teams to weaken transport settings to make errors go away. Terminate TLS with certificates managed in the cluster, confirm the discovery URL that Nextcloud uses is the HTTPS endpoint, and test document opening from a clean browser session after each certificate renewal.

Limit who can edit by group

In Nextcloud Office, administrators can limit which groups may use the editor and which groups may edit rather than only view. Map these rules to the groups provisioned through the openDesk identity layer so that access follows the organization's existing roles. Review the group assignments on a schedule, because editor rights granted to a broad group quietly extend the set of users who can change official documents.

Stay on the supported release line

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. Track the branch your openDesk release uses, subscribe to advisories, and apply signed point releases on a defined schedule. Confirm with ZenDiS which Collabora version each openDesk release ships, because a patch you apply by hand outside the release train may conflict with the deployment.

Verify package signing keys

If any Collabora component is installed from RPM or DEB packages rather than the bundled container path, verify package signatures against the current keys. The 25.04 release notes record that package signing keys were updated for RPM and DEB users, so an old key left in a repository configuration can cause installs or updates to fail or, worse, lead teams to disable verification. Document the key fingerprints you trust, and rotate them through a controlled change.

Scope network policy to Nextcloud and ingress

Only the ingress controller and Nextcloud should reach the Collabora service. Write Kubernetes network policies that admit traffic from those sources on the required ports and deny other pods, namespaces and administrative paths. Test the policy with a pod that is not supposed to connect, and confirm that WOPISrc-based routing still reaches the same replica for each document, since the policy must not break sticky routing or the collaborative session.

Prepare evidence, not certification

DeployOpen prepares controls, configuration records and test evidence for compliance assessments. Independent auditors and certification bodies assess them, and this path does not by itself satisfy any named framework. Keep dated configuration exports, allow list history, patch records, signing key changes and policy test results together, and ask your assessor early which evidence they expect for the openDesk scope.

Common openDesk Collabora failures and where they start

This table pairs common Collabora Online symptoms inside an openDesk deployment with their likely causes, the first check to run and the usual fix. Read it top down when a fault appears, starting with the cheapest check. Most failures trace back to WOPI routing, replica handling, ingress support, resource requests, file testing or version gaps.

Symptom	Likely cause	First check	Fix
Documents open read-only or fail to open	WOPI allow list or protocol mismatch between Nextcloud and Collabora	Compare the Collabora server URL and Nextcloud URL for the same protocol, ideally HTTPS	Align protocols and allow only the Collabora server IPs in the WOPI settings
Edits lost or copy and paste failing after scaling	Load balancer not routing by WOPISrc, or replicas changed during live sessions	Confirm routing keys on the WOPISrc parameter and check whether replica counts changed	Route by WOPISrc, set replicas manually and schedule changes outside editing hours
Ingress returns errors	Ingress controller not on the supported list, or cert-manager issuer missing	Check the ingress controller type and the cert-manager issuer and certificate status	Use a supported controller such as haproxy-ingress and create the missing issuer
Pods restart under load	Memory and CPU requests below the chart recommendation	Compare pod requests and limits with the Helm chart README values	Raise requests toward 4 cores and 6000 MiB and limits toward 8 cores and 8000 MiB
Format fidelity complaints	Documents were never tested with the team's own files	Open a sample of real team documents in the editor and compare with the source	Build a test set from team files and log fidelity issues before wider rollout
Upgrade failures	Several openDesk minor versions skipped, which may need intermediate steps	Check the installed openDesk version against the release management guidance	Upgrade stepwise through the documented intermediate versions in a test environment first

What buyers ask before running Collabora Online in openDesk

What drives the effort of an openDesk Collabora Online rollout?

The main drivers are cluster readiness, the external services openDesk expects in production, sizing, format testing and the user rollout. The openDesk requirements call for a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. For production, openDesk also expects PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, so each of these may need to exist before Collabora is deployed. Sizing follows the Helm chart guidance to set replicas manually and route by WOPISrc, with production limits of 8 CPU cores and 8000 MiB per pod. Testing your own templates and file types, then moving users in phases, adds effort on top of the build.

Can our own team run Collabora Online in openDesk without a partner?

Yes, a team with solid Kubernetes and Helm skills and some openDesk experience can run the deployment, but the answer depends on your skills and your support obligations. openDesk is deployed with Helmfile and Helm, so the team must maintain that automation, manage ingress and certificates, and troubleshoot WOPI connectivity between the editor and the hosting application. ZenDiS recommends openDesk Enterprise Edition for production. The Enterprise Edition adds SLA-backed 2nd and 3rd level support and patches, along with Enterprise-only features such as Collabora branding and automatic load scaling. If you stay on the open-source edition, your team carries that support load itself. Ask for specific tasks, such as the initial build, the first upgrade or a security review, to be quoted separately so you can compare them with in-house effort.

How is Collabora Online priced inside an openDesk deployment?

Collabora's public pricing is per user for standalone Collabora Online, and the Collabora component inside openDesk may be licensed or supported through a different path, so confirm which one applies to your deployment. The Collabora Online pricing page lists the Business plan at 3 euros per user per month for up to 99 users, including long term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan for 100 or more users is quoted with volume discounts and adds integration support, customization services and roadmap input. openDesk Enterprise Edition is a separate ZenDiS offer, sold as SaaS or for on-premises installation. Recurring costs include subscriptions, the infrastructure that runs the cluster and staff time for upgrades. Ask for each cost line in writing and mark which items are one-time and which recur.

How often does openDesk release updates, and which versions get support?

openDesk plans major releases once a year in Q3, minor releases monthly and patch releases on demand. Only the latest minor version is supported, so an installation that falls behind must catch up before it receives support. In-place upgrades between major versions are not guaranteed, and skipping several minor versions may require intermediate steps. The latest release at research time was v1.19.1, published on 2026-10-06, after v1.19.0 on 2026-10-01. Because each openDesk minor release may change the bundled Collabora component, plan a test cycle on a staging cluster for every minor release. Read the release notes and the release management guidance before each change, and confirm with ZenDiS or your partner how upgrade windows, rollback and document editing checks are handled.

What must our team provide before a Collabora Online in openDesk rollout starts?

Before work starts, the team needs to provide access to the target Kubernetes cluster and its namespaces, DNS records for the openDesk hostnames, TLS certificates or a cert-manager issuer, and the identity configuration openDesk will use for sign-in. You also need test users in each role, sample documents that match your production templates, and a named owner who can approve decisions. If you connect an external identity provider, the openDesk federation documentation describes the configuration to review early. Confirm who provisions each external service listed in the requirements, including the database, SMTP relay, object storage and TURN server. Record these inputs in the written scope so each one has an owner and a milestone.

How long does an openDesk Collabora Online rollout take?

The duration depends on the scope agreed in writing, so no single figure applies to every environment. A proof of concept on one cluster takes less time than a production rollout that includes external services, identity federation, format testing and a phased user migration. The openDesk evaluation minimum of 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk applies to evaluation only, so production sizing is a separate step. Cluster readiness, approval of external services, identity configuration and the number of document types to test are the factors most likely to extend the schedule. Ask for the duration in the quote, along with the milestones, the deliverables for each milestone and the exit criteria for document fidelity testing.

How should Collabora Online replicas and ingress be set up in openDesk?

Set replica counts manually, because the Helm chart disables horizontal pod autoscaling. Scaling breaks collaborative editing and copy and paste, and the load balancer must route by the WOPISrc parameter so all users editing one document reach the same pod. The chart recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. The chart supports Nginx, HAProxy and OpenShift Router ingress, but the openDesk requirements name haproxy-ingress or the deprecated Ingress nginx and state that openDesk is tested on kubespray clusters, not OpenShift. Confirm that your ingress choice is supported by the openDesk release you deploy, then run load tests with representative concurrent editing sessions before you fix replica counts.

How DeployOpen scopes, delivers and supports Collabora in openDesk

DeployOpen treats Collabora Online inside openDesk as one component of a Kubernetes-based workplace suite that your team must operate. We start from a written scope that names the openDesk release, the cluster, the ingress and the editor's place in your support model, then build, document and hand over the work in your own infrastructure.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names the openDesk release, Kubernetes version, ingress controller and whether you run the Enterprise Edition.
We confirm which Collabora Online features and licensing tier your openDesk deployment uses before any build begins.
Scope includes which user groups may open and edit documents, and how that access maps to your identity setup.

How we build

Deployment follows the openDesk Helmfile and Helm automation in your own cluster, with changes tracked in version control.
We check the Collabora Online routing so that all users editing one document reach the same pod.
Testing covers document round trips for the formats your staff use, including docx, xlsx, pptx and PDF.
Resource limits, replica counts and the external services openDesk expects are set and verified against your sizing targets.

How we hand over

Handover includes configuration records for the editor, ingress, certificates and the external services it depends on.
Runbooks describe how to change the openDesk release and how to check the editor after each minor update.
Your operators receive a test script to confirm document editing after upgrades, restores or node changes.
Documentation records which parts of the stack are supported by ZenDiS and which are your responsibility.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
Upgrade work follows the openDesk release cadence, including minor updates and any intermediate steps the release notes require.
Security testing of the deployed stack can be scoped alongside support, with findings tracked against your change process.
Ask any provider to confirm which tier of support and patches they are contracting for before you rely on it.