When one Collabora Online server is no longer enough without Kubernetes
When a single Collabora Online server saturates, the answer without Kubernetes is several servers behind a load balancer that routes by the WOPISrc parameter, so every user editing a given document reaches the same Collabora server. Your Nextcloud or other WOPI host team can run a fixed set of virtual machines or bare-metal hosts for this, as long as the front end keeps document sessions pinned. The signs that you have reached this point are sustained CPU or memory pressure on the server during normal working hours, slower document loads at peak times, and users reporting that editing sessions feel sluggish even though the host itself has capacity to spare.
The official Collabora Online Helm chart documentation states that load balancers must route by the WOPISrc parameter so all users editing one document reach the same pod, and it also says horizontal autoscaling is disabled because scaling breaks collaborative editing and copy and paste. The same logic applies to VMs: if two users editing one document land on different servers, they do not share a session, and edits, comments and clipboard operations can fail in confusing ways. Adding servers therefore increases total capacity only if the routing is document-aware. Before you add a second server, confirm the exact routing approach with Collabora's documentation for your version, and check how your WOPI host sends the WOPISrc value, because a load balancer cannot route on a parameter that the host does not consistently provide.
A fixed set of VMs is the right choice when your user base grows gradually, your team already runs HAProxy or Nginx and manages VM images, and you want explicit control over how many servers run at any time. It is less suited to workloads with large swings in demand, where you will need to plan capacity for peak hours and accept idle servers off-peak, or to organizations that need automated replacement of failed nodes. Decide early whether you will adjust the server count by hand and who owns that change, and confirm with your WOPI host vendor which Collabora server URLs and IP addresses must be allowed in its configuration, since the Nextcloud administration manual recommends restricting WOPI requests to known Collabora server addresses.
Choosing a load balancer and server layout for a VM pool
This table compares HAProxy and Nginx for WOPISrc-based balancing and two common server layouts for a VM pool. Read each row against your team's skills and your change process, since the right choice depends on who will maintain the balancer and how much failover you need. The main takeaway is that the balancer choice matters less than confirming that it routes every request for a document to the same server.
| Option | When it fits | What the operator must maintain | Confirm before committing |
|---|---|---|---|
| HAProxy with url_param WOPISrc | Teams that want a dedicated balancer with explicit stick-table and health check behavior for WOPI traffic | Backend list, health check definitions, tunnel timeouts for WebSocket sessions, and config reloads during rolling restarts | The exact url_param and stick settings in the current Collabora deployment guide for your version |
| Nginx with hash on WOPISrc | Teams that already run Nginx as their reverse proxy and want one component at the edge | Upstream block with a consistent hash on the WOPISrc argument, proxy timeouts for WebSockets, and open source versus Plus feature choices | Whether your Nginx build supports the hashing directive you plan to use and how it behaves when a backend is removed |
| Helm README ingress options (Nginx, HAProxy, OpenShift Router) | Reference point only, since this topic covers VMs rather than Kubernetes | Nothing on VMs directly, but the README shows the routing requirement that any balancer must meet | That the README's WOPISrc routing requirement is restated in the version you deploy |
| Single balancer in front of several VMs | Small pools where a short balancer outage is acceptable and one configuration is easiest to audit | One balancer host with patching, monitoring and a documented restore procedure, plus a plan for the balancer being a single point of failure | Your recovery time expectations and whether a stand-by balancer can be built later without re-routing active sessions |
| Pair of balancers with virtual IP failover | Pools that must stay reachable during a balancer host failure or planned maintenance | Two balancer configs kept identical, a failover tool such as keepalived or equivalent, and failover tests after every change | Whether your network allows the virtual IP to move, and how existing sessions behave when routing changes on failover |
| Balancer placement on the same host as a Collabora server | Only for lab or single-host tests, because load and failure domains overlap | Resource contention management and separate monitoring for each role | Whether the vendor documentation supports this layout at all for your target user count |
| Health checks on the Collabora endpoint | Every production pool, so failed servers are removed from new routing decisions | Check path, interval and failure thresholds tuned to the server's startup time | The health endpoint and expected response for your Collabora version |
| Rolling restarts with drained backends | Pools that receive config or version updates without a maintenance window | A procedure to stop new routing to one server, wait for active documents to close, then restart | How long active editing sessions can remain open before a restart forces them to end |
Setting up a Collabora Online server pool step by step
This sequence turns a single Collabora Online server into a pool of identical servers behind a WOPISrc-aware balancer, so every session for one document reaches the same server and the WOPI host only ever sees one entry point.
Provision identical Collabora Online servers
Your infrastructure team builds two or more servers with the same operating system release, the same CPU and memory allocation, the same fonts and the same network path to your Nextcloud or other WOPI host. Install Collabora Online on each one from its system packages or from the collabora/code Docker image, using the same version on every server. Confirm the choice of package or container with Collabora's deployment documentation before you start. The step is done when every server reports the same Collabora Online version and each one starts its service without errors in its logs.
Configure listen and host settings on each server
On each server, set the address and port the Collabora Online service listens on, and set the host name that clients and the WOPI host will use to reach it. Configure the server-side allow list of WOPI hosts so that only your Nextcloud or other WOPI host can request documents. Keep the settings identical across servers except for the host name, which must match each server's own address. Confirm the exact configuration keys for your package or image version in the official documentation. The step is done when each server answers its discovery endpoint on its own address with the expected host name and does not accept requests from unlisted hosts.
Place the balancer in front of the pool
Deploy HAProxy or Nginx as the single entry point for the pool. Route WebSocket and HTTPS traffic for the Collabora Online endpoints to the backend servers, and set generous tunnel timeouts so long editing sessions are not cut. Keep the balancer on a host that your team can monitor and restart independently of the Collabora servers. Confirm that your chosen balancer supports the WebSocket upgrade behavior your version of Collabora Online needs. The step is done when a request sent to the balancer reaches a backend server and returns the expected discovery response.
Hash backends on the WOPISrc parameter
Configure the balancer to choose a backend by hashing the WOPISrc URL parameter, which identifies the document. In HAProxy this is typically a backend using
balance url_param WOPISrcwith a consistent hash, and in Nginx it is an upstream using a hash directive keyed on the same parameter. Every user who opens the same document then lands on the same server, which is what keeps collaborative editing and copy and paste working. Confirm the exact directive for your balancer version. The step is done when two separate requests carrying the same WOPISrc value are logged against the same backend server.Add health checks for each server
Define a health check for every backend that calls the Collabora Online discovery or health endpoint on that server, using the same host name the balancer uses. Set the check interval and failure threshold with your operations team so that a stopped or unresponsive server is removed from rotation. Document what happens to documents already open on a failed server, because the hash will move new sessions to another server while existing sessions must reconnect. The step is done when stopping one server causes the balancer to mark it down, and starting it again returns it to rotation.
Point the WOPI host at the balancer over HTTPS
In the WOPI host, such as the Nextcloud Office settings, set the Collabora Online server URL to the balancer address and use HTTPS, using the same protocol as the Nextcloud installation. Do not point the WOPI host at individual Collabora servers, because that bypasses the WOPISrc routing. Confirm that certificates on the balancer are trusted by the WOPI host. The step is done when the WOPI host opens the editor from its own interface and the browser shows the balancer host name, not a backend address.
Restrict WOPI requests to known addresses
Following the Nextcloud administration manual, limit inbound WOPI requests to the Collabora Online servers by allowing only the addresses of your balancer and backend servers at the firewall or in the WOPI host's allow settings. Also restrict which groups can use the editor and which can edit, as the same manual describes. Ask your security team to confirm the address list against the actual egress addresses of your environment. The step is done when a request from an address outside the list is refused and a normal editing session from an allowed user still succeeds.
Verify a document lands on one server
Open one document through the balancer from two different user accounts and confirm both sessions reach the same backend, using the balancer logs or the Collabora Online logs on each server. Then open a second document and confirm it may land on a different server. Test that edits made by one user appear for the other. Record the backend assignment for the test documents so that future changes can be checked against the same baseline. The step is done when the same document consistently reaches one server and co-editing works across two sessions.
Planning capacity per server in a multi-VM pool
Size each VM from the server's own load, not from a global count of users. A pool of identical VMs is only as large as its busiest server, and in Collabora Online the busiest server is the one holding the documents that are being edited hardest. The Helm chart README gives production reference figures per pod of 4 CPU cores and 6000 MiB of memory as requests, with limits of 8 cores and 8000 MiB. Treat these as a reference point for what a production-grade Collabora Online container has been configured to expect, not as a sizing rule for a VM. Your per-user and per-document figures must come from the sizing topic and be confirmed against your own load tests with realistic documents, because a VM that runs fine with small text files can struggle with large spreadsheets and presentations.
Documents are pinned to one server. Because every request for a document must reach the same Collabora Online server through WOPISrc routing, all editors of a file load onto one backend, and the load balancer cannot spread that work. One heavy workbook with many formulas, or a large presentation opened by a meeting-sized group, can therefore saturate a single VM while the others sit idle. Measure per-server CPU, memory and session counts individually, and record the largest documents your users open. Ask whether your pool needs a hot-spot plan, such as a warning for very large files or a separate pool for heavy spreadsheets, and confirm how the host application handles a server that is removed from rotation while documents are open.
Add servers in N-plus-headroom terms. Work out how many VMs your measured peak needs (N), then add at least one more so that a single VM failure or a rolling restart does not push the remaining servers past their tested limits. Keep the headroom high enough that a server can be drained and restarted during business hours, and check whether you can afford to run N+1 at peak once the drained server is out of rotation. Confirm the exact headroom target with your own tests and your operations team, and update it when you upgrade Collabora Online or change document mix, since both alter per-server load.
Which health checks and failure modes to plan for
A multi-server Collabora Online setup has no orchestrator to replace a failed pod for you, so the balancer, the sticky routing and the WOPI allow list all have to fail safely. The cards below cover what breaks in each case and what to verify before users depend on the setup.
Health checks on each server
The balancer needs a reliable signal that each Collabora server can accept new sessions. Configure a health check against each server's own endpoint, not only the load balancer's listener, so a server that is up at the TCP level but failing to serve documents is taken out of rotation. Test the check by stopping the service on one node and confirming that new sessions skip it. Confirm the exact endpoint path and expected response for your Collabora Online version in the vendor documentation before you write the check.
Balancer failover
If the load balancer itself is a single instance, it becomes the one point of failure for every document session. Decide whether you will run a second balancer with a floating address or rely on a managed virtual IP, and document how traffic moves between them. Verify failover by moving the active balancer while a test document is open and checking whether the editing session survives or must reload. Confirm how your chosen balancer handles connection state during a switch.
Server loss mid-session
When a Collabora server stops while users are editing a document on it, those WebSocket connections end and unsaved changes are at risk. Users typically see a connection error and must reopen the file, so the real exposure is lost edits rather than downtime. Test this deliberately with a live editing session, then check how the host application (for example, Nextcloud) reports the failure and whether users are told to save before reloading. Set expectations with users in writing before rollout.
Stale sticky mappings after removal
WOPISrc-based routing pins every session for one document to one server. When you remove or replace a server, existing mappings may still point at the old address until they expire or are cleared, so requests for those documents fail or land on the wrong node. Before decommissioning a server, drain it, confirm no active sessions remain, and then update the balancer configuration and reload it. After the change, open a document that was previously on the removed node and confirm it routes correctly.
WebSocket tunnel timeouts on idle sessions
Collabora editing runs over long-lived WebSocket connections, and balancers or proxies with short idle timeouts will close them while a user is reading or thinking. The symptom is a session that drops after a quiet period and reconnects with a warning, which users often report as instability. Review the tunnel and idle timeout settings on every proxy hop, including the host application's reverse proxy, and test with a document left idle longer than your standard session. Confirm the required values with Collabora's guidance for your release rather than copying a figure from another setup.
WOPI allow lists after an IP change
The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers. If a server is re-addressed, replaced or placed behind a new NAT or proxy, the host will reject its requests, and users will see the editor fail to load with no obvious server error. After any network change, confirm the outbound address that the host sees from each Collabora node, update the allow list on the host, and test opening a file from every server. Keep the allow list in your change records so the update is repeatable.
Rolling restarts and patching without interrupting active editors
This sequence takes one Collabora Online server out of rotation, lets its open sessions finish or moves them on a planned window, applies a signed update, and returns the server to the pool only after it passes health checks. Run one server at a time so the rest of the fleet keeps serving documents.
Confirm the release and signing keys to apply
The platform engineer checks Collabora's release notes and security advisories for the target point release, such as the 25.04 branch notes, and records any CVE it fixes. Read the same notes for package signing key updates, because RPM and DEB repositories can change keys between point releases. Confirm the signed package source and key fingerprint with Collabora before the change window opens. Done when the change record lists the target version, the advisories it addresses, and the key status for each server package type.
Stop routing new documents to the target server
The load balancer operator marks the target server as draining or disabled so that no new WOPISrc requests reach it, while requests for documents already open on that server continue to reach it. Confirm the drain behavior in your balancer, since HAProxy and Nginx handle disabled servers, sticky table entries and existing WebSocket tunnels differently. Check that the other servers accept new sessions for the same hosts. Done when the balancer status shows the server as draining and new document requests land only on the remaining servers.
Let active sessions end or schedule a window
The operator watches open editing sessions on the draining server through the balancer's connection view and the Collabora Online logs, and waits for them to close as users finish. If sessions remain open past the planned window, the team agrees with the document owners on a maintenance time and notifies affected users, because restarting the server will disconnect them and unsaved changes depend on the host's save behavior. Confirm how your WOPI host handles a dropped session before relying on it. Done when no active editing sessions remain on the server or the agreed window has been announced.
Apply the signed update and restart the service
The administrator installs the signed package from the verified repository using the system package manager, then restarts the Collabora Online service on that one server. Review the package changelog for configuration changes before restarting, and keep a copy of the prior configuration so it can be restored. Do not move on to a second server until this one is healthy. Done when the installed version matches the target release and the service process starts without errors in the system journal.
Verify health before returning the server
The operator checks the Collabora Online service status, the discovery endpoint served by the server, and the WOPI-facing health check your balancer uses. The team opens a test document from the WOPI host through this server, edits it, and confirms that the save reaches the host, using a non-production document where possible. Confirm fonts and document conversion still work for the formats you support. Done when the discovery response, a test edit, and a test save all succeed.
Return the server to the pool
The load balancer operator re-enables the server so it accepts new document sessions again, and checks that its traffic share returns to the level it had before the change. Watch error rates and connection logs on the rest of the fleet for a short period after the change to catch any cross-server effect. Confirm the drain and enable commands for your balancer in its own documentation before the first live change. Done when the balancer lists the server as active and error rates match the pre-change baseline.
Repeat for each server and record the result
The team runs the same sequence for the next server, one at a time, and does not start a new server until the previous one has passed health checks and returned to the pool. At the end, the change record lists each server, its installed version, the advisories it addresses, the key status, and any sessions that were interrupted. Keep this record with your Collabora Online inventory so the next patch cycle starts from a known state. Done when every server reports the same target version and the record is filed.
Securing the pool: allow lists, TLS and patch discipline
A pool of Collabora Online servers widens the attack surface in ways a single server does not: every VM is a WOPI endpoint, and every VM needs patches. The controls below connect the Nextcloud side of the integration, the balancer in front of the pool, and the release process that keeps each server current.
Restrict WOPI requests to Collabora addresses
The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers. In a pool, that list must cover every VM that can answer WOPI traffic, including the balancer's source addresses if requests reach Nextcloud through it. Before go-live, confirm the list matches the inventory, and remove addresses of servers that have been retired or rebuilt under a new IP. Review the list again after each scaling change.
Match the protocol on the Collabora URL
The Nextcloud manual recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Mixed schemes cause browsers to block content and make session and cookie behavior harder to reason about. Terminate TLS on the balancer with certificates that cover the public Collabora hostname, and confirm that the Nextcloud configuration uses that same hostname and scheme. Check the certificate chain from a machine outside your network, not only from inside it.
Keep backend Collabora ports off the network
Each Collabora server should accept connections only from the balancer and from the administrators who manage it. Bind the Collabora listener to the internal interface where the platform allows it, and firewall the port on each VM so that clients cannot reach a single server directly. Direct access bypasses WOPISrc routing, which breaks shared editing for documents that are open on a different server. Test this by attempting a direct connection to each backend from a client subnet.
Limit editing groups in Nextcloud Office
Nextcloud Office lets administrators limit which groups can use the editor and which groups can edit rather than only view. Use these settings to match the document policy: for example, let a read-only group open files while restricting edit rights to the teams that need them. Scope is an access control question, not a server hardening step, so record the group list with the owner of the Nextcloud sharing policy and review it when group membership changes.
Track Collabora security advisories
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. Subscribe to Collabora's release notes, map each advisory to the branch and point release you run, and schedule patching against the fix version rather than the next feature release. Keep a record of when each VM received the fix so an auditor or incident responder can see the exposure window.
Verify package signing keys on each VM
The 25.04 release notes record that package signing keys were updated for RPM and DEB users. Each VM installed from packages needs the current key before the next update, and a key change should be treated as an event to verify, not a routine prompt to accept. Confirm the key fingerprint against Collabora's published guidance through a channel you trust, then check it on every server rather than once per image. Record the key version in the build inventory so rebuilt VMs are checked too.
Questions teams ask before running a Collabora Online pool themselves
Does running several Collabora Online servers require Kubernetes?
No. The Collabora Online documentation covers installing and running the server from Docker images and system packages on virtual machines and bare-metal hosts, and the COOL Controller is offered for large Kubernetes deployments. A pool of VMs behind a load balancer is a supported shape, provided every request for a given document reaches the same server. Teams already running Kubernetes can still choose a VM pool if their platform team prefers that model, but the decision should rest on operating capacity, not on a belief that Kubernetes is required.
What drives the cost of running a Collabora Online pool?
Cost has five components: the servers and their compute, the load balancer, monitoring, the staff time for patching and rolling restarts, and the subscription. The server and balancer costs are one-time setup plus recurring infrastructure. Patching is recurring labor. For the subscription, Collabora's 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. Larger user counts fall under the Enterprise plan, which Collabora quotes individually. The free CODE edition is described as not recommended for production, so ask any partner to price the production path explicitly.
How long does it take to build a multi-server Collabora Online pool?
The duration depends on the scope and the environment, so no fixed figure applies. The main variables are how many servers and which load balancer you run, whether TLS and proxy settings already exist, how many WOPI hosts connect, how much integration testing with your document set is required, and how quickly access and change approvals are granted. Ask for a written plan that lists each phase, the environment assumptions behind it, the client inputs each phase needs, and the acceptance tests that close it. A plan without those items cannot be compared with another quote.
What does the client need to provide for the build?
Expect to provide access to the virtual machines or hosts, network rules between the WOPI hosts, load balancer and Collabora servers, and the DNS names and certificates for the Collabora server URL. On the WOPI side, you will need the host's administrator access so the allow list of Collabora server addresses can be set, and the protocol and URL must match the host's own. You should also supply a test document set that reflects your real files, including large spreadsheets and presentations, plus named owners for change approval and out-of-hours contact.
Can our in-house team run a Collabora Online pool without an outside partner?
Yes, if the team has Linux administration, reverse proxy and TLS experience, and time to build a runbook and test it. The work that most often gets skipped is load testing with realistic concurrent editing and a documented procedure for rolling restarts that keeps active sessions on their servers. A capable in-house team should write the runbook for configuration, balancing, health checks, patching and capacity review, then load test the pool before users depend on it. A partner can supply the same artifacts as a fixed-scope deliverable if the team lacks capacity.
What goes wrong most often in a pool without document-aware routing?
Without routing by the WOPISrc parameter, users editing the same document can land on different servers, which breaks collaborative editing and copy and paste. The official Helm chart documentation states that load balancers must route by WOPISrc so that all users editing one document reach the same pod, and the same principle applies to VM pools. Other frequent problems are WebSocket connections timing out at the balancer, health checks that report a server as healthy while it is overloaded, and restarts that drop open sessions. Confirm each of these in your own test environment before go-live.
How do we keep a Collabora Online pool secure and patched?
Restrict WOPI requests to the addresses of your Collabora servers, as the Nextcloud administration manual recommends, and use HTTPS for the server URL on the same protocol as your host. Collabora publishes security advisories for Collabora Online, and the 25.04 release notes record a fix released on January 29, 2026 for CVE-2026-23623, along with updated package signing keys. Plan a recurring patch window for every server in the pool, verify the signing keys during package updates, and subscribe to advisories so each release is assessed against your deployment.
What a fixed-scope pool engagement covers
A fixed-scope engagement for a pool of Collabora Online servers usually delivers the design and the working system together, so the client receives something they can operate without us. The first deliverable is an architecture and sizing note that records the server count, the CPU and memory allotted to each server, the balancer model, and the assumptions behind them. The second is a configured balancer and configured Collabora Online servers, with the WOPISrc-aware routing rule in place so every request for one document reaches the same server. Health checks, the WOPI allow list on each server, and the TLS and proxy settings that match the Nextcloud or other WOPI host configuration are delivered with that build, so the routing and the security posture are verified in the same pass.
The operational deliverables are the parts that decide whether the pool stays healthy after handover. A runbook covers rolling restarts, draining a server before it is taken out of rotation, and the patch cadence for Collabora Online point releases and security fixes, so an operator can follow it without the original builders. A handover test then runs the planned failure and maintenance cases end to end, such as restarting one server during open sessions and confirming that editors reconnect to the same document. Ask the partner to name the exact test cases in the written scope before signing.
Scope, deliverables and timelines are agreed in writing before work starts, and the written scope should list which items are included, which are excluded (for example, the WOPI host itself, identity, or client-side testing), and who performs each acceptance check. Confirm the supported Collabora Online branch and the balancer software version against the current release notes before scoping. Pricing is not estimated here. A quote follows from the written scope, and the main cost drivers are the number of servers, the number of environments, and the number of distinct WOPI hosts that must be integrated.
How DeployOpen scopes and supports a Collabora Online server pool
DeployOpen plans, builds, documents and supports Collabora Online server pools inside your own infrastructure, whether that is cloud accounts, data centers or air-gapped networks. Each engagement starts from a written scope that names the servers, the WOPI hosts, the load balancer and the operating model before any configuration begins.
How we scope
- We agree the number of Collabora servers, the WOPI hosts that will call them, and the expected user population in writing.
- The written scope names the load balancer, health check method, TLS termination point and the WOPISrc routing rule to be delivered.
- We confirm which Collabora Online branch and release channel fits your support needs before any server is provisioned.
How we build
- We install identical Collabora Online servers from your chosen package or Docker source, with configuration kept under version control.
- We configure WOPISrc-aware balancing and tunnel timeouts on your Nginx or HAProxy tier, then test editing sessions across server failures.
- We verify restricted WOPI host addresses and TLS settings on each server against the Nextcloud or other host configuration you provide.
How we hand over
- You receive runbooks covering rolling restarts, drain steps for a single server, and how to add or remove a server from the pool.
- Capacity planning notes show the per-server sizing assumptions, so your team can recalculate when user numbers change.
- Handover includes a test record of routing, health checks and failover behavior, along with the documented rollback procedure.
How we support
- Engagements are fixed-scope, and changes to the server count or routing rules are handled through a written change to that scope.
- Ongoing support, upgrades and continuous testing are available as a retainer, which covers patching when Collabora publishes new point releases.
- Ask us to confirm which support tier from Collabora your pool requires, since vendor subscriptions are bought separately from DeployOpen services.
