Collabora Online capacity for large collaborative sessions: what the reader is planning
Large Collabora Online sessions are limited by the single Collabora server or Kubernetes pod that holds the document being edited, not by the total number of users on the platform. Every editor on one document is served by the same backend process, so the capacity question is how many people can work on that one file at the same time, and how the rest of the platform behaves while they do. An IT lead supporting a town hall, a class or a workshop is therefore planning for one hot document rather than for the size of the user directory. This planning matters most when people write together in real time: live drafting of a policy or statement, shared meeting minutes that several people update during the session, or a joint slide deck that a room of presenters edits before going on stage. The same pattern appears in teaching, where a whole class edits one template, and in workshops where participants annotate a common spreadsheet. The vendor's documentation gives no published ceiling for the number of simultaneous editors on one document, so the reader has to establish that figure locally. Ask Collabora for any guidance it can give on per-document concurrency, then confirm it with a load test that uses your document types, your network path and your ingress.
Run the test with documents that match the real session, not a blank file. Include the largest spreadsheet, the heaviest presentation and the embedded images your users will paste, and watch CPU, memory and latency on the pod or server that owns the document while the editor count rises in steps. Also verify that the load balancer keeps every connection for that document on the same backend, because a session split across servers will fail in ways that look like editing bugs. Record the point where typing latency or save behavior becomes unacceptable, and treat that point as the limit for one document, with headroom left for the unexpected. The result should decide whether one large session needs a dedicated server, a larger pod or a split into several documents.
Five factors that shape a 20-editor meeting
Twenty people editing one document is less a server count question than a question of how five conditions interact: how many editors share the document, what the document contains, how the network carries live changes, how the host manages sessions, and how much headroom the server keeps. Vendor per-user figures are a starting point only, so measure each factor in your own environment before fixing the sizing for a town hall, classroom or workshop.
Editor count on one document
All editors of one document share a single Collabora Online process on one pod or server, so the number of simultaneous editors on that document drives load on that process, not the total user count of the platform. A 20-editor session is a concentrated case even when the platform serves thousands of users. Test with the real number of editors you expect, and ask whether the sessions will include viewers who join and leave, since those joins also cost work.
Document type and size
Short text documents place little strain on the server, while large spreadsheets with many formulas and presentations with heavy embedded media require more memory and CPU for every edit that every participant sees. Build a test set from documents your organization actually uses, including the largest workbook and the most image-heavy deck, and measure memory growth over the length of a session.
Network latency and tunnel timeouts
Live co-editing depends on WebSocket connections that stay open for the whole session. High latency on the path between clients and the load balancer, or idle timeouts set too low on the proxy, cause dropped connections and forced reconnects during a meeting. Check the timeout values on every hop, test from the locations where participants really sit, and confirm that reconnects restore the document state without losing edits.
WOPI host session behaviour
The host application decides how often sessions are created, how long access tokens last and how many requests reach the Collabora server when users open, refresh or switch documents. Nextcloud and other WOPI hosts differ here, so observe the request pattern during a rehearsal rather than assuming it. Confirm with the host's documentation and your own logs how session creation behaves when many users open the same file within a few minutes.
Headroom on the pod or server
A pod or server that runs near its limits during a rehearsal will fail under the real event, when nerves, late joiners and large files all arrive together. Measure CPU and memory use with the other workloads on the same node, and keep the margin you choose written down. The Helm chart README gives production resource requests and limits per pod, which is a reference point for planning, but your own measurements decide the margin.
Settings and sizing choices for town halls, classrooms and workshops
This table compares three session types, town halls, classrooms and workshops, against the settings and sizing options that shape them. Read each row as a choice you make before the session, with its fit and its trade-off. The main takeaway is that permission settings and the number of editors matter more than raw server size for most of these sessions.
| Option | Best fit | Trade-off | When to choose it |
|---|---|---|---|
| View-only access by group in Nextcloud Office | Town halls with many viewers and few editors | Viewers follow along but cannot change content, so presenters need a separate edit group | Choose when the audience only reads and a small named group drafts or presents |
| Edit access by group in Nextcloud Office | Classrooms and workshops with shared editing | Every editor adds concurrent load on the same document, so group size needs to match the server plan | Choose when students or participants must change the same file and the group is limited to those people |
| Dedicated Collabora Online server | Recurring large sessions or sessions with sensitive records | Higher fixed infrastructure and an operations owner, but load and maintenance stay separate from other users | Choose when sessions are scheduled, large, or involve regulated education or personal data |
| Shared CODE deployment | Small trials, home use or small teams | CODE is free and released about monthly as a rolling release, but Collabora does not recommend it for production | Choose only for testing or low-stakes sessions, and confirm its fit for your environment with Collabora |
| Fixed replica count on Kubernetes | Sessions that run at known times | Horizontal autoscaling is disabled because scaling breaks collaborative editing, so you must set replicas before the session | Choose when session times are predictable and you can raise the replica count ahead of each event |
| Resource requests and limits per pod | Large documents and many simultaneous editors | Higher requests reserve more capacity even when idle, which raises cluster cost | Use the Helm chart production figures as a reference point, then confirm sizing with a load test |
| WOPISrc-aware routing for one document | Any session where all editors share one file | Without it, editors on the same document can land on different pods and break co-editing | Always apply when more than one server or pod serves editors |
How to test a large session before the event
This sequence proves, on a single production-like server and before the event, that one document can hold the expected number of editors with acceptable CPU, memory and latency. It ends with recorded results that show whether the planned capacity holds or needs changing.
Define expected editors per document
The event owner and the platform team agree on the maximum number of people who will edit the same document at once, the document types they will use (text, spreadsheet or presentation), and the largest expected file sizes. Write these figures down as the test target. The step is done when the target is signed off by the event owner and the platform team, and every later check is measured against it. Ask the vendor or your partner to confirm how the expected load maps to your chosen resource settings before you move on.
Deploy one test server with production settings
The platform team deploys a single Collabora Online server using the same image or package version, TLS setup, reverse proxy, resource requests and limits, and WOPI host configuration planned for production. For Kubernetes, the Helm chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Do not test on a larger or smaller machine than the one you plan to run. The step is done when the server starts cleanly, reports healthy, and a single test document opens from the host application.
Configure WOPISrc routing for one pod
Configure the load balancer or ingress to route by the WOPISrc parameter, so every editor of the same document reaches the same pod. The Helm chart README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so keep the replica count fixed during the test. Confirm that requests for one document land on the same backend by checking the routing logs while two test accounts open the same file. The step is done when both sessions show the same backend, and a request for a second document does not disturb the first.
Restrict edit rights by group
In the host platform, set which groups can open the editor and which can edit rather than only view. The Nextcloud administration manual describes these group-level controls in Nextcloud Office. Create a test group for rehearsal participants, give most of them view access where the event design allows it, and give edit rights only to the intended editors. The step is done when a test account outside the edit group can open the document in view mode only, and a test account inside the group can edit it. Record the exact settings so the production configuration matches.
Rehearse with real document types
Run a rehearsal with the expected number of participants editing the same documents, using copies of the real files from the event rather than small sample documents. Include the spreadsheet and presentation types that will appear, and have participants perform typical actions such as typing, pasting between documents, inserting images and scrolling. Use a timed script so each rehearsal is repeatable. The step is done when all planned editors can join, edit and save without errors, and the coordinator logs any dropped sessions, failed saves or copy and paste failures for analysis.
Record CPU, memory and latency at each stage
During the rehearsal, the operations team records CPU use, memory use, and the response time seen by editors at fixed points: when the session starts, when all editors have joined, during sustained editing, and during a save. Store the figures with the test target from the first step. Compare each recorded value with the headroom you planned for the production pod. The step is done when every recorded value has been compared with the target and a written pass or fail result exists for each stage. If a stage fails, change the resource settings or the document design and repeat the rehearsal before the event.
Decide go or no-go for the event
The event owner and platform team review the recorded results against the test target and agree on a go or no-go decision. Confirm the decision in writing, along with the final resource settings, routing rules, group permissions and the number of editors each document will support. Keep the test logs so the same check can be repeated after upgrades or changes to the host platform. The step is done when the written decision is filed and the production configuration matches the tested configuration exactly.
Security and operational risks during large sessions
A large session concentrates load, shared edit rights and external access into one short window. The cards below cover the controls that keep a town hall, classroom or workshop from becoming an incident, and the checks to run before and during the event.
Restrict WOPI requests by source address
Nextcloud's administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers. For a large session this stops any other host from posing as the document host while the event is running. Check that the allow list matches the addresses your servers use after a load balancer or NAT hop, because a mismatch fails at the moment of highest demand. Confirm the list in a staging run with the same number of editors you expect.
Use HTTPS on both sides
The Nextcloud manual recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. A mixed-protocol setup can produce connection errors that look like capacity failures, and editors will retry and add load. Verify the public URL, the internal URL and the certificate chain before the event, and confirm that WebSocket traffic through your reverse proxy also uses TLS.
Limit edit rights by group
In Nextcloud Office, administrators can limit which groups can use the editor and which groups can edit rather than only view. For a town hall or workshop, give most attendees view access and grant edit rights to a named group of presenters or note-takers. This reduces accidental mass edits to a shared document and keeps the number of concurrent editors closer to the number you sized for. Set the group membership before the session, not during it.
Stay on supported point releases
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 and updated package signing keys for RPM and DEB users. Before a large session, confirm that every server runs a current point release on its branch and that the signing keys in your package repositories match the current ones. Do not change versions during the week of the event.
Monitor during the event
Watch active WebSocket connections, server memory and CPU per instance, and WOPI error rates on the load balancer and the Nextcloud log. A rising error rate on one server often points to a document pinned to an overloaded pod rather than a general shortage. Agree in advance who can restart a server, who can change a load balancer weight and how attendees are told to reload. Record the thresholds you chose so the post-event review compares actual numbers with your sizing assumptions.
Questions buyers ask about large Collabora Online sessions
How many editors can one Collabora Online document support?
Collabora does not publish a fixed ceiling for editors on one document, so the honest answer comes from a test on your hardware, your document types and your network. Load depends on how many people type, scroll and paste at once, how large the spreadsheets and presentations are, and whether the session uses a single server or several. Ask for a test plan that simulates your real meeting pattern, including a ramp to your target count and a record of CPU, memory and latency at each step. Treat any number you read elsewhere as a starting point to verify, not a promise.
What drives the cost and effort of a large session deployment?
Most of the cost is skilled engineering time, and it scales with the number of unknowns you need to settle. The main components are:
- A test environment that matches production, including the proxy and WOPI host.
- Sizing and load testing against your document samples.
- Routing configuration so every request for a document reaches the same server.
- Rehearsal of the event itself, including failover and a rollback plan.
One-time work covers design, testing and configuration. Recurring work covers patching, monitoring and re-testing when you change versions or hardware. Ask any provider to split the quote along these lines so you can see what you pay for once and what continues.
What does the customer need to provide for a large session project?
The work moves faster when you prepare access and material before the first call. Typically you need:
- Access to the infrastructure where Collabora Online will run, such as cloud accounts, virtual machines, Kubernetes clusters or an air-gapped network.
- Representative document samples, including large spreadsheets and presentations with images, fonts and macros your staff actually use.
- The event schedule, expected peak attendance, and the names of the people who approve changes during the event.
- Your WOPI host details, such as the Nextcloud instance and its network path to Collabora.
If any of these are missing, the schedule and scope should reflect that gap in writing.
Can our own team run large sessions without an outside partner?
Yes, if your team has experience with reverse proxies, WOPI routing and load testing, and if it can staff the event. Many organizations keep operation in-house and bring in outside help only for the first design, the load test or a specific gap. The questions to answer honestly are whether anyone already knows how the WOPISrc parameter is used for routing, whether you have a repeatable load test, and whether you can rehearse a failover before a town hall. A fixed-scope engagement can cover one of these pieces without taking over the whole platform.
What does Collabora Online licensing cost for a large organization?
Licensing depends on your user count and the support you need. According to Collabora's 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 free CODE edition is not recommended for production by Collabora, so it is unsuitable for a meeting-critical deployment. Confirm the current figures on the pricing page before budgeting, because the subscription is separate from any services fee for design, testing or rehearsal.
Why does the load balancer need to route by document for large sessions?
Collaborative editing keeps the state of a document in one server process, so every editor of that document must reach the same server. Collabora's Helm chart documentation says load balancers must route by the WOPISrc parameter for this reason, and it disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste. In practice, a session that spreads across pods will show editors out of sync or lose paste operations. Your engineers should confirm this behavior in a test before the event, not discover it during it.
What breaks first when a large session goes wrong?
The usual first failures are routing errors, memory pressure on a single server and network timeouts on long-lived WebSocket connections. Routing errors appear when a proxy does not balance by document, so editors land on different servers. Memory pressure shows up when many large spreadsheets are open together. Timeouts drop connections when the proxy closes idle tunnels too early. Ask for monitoring that tracks these three areas during the rehearsal, and for a documented rollback path that does not depend on one person.
Limits to confirm in your environment
No editor ceiling per document was supplied for Collabora Online, so the figures that matter for a town hall, classroom or workshop must come from your own tests. The cards below cover the variables that change the result: the document, the host, the routing, the resource limits and the support terms behind the plan you choose.
Maximum editors per document
No supplied figure gives a ceiling for simultaneous editors on one document, so do not plan around a number from a vendor page or a forum post. Build a test with your real session size, for example a group that matches your largest expected meeting, and record where latency, cursor updates or save conflicts become unacceptable. Run the test on the same server class you plan to deploy, and repeat it at peak concurrency across the whole event, not only at the start.
Behaviour under your WOPI host
Collabora Online runs inside a host such as Nextcloud, and the host decides how users open, authenticate and reconnect. Confirm how your host requests and refreshes sessions when attendees join late, switch networks or reload the page. Check that the host's WOPI settings, including the allow list it sends to Collabora, match the server you test against, so that a test does not pass on a configuration you will not run in production.
WOPISrc routing in your load balancer
Every user editing one document must reach the same Collabora pod or server. Confirm that your load balancer, whether Nginx, HAProxy or an OpenShift Router, can route by the WOPISrc parameter, and test it with several clients opening the same document at once. Without this routing, editors can land on different servers, and the session breaks in ways that look like random sync errors.
Effect of your document formats
Large spreadsheets, presentations with embedded media and documents with many tracked changes consume more memory and CPU per editor than plain text. Build a set of representative files from your own archive, covering the Microsoft and OpenDocument formats you store, and measure memory growth as editors join. Include the largest files you expect to see, since a single heavy document can set the resource needs for the whole session.
Resource limits per pod
The Helm chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. These are the chart's recommendations, not a measured capacity for your workload. Confirm that your nodes can honor the requests, that memory limits leave room for peaks, and that horizontal pod autoscaling stays disabled so replica counts are set by you.
Support terms for your plan
Community editions such as CODE are described by Collabora as suited to testing, home use or small teams, and not recommended for production. For a production deployment, confirm in writing what the chosen plan covers, including the response commitments, long term support, signed security updates and the Enterprise integration and customization services. Ask which versions are covered and how long each branch receives point releases, so the sizing you validate remains supported.
How DeployOpen scopes and delivers large-session capacity work
DeployOpen plans, implements, tests and documents self-hosted open-source platforms inside your own infrastructure, including Collabora Online capacity for large collaborative sessions. We start from the session sizes, document types and hosting platform you actually run, then agree the work in writing before any build begins.
How we scope
- We record expected concurrent editors per document, session length and the document types people will open.
- The written scope names the hosting model, WOPI host, load balancer and the number of Collabora Online servers covered.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We confirm which per-user figures and release branch the sizing will rely on, so the quote follows from the stated assumptions.
How we build
- We configure WOPISrc-aware routing so every session for one document reaches the same Collabora Online server.
- We set per-pod or per-server CPU and memory limits and document the reasoning behind each value.
- We test load with simulated meeting-style sessions and record memory, latency and failure behavior at the target size.
- We tune WOPI allow lists, TLS and proxy timeouts alongside capacity settings so the sizing holds under real traffic.
How we hand over
- You receive the sizing worksheet, configuration files and load-test results with the assumptions behind them.
- Runbooks cover adding editors, restarting servers without interrupting sessions and reading capacity warnings.
- We document the upgrade path between Collabora Online branches so your team can plan future releases.
- Knowledge transfer sessions walk your engineers through the design so they can maintain it after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- A retainer can cover re-testing capacity after new Collabora Online releases or changes to your user numbers.
- Ask any provider which monitoring signals they will watch for session growth and who responds when limits are reached.
- Confirm response expectations and escalation paths in the written agreement before the retainer starts.
