When a single Collabora Online server is enough and when Kubernetes earns its cost
A single Collabora Online server is enough for a team with a small or moderate editing load and no existing cluster. Kubernetes earns its cost when your platform team already runs a cluster and needs several Collabora pods behind one entry point. Whichever you choose, you attach Collabora to Nextcloud, ownCloud or Seafile through WOPI, so the file platform's administrators, not the editor, decide who can open which document. Start by counting the concurrent editors you expect at peak, then compare that load against the per-pod resources in the Helm chart README before you pick a topology.
The Collabora Online Helm chart disables Horizontal Pod Autoscaling because scaling breaks collaborative editing and copy and paste, so you set replicaCount yourself and change it through a planned change, not a metrics rule. On Kubernetes, session affinity is mandatory: the load balancer must route by the WOPISrc parameter so every user editing one document reaches the same pod. The chart documents HAProxy Ingress with balance url_param WOPISrc and consistent hashing, NGINX ingress hashing on WOPISrc, and an in-namespace nginx reverse proxy for platforms such as OpenShift where an ingress controller cannot be installed. If your ingress cannot be configured this way, a single server avoids the problem entirely.
Kubernetes adds cost that a single server does not carry: a control plane you must keep patched, an ingress path you must test against the affinity rule, and an etcd and secrets posture you must own. Ask your team whether the cluster already meets these needs. The production guidance is also heavy, with requests of 4 CPUs and 6000Mi per pod and limits of 8 CPUs and 8000Mi, plus --o:num_prespawn_children=4, so confirm node capacity before you add replicas. Test a single-server rollout first, measure editing latency with your own documents, and move to Kubernetes only when the cluster and the load justify it.
Single server vs Kubernetes deployment factors
This table compares running Collabora Online as one server or container beside your file sync platform with running several pods from the official Helm chart. Read each row as a decision point, and use the Kubernetes column to judge whether your team can carry the extra routing, sizing and upgrade work. The main takeaway is that a Kubernetes layout adds operating obligations that a single server does not, so choose it only when your team already runs Kubernetes.
| Factor | Option A: single server or container | Option B: Helm chart on Kubernetes |
|---|---|---|
| Existing platform skills | Fits teams that already run Docker or system packages next to their file sync platform | Assumes your team can operate Kubernetes, ingress and the WOPISrc routing the chart requires |
| Number of pods and replicas | One server or container serves all editing sessions | Several pods, with replica count set by hand through replicaCount |
| Session affinity | Not needed, since all users reach the same instance | Required: all users editing one document must reach the same pod |
| Ingress options | Your existing web server or reverse proxy in front of the instance | HAProxy or NGINX ingress hashing on WOPISrc, or an in-namespace nginx proxy where no ingress controller can be installed |
| Scaling method | Vertical, by giving the host or container more CPU and memory | Manual replica count only, because Horizontal Pod Autoscaling is disabled in the chart |
| Per-pod resources | Sized to your host; confirm the CPU and memory your document load needs | Chart recommends requests of 4 CPUs and 6000Mi memory and limits of 8 CPUs and 8000Mi per pod for production |
| Upgrade path | Replace the container or package on your own schedule | Helm upgrades across pods, plus any Kubernetes version changes your cluster needs to track |
| Cost drivers | Host capacity and your staff time for one deployment | Cluster nodes, ingress setup, staff time for Kubernetes operations and the per-pod resource footprint |
How the two options fit different teams
If your team does not operate Kubernetes, a single server or a single container host next to your file sync platform is usually the simpler path. Collabora Online can be deployed from Docker images, from system packages or on Kubernetes, so the single-host route does not require a cluster. The Helm chart's session affinity rules only matter once you run several pods, so a single instance avoids the routing design entirely. The work sits in keeping one host patched, sized and backed up, and in wiring the WOPI connection from your file platform to Collabora.
- Deployment method: Docker images or system packages, both documented by Collabora.
- Routing: no pod-level affinity is needed when one instance serves all sessions.
- Scale path: moving later to several pods means redesigning ingress and affinity, so plan for it early.
- Kubernetes skills: not required, but someone must still own host updates and restores.
Confirm with your file platform team that its WOPI setup works against the single host address and TLS configuration you plan to use.
If your platform team already runs Kubernetes, the Collabora Online Helm chart gives you a documented starting point. The chart expects you to set replica counts by hand because horizontal pod autoscaling is disabled, and it requires load balancing on the WOPISrc parameter so that all users editing one document reach the same pod. Your team takes on the ingress design, the per-pod resource planning and the change process for each new release. Kubernetes itself is open source under Apache 2.0, so the platform cost sits in the cluster you already operate rather than in a new license.
- Ingress: HAProxy Ingress with balance url_param WOPISrc and consistent hashing, or NGINX ingress hashing on WOPISrc.
- Replicas: set
replicaCountmanually, since autoscaling is disabled. - Resources: the chart recommends 4 CPUs and 6000Mi memory as requests, and 8 CPUs and 8000Mi as limits, per pod, for production.
- Upgrades: Kubernetes ships about three minor releases a year, so the cluster upgrade calendar must include Collabora.
- Pool sizing: confirm node capacity for the per-pod figures before scheduling several replicas.
Confirm that your ingress controller supports consistent hashing on a URL parameter, since the affinity rule depends on it.
On an OpenShift-style platform, you may not be allowed to install a separate ingress controller. The Collabora Online Helm chart covers this case by deploying an in-namespace nginx reverse proxy, and it supports the OpenShift Router as an ingress option. This keeps the affinity requirement intact without a cluster-wide change, but it adds a proxy layer your team must monitor, patch and include in its change records. Confirm the platform's policy on controllers and on which images your cluster can pull before you start.
- Proxy option: the in-namespace nginx reverse proxy avoids a new cluster-wide controller.
- Router option: the OpenShift Router is supported by the chart.
- Security context: confirm how the platform's admission rules apply to the chart's pods and containers.
- Image sourcing: check whether your registry policy allows the Collabora images and their updates.
- Extra layer: the proxy becomes one more component in your certificate, logging and patch processes.
Confirm with the platform team which routing object they accept, because that choice decides how much of the affinity design you can keep unchanged.
The free CODE edition, distributed as the collabora/code Docker image for x86-64, ppc64 and arm64, suits testing, home use or small teams. Collabora describes CODE as a rolling release that is not recommended for production, so it is a poor base for a regulated deployment even when the technical setup looks identical to the supported build. Use CODE to validate the WOPI connection, the ingress routing and the document fidelity you need, then decide whether the production build is required. The same test rig can show whether collaborative editing works through your chosen affinity rule.
- Image: collabora/code for x86-64, ppc64 and arm64.
- Release model: a rolling release published on average once a month.
- Production fit: Collabora does not recommend CODE for production use.
- Test scope: check multi-user editing and copy and paste across pods before the design is frozen.
- Upgrade path: plan how a test configuration moves to the supported build.
Confirm with Collabora which build and support terms your organization needs before you promote anything from a CODE test into production.
What runs in each topology
Collabora Online can run as one container beside your file platform or as several pods behind an ingress on Kubernetes. The cards below cover the moving parts in each setup, and the decisions that change when you choose one over the other.
Single container or server
A single Collabora Online instance is the simplest topology: one container or server process that your file platform calls over WOPI. Every user editing a document reaches the same instance, so collaborative editing and copy and paste work without extra routing. The trade-off is that capacity is bounded by one host, and a restart or failure stops all editing. Before choosing this model, confirm the concurrent editing load you expect and whether a short outage is acceptable for your users.
Kubernetes pods and replicaCount
On Kubernetes, the Collabora Online Helm chart runs several pods, and you set the count yourself through replicaCount. Horizontal Pod Autoscaling is disabled in the chart because scaling breaks collaborative editing and copy and paste, so capacity changes are planned changes, not automatic ones. Ask your platform team who owns the replica decision and how a replica change is tested before it reaches production users.
WOPI integration with the file platform
Your file platform, such as Nextcloud, ownCloud or Seafile, sends users to Collabora Online through the WOPI protocol, and the WOPISrc parameter identifies each document. That identifier is also what the load balancer uses to pin all editors of one document to one pod. Confirm that your file platform's WOPI URL configuration matches the discovery endpoint your Collabora deployment exposes, because a mismatch breaks editing in both topologies.
Ingress or reverse proxy layer
On Kubernetes, the chart documents HAProxy Ingress with balance url_param WOPISrc and consistent hashing, or NGINX ingress hashing on WOPISrc. Where an ingress controller cannot be installed, such as some OpenShift clusters, the chart can deploy an in-namespace nginx reverse proxy instead. Check which controller your platform team already supports, and whether session affinity is enforced at the ingress rather than left to default round-robin behavior.
Collabora Online Controller for large deployments
Collabora offers the Collabora Online Controller for large deployments, according to its product page. It is a separate operational layer to evaluate once a single deployment grows beyond what one set of pods covers. Ask Collabora what the controller manages, how it interacts with the chart's replica and routing settings, and what support covers it under the paid edition before you plan around it.
Per-pod resources for production
The chart's production guidance sets per-pod resource requests of 4 CPUs and 6000Mi of memory, with limits of 8 CPUs and 8000Mi, and adds --o:num_prespawn_children=4 so child processes start in advance. Each pod therefore claims a large share of a worker node, which affects how many pods fit in your cluster and how you size node pools. Confirm these values with your capacity plan and load test them against your document mix before going live.
Why session affinity and ingress choice decide the Kubernetes design
Collaborative editing and copy and paste only work on Kubernetes when every user editing the same document, and every clipboard request, lands on the same pod. The Collabora Online Helm chart README states this requirement directly, and it means the design question is not only how many replicas to run but how traffic is pinned to them. The chart's documented answer is to load balance on the WOPISrc identifier in the WOPI URL, so that the ingress hashes each document's WOPI request to one backend. A plain round-robin service in front of several pods will split co-editors across pods, and the failure may only appear when two people edit the same file at once, which makes it easy to miss in a basic smoke test.
The chart documents three ways to get that hashing. HAProxy Ingress can be configured with balance url_param WOPISrc and consistent hashing. The NGINX ingress can hash on WOPISrc as well. Where neither controller can be installed, for example on some OpenShift clusters, the chart can deploy an in-namespace nginx reverse proxy to do the routing. Each option moves a different piece of the design: the first two depend on which ingress controller your platform team already runs and supports, while the in-namespace proxy adds one more component to patch, monitor and secure. Confirm with your platform team which controller is approved, whether its hashing annotation or configuration is supported in your version, and whether the WOPI path passes through unchanged to the pod, before you commit to a replica count.
Test affinity with two sessions on one document, not with a single user. Open the same document from two browsers, type in both, and copy text from one session into the other. Repeat after a rolling restart of the Collabora pods and after any ingress reload, since a failed hash will show up as lost edits or broken clipboard transfers. Because horizontal pod autoscaling is disabled in the chart, pod count changes are manual, so the runbook should state who changes replicaCount and how sessions are checked afterwards. This test also belongs in your acceptance criteria for the file platform that calls Collabora, because the same WOPI requests come from that platform.
Questions teams ask before choosing a Collabora Online deployment
Is a single Collabora Online server enough for our team?
For many small and mid-sized teams, a single server or container next to the file sync platform is the simpler starting point, and the choice depends on how many people edit at the same time and how much hardware you can dedicate. Collabora's Helm chart README recommends production pods with requests of 4 CPUs and 6000Mi memory and limits of 8 CPUs and 8000Mi, so size your host around that per-instance figure and test concurrent editing with your own documents. The main drivers are peak concurrent sessions, document size and whether you need separate failure domains. Ask Collabora or your own load tests to confirm capacity before committing to one design.
What makes running Collabora Online on Kubernetes costly beyond the Helm chart?
The chart is only one component. The larger costs usually sit around it: a cluster you operate, an ingress controller configured for session affinity, monitoring, backups, and the staff time to patch nodes and the control plane. Kubernetes itself is open source under Apache 2.0, so the license is not the cost; the cluster operations are. Cost drivers include the number of control plane nodes, etcd backups and the team's familiarity with the platform. Ask for a written scope that lists which of these items sit inside the engagement and which stay with your platform team.
Can our own team run a Collabora Online deployment without outside help?
A team with solid Linux, container and reverse proxy skills can run a single-server deployment without outside help, provided it has an update routine and a tested backup plan. A Kubernetes deployment asks more: the team needs to handle session affinity on the WOPISrc parameter, manual replica counts because autoscaling is disabled, and cluster-level maintenance. Be honest about who will be on call. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure under a written, fixed scope, and ongoing support is available as a retainer.
How long does a Collabora Online deployment take to complete?
No supplied source gives a typical duration for deploying Collabora Online on a single server or on Kubernetes, so treat any published timeline with caution. The schedule depends on the number of environments, the ingress and identity setup, how many file platforms connect through WOPI, and how much testing your documents need. Ask for the timeline in the written scope, and ask which milestones depend on your cluster or infrastructure being ready. Your own environment, including change windows and approval steps, will often set the critical path.
What does Kubernetes version support and skew mean for upgrades?
Kubernetes maintains the three most recent minor releases, and the version skew policy requires kube-apiserver to be upgraded one minor version at a time before the other control plane components and kubelets. Kubelets may run up to three minor versions behind the API server, which gives you room to stagger node upgrades. As of September 2026, the supported minor releases were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027), per kubernetes.io/releases. Plan Collabora chart upgrades around these windows, and confirm the chart version you run supports your cluster version.
What does a Business or Enterprise Collabora subscription add to either option?
Per the Collabora Online pricing page, the Business plan costs 3 euros per user per month for up to 99 users and includes 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. The subscription is a recurring cost that applies whether you run one server or a cluster, so it does not replace infrastructure spending. Compare it with the free CODE edition, which Collabora describes as not recommended for production.
Which Kubernetes security checks should we confirm before going live?
Confirm that Collabora pods run under the Pod Security Standards level your cluster enforces, and that the ingress setup keeps WOPISrc routing consistent across all pods. Kubernetes stores Secrets unencrypted in etcd by default, so confirm encryption at rest, least-privilege RBAC for list and watch access, and whether an external secret store fits your policy. Check how users authenticate to the cluster, since Kubernetes does not represent normal users as API objects. Your security team should verify these controls in your environment rather than rely on the chart defaults.
Upgrades, backups and skills for each option
This table compares what each deployment shape asks of your team over time: version upgrades, backups, monitoring, certificates and secrets, and skills. Read each row as a question to answer for your own environment before choosing. The main takeaway is that Kubernetes adds a control plane, and its upgrade and backup duties, on top of the Collabora Online duties that a single server also carries.
| Area | Single server or container | Kubernetes with the Helm chart |
|---|---|---|
| Version upgrades | Upgrade the Collabora Online image or package and the file platform together, then test document editing against your file platform's supported versions. | Kubernetes maintains only the three most recent minor releases, so plan cluster upgrades on that cycle. The version skew policy requires kube-apiserver to be upgraded first, one minor version at a time, before other control plane components and kubelets. |
| Chart and replica changes | Change the container version in one place and restart the service during a planned window. | Upgrade the Helm release and set replicaCount by hand, since horizontal pod autoscaling is disabled. Roll changes so that each document session still routes to the same pod. |
| Backup scope | Back up the document store of your file platform, the file platform database and the Collabora configuration files. | Back up the same application data, plus cluster state. Ask whether your team or a provider owns etcd snapshots and restore testing. |
| etcd backups | Not applicable when Collabora runs on a host you already manage without a cluster. | Only if your team runs its own control plane. Kubernetes documentation expects a backup plan for etcd data, using etcdctl snapshot save and etcdutl for restores. |
| Monitoring | Watch the container or service health, CPU and memory on the host, and the file platform's connection to Collabora. | Watch pod health, per-pod CPU and memory against the chart's requests and limits, and the ingress routing that keeps sessions on one pod. Confirm what your cluster monitoring stack already provides. |
| Certificates and TLS | Manage the certificate on the reverse proxy or host and renew it on your schedule. | Manage certificates at the ingress controller or in-namespace reverse proxy. Confirm how your cluster issues and renews them. |
| Secrets handling | Store the WOPI and admin credentials in the host's configuration with restricted file permissions. | Kubernetes Secrets are stored unencrypted in etcd by default. Configure encryption at rest, restrict list and watch access with least-privilege RBAC, or use an external store through the Secrets Store CSI Driver. |
| Skills needed | Container or package administration, reverse proxy setup, and familiarity with the file platform's WOPI settings. | Kubernetes administration, Helm, ingress configuration with session affinity on WOPISrc, and etcd operations if you run your own control plane. |
A decision path for choosing the deployment model
This sequence turns the single server versus Kubernetes question into a set of checks you run in your own environment, so the deployment you pick matches your file platform, your cluster and your team's concurrent editing load. Each step ends with a written result that feeds the next one.
Confirm the file platform and its WOPI setup
Start by recording which file sync platform will host the editor and how it reaches Collabora Online through WOPI. Collabora lists Nextcloud, ownCloud and Seafile among the WOPI integrations on its product page, but your platform version, its Office connector settings and the public URL it uses for the WOPI callback are facts you must confirm with your platform administrator. The output is a short written note with the platform version, the WOPI host URL and the owner of that configuration. Do not move on until the note names one owner.
Check for an existing production-grade cluster and its operator
Determine whether your organization already runs a Kubernetes cluster that operations staff support for production workloads, and who is on call for it. Kubernetes releases roughly three times a year and maintains only the three most recent minor versions, so ask which version your cluster runs and whether it is still inside that window. If no cluster is run by a team that will own Collabora alongside it, a single server or container next to the file platform is the simpler path to evaluate first. The output is a named cluster owner, a supported version and a yes or no answer on production readiness.
Confirm the ingress or proxy the cluster allows
The Collabora Online Helm chart documents HAProxy Ingress and NGINX ingress with hashing on the WOPISrc parameter, and an in-namespace nginx reverse proxy for clusters where an ingress controller cannot be installed. Ask your platform team whether they can install and configure one of these controllers, and whether the load balancer in front of the cluster preserves the WOPISrc parameter and keeps requests on one path. If none of these is permitted, the Kubernetes option needs a different routing design that you must confirm with the chart maintainers and your security team. The output is a confirmed routing component and a written statement that URL-based hashing reaches the pods.
Estimate concurrent editors from your own usage data
Pull real usage figures from your file platform, such as the number of users who open office documents in a typical busy hour and how many documents are edited at once, and do not rely on headcount alone. Collabora's pricing page sets per-user plans, but licensing does not tell you how many editing sessions a server must hold, so the sizing has to come from your own logs and your own test results. Ask the vendor to explain how sessions map to resources in their documentation. The output is a table of peak concurrent editing sessions and the document types involved.
Compare the per-pod resource needs with your capacity
Set the estimated concurrent sessions against the resources you can give Collabora. The Helm chart README recommends production requests of 4 CPUs and 6000Mi memory with limits of 8 CPUs and 8000Mi per pod, plus the --o:num_prespawn_children=4 option. Because autoscaling is disabled and replicaCount is set by hand, you must hold enough headroom for peak sessions across the pods you set. Confirm with your cluster owner that these figures fit the nodes, quotas and budget you already have. The output is a replica count and a node capacity plan that your team has signed off.
Decide the deployment model and record the trade-offs
With the earlier results in hand, choose between a single server or container and several pods on Kubernetes. Record why the choice fits your platform, your cluster ownership, your routing constraints and your peak editing load, and record what you would have to change if the answer shifted. Also note who will carry the ongoing work of upgrades and security patches for the chosen model, and confirm with Collabora whether your paid edition, if you buy one, changes support terms for that model. The output is a one-page decision record with a named owner and a review date you set yourself.
Pilot the chosen model with your own documents
Run a limited pilot with a small group of real editors on the chosen deployment. Test collaborative editing on the same document from several users, copy and paste between sessions, and the behavior after a pod restart or a rolling update. These are the failure points the Helm chart describes when routing is wrong, so test them directly and do not assume they work. Record which checks passed, which failed and what you changed. The output is a pilot report that either supports the decision or sends you back to step five to change the model.
How the license and paid edition change the operating decision
The license does not change with the deployment model. The Collabora Online server code is licensed under the Mozilla Public License 2.0, so a single container and a multi-pod Helm release carry the same license terms. What changes is the edition you run in production. Collabora describes CODE, its free rolling release published on average once a month, as suited to testing, home use or small teams and not recommended for production. The paid Collabora Online adds tested updates, security fixes and support. On Kubernetes, every pod pulls the same image, so an untested update reaches every replica at once. Decide the edition before the first replica is scheduled, not after an incident.
The subscription is priced per user, so the deployment shape does not set the license fee directly. 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. The subscription is a recurring cost that grows with headcount. The Kubernetes cost sits in the cluster you run or buy separately. Ask the vendor in writing whether the subscription covers every replica, including staging and test environments.
Before you sign, confirm three points in writing. First, whether the service level agreement and signed security updates apply to containers deployed from the Helm chart as well as to packages. Second, how often tested builds ship relative to your change windows. The 25.04 branch was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026, which shows how long a branch can be maintained. Third, which support tier covers faults caused by ingress hashing or session affinity, because a routing fault looks like a document fault to end users. Record the answers next to your planned replica count.
How DeployOpen scopes and delivers Collabora Online deployments
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Collabora Online on Kubernetes or on a single server. Each deployment starts from a written scope that sets out the topology, the file platform integration and the evidence the client needs before go-live.
How we scope
- Confirm which file sync platform will call Collabora Online through WOPI and which versions are in use.
- Decide with the client whether one server or a Kubernetes cluster fits their user count, availability target and team skills.
- Agree in writing the ingress controller, session affinity method, certificate approach and where the cluster will run.
How we build
- Install Collabora Online with the project's Helm chart or on a single host, configured to the client's chosen ingress.
- Configure WOPISrc-based load balancing for collaborative editing and copy and paste, then test it with multiple users on one document.
- Set per-pod resources and replica counts by documented method, with manual scaling and load tests run before handover.
How we hand over
- Deliver the written configuration, architecture diagram, runbooks for scaling, upgrades and restores, and the test results.
- Walk the client's platform and security teams through ingress behavior, failure modes and the steps for adding replicas.
- Document the evidence and controls that the client's compliance assessor will ask for, without claiming any certification.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope is agreed in writing and can cover patch rollouts, Kubernetes version changes and re-testing after updates.
- Ask any provider, including DeployOpen, to confirm which Collabora Online edition and support terms apply to your deployment.
