Why scaling self-hosted document editing for thousands of users is a different problem
Scaling browser editing for thousands of staff depends on three things: document-level session routing, per-pod sizing, and whether the edition you buy is allowed to cluster. Web-app replacements often assume that adding servers adds capacity in the same way it does for a stateless web tier. Collaborative editors do not work that way. Every editor of one document has to land on the same editing process, so the load balancer, not the autoscaler, decides how the system spreads. Before you size anything, confirm how your chosen platform keeps those sessions together and what it costs to run that design at your user count.
The two leading options handle this differently. Collabora Online's Helm chart turns off horizontal pod autoscaling because scaling breaks collaborative editing, so you set replica counts by hand and configure the ingress to route by the WOPISrc parameter. The chart's README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB, which means capacity planning is a capital and scheduling exercise rather than an automatic one. ONLYOFFICE takes a different path: its Enterprise Edition lists scaling for thousands of users as a paid feature, and its Community Edition configuration is file-based. Confirm with the vendor which tier your user count requires before you commit to a topology.
The right design depends on the rest of the environment: your file platform, whether the ingress is Nginx, HAProxy or OpenShift Router, how many documents are open at peak, and whether you need an AI assistant or a private network with no internet access. Ask for a load test on your own document mix, your own templates and your own routing rules, and ask who owns the manual replica runbook after go-live. Those answers shape the topology far more than the product name does.
What a large deployment must satisfy before sizing pods
This table lists the requirements a deployment for thousands of users must meet before anyone sets replica counts or pod resources. Read each row as a constraint first, then as the design decision it forces. The main takeaway is that routing, edition choice and audit evidence shape the architecture before any capacity numbers are chosen.
| Requirement | Regulation or constraint | What it means for the build |
|---|---|---|
| Concurrent editors per document | Collabora Helm chart README: scaling breaks collaborative editing and copy and paste | Count editors per document and per server separately. Replica counts are set by hand, so plan peak headroom and confirm the expected peak with the vendor and your own usage data. |
| Routing every editor of one document to one pod | Collabora Helm chart README: load balancers must route by the WOPISrc parameter | Confirm your ingress (Nginx, HAProxy or OpenShift Router are listed) can hash on WOPISrc. Test with two browsers on one document before go-live. |
| Edition and support for 100 or more users | Collabora pricing page: Business plan covers up to 99 users; Enterprise plan applies from 100 users. ONLYOFFICE lists scaling for thousands of users as an Enterprise Edition feature | Free community builds are not sized for production at this scale. Ask for written support terms, signed security updates and the edition that covers your exact user count before choosing pod sizes. |
| Editing traffic kept inside your boundary | Collabora and ONLYOFFICE both offer optional AI features and external integrations; the Collabora 26.04 AI assistant is off by default | Document servers, WOPI endpoints and storage stay in your network. Disable or restrict any external AI or telemetry, and document each outbound destination for your reviewers. |
| Audit records of document access containing ePHI | 45 CFR 164.312(b): audit controls that record and examine activity in systems containing ePHI | Log access events from the file platform and the WOPI layer into a central store. Confirm which document servers emit usable logs before the load test, since logs must exist at peak. |
| Encrypted transmission of editing sessions | 45 CFR 164.312(e)(1): guard against unauthorized access to ePHI transmitted over a network | Terminate TLS at the ingress, encrypt traffic between the file platform, WOPI host and document server, and restrict WOPI access to known hosts. |
| Preservation of business records | SEC Rule 17a-4(b)(4): preserve originals and copies of business communications for not less than three years | Decide whether document versions and edit history are records. If so, the retention design, storage capacity and backup plan must be sized alongside the editors. |
| Peak load testing evidence | No external rule supplied; assessors expect evidence that the design was tested | Run a load test that mirrors your document mix and peak pattern. Keep the results with the sizing decision so you can show why each replica count was chosen. |
Which editor fits a large, sticky-routed deployment
Both editors can serve large user bases, but they get there differently. Collabora's sizing depends on manual replicas and document-level routing, while ONLYOFFICE's connection limits and scaling features depend on which edition you run. Read each card against your own user count, routing design and support requirements before you commit.
Collabora Online licensing by user count
Collabora Online source code is licensed under MPL-2.0, and its paid plans are priced by user tier. The Business plan is listed at 3 euros per user per month for up to 99 users and includes long term support, an SLA and signed security updates. The Enterprise plan for 100 or more users is quoted with volume discounts. Confirm with Collabora which plan and quote apply to your exact headcount, and whether the SLA covers the server versions you will run.
Collabora manual replica scaling
The official Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste. Your team sets the replica count by hand, so capacity planning moves into operations: you size for peak concurrent sessions, not average load. The chart recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Ask Collabora how many concurrent sessions a pod of that size supports for your document mix.
Collabora document-level sticky routing
Your load balancer must route by the WOPISrc parameter so every user editing one document reaches the same pod. This is the design decision that makes Collabora scale, and it is also the main failure point. Confirm that your ingress (Nginx, HAProxy or OpenShift Router are supported) preserves WOPISrc routing under pod restarts, rolling upgrades and node drains. Test with two users on one document during each of these events before go-live.
Collabora Online Controller for large deployments
Collabora describes the Collabora Online Controller as an option for large deployments on Kubernetes, alongside Docker images and system packages. Ask Collabora what the Controller changes in session placement and capacity handling, whether it is included in the Enterprise plan, and how it interacts with your WOPISrc routing. Do not assume it removes the manual replica work until you see it documented for your version.
ONLYOFFICE Docs Community connection limit removed
ONLYOFFICE Docs is licensed under AGPL-3.0, and the Community Edition is the entry point for teams that want to self-host without per-user fees. With version 9.4, released on May 19, 2026, the 20 simultaneous connection limit was removed from the Community Edition, and the stack was consolidated into a single process without RabbitMQ or database dependencies. Load test your own document mix on this version before treating it as a capacity figure.
ONLYOFFICE scaling and support tied to Enterprise
ONLYOFFICE lists an admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support as Enterprise Edition features. Community support runs through GitHub and the forum, and configuration is done through config files only. For a large deployment, confirm in writing whether the scaling guidance you rely on is covered in the Community Edition, what support tier you need, and whether the Developer Edition applies if you embed the editors in a product you sell.
How WOPISrc routing keeps every editor of one document on one pod
The Collabora Online Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, so you set the replica count by hand and make the load balancer do the work of keeping sessions together. The chart's README requires that the load balancer route by the WOPISrc parameter, so every user who opens the same document reaches the same pod. Without that rule, two editors on one file can land on two pods that each hold a separate copy of the document state, and their changes do not merge. Treat the replica count as a capacity decision you revisit on a schedule, not a metric that adjusts itself under load.
The chart supports Nginx, HAProxy and OpenShift Router ingress, so the routing rule has to be written in the syntax of whichever one your platform team already runs. In each case the job is the same: hash on the WOPISrc value from the request, keep that hash stable across replicas, and ensure the rule applies to the editor's WebSocket connections as well as the initial page load. Confirm the exact annotation or directive with your ingress vendor and the chart README for your chart version, because a rule that matches only the first HTTP request will look correct in a demo and fail once a session upgrades to a persistent connection. Also decide how the balancer behaves when a pod is removed, since a drain or rolling update moves documents that are still open.
Before go-live, run a staging test that opens one document from several browsers at once, then forces the failure you plan to live with. Confirm that all editors land on one pod, that edits from each browser appear everywhere, and that copy and paste still works. Then kill the pod that holds an open document and record what the user sees, whether they lose unsaved work, and how long the session takes to recover. Repeat the test under the per-pod resource settings in the chart README, which recommends limits of 8 CPU cores and 8000 MiB of memory and requests of 4 cores and 6000 MiB. Ask your partner to document the results, because the replica count and the failure runbook depend on them.
Sizing pods and integration points for thousands of users
Editing at scale depends on how a few components work together: the file platform that opens the editor, the ingress that routes sessions, the editor pods that do the work, and the storage and identity systems behind them. Each card below names one of these pieces and what to verify before you size the deployment.
Collabora pod resource baseline
The official Collabora Online 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 a starting envelope for the chart, not a capacity figure. Concurrent sessions, document size, embedded images and macro-heavy spreadsheets all change how much of that envelope a pod uses. Ask your implementation partner to show the measured CPU and memory curves under your own document mix before you set replica counts.
Manual replica counts
Horizontal pod autoscaling is disabled in the Collabora chart because scaling breaks collaborative editing, so you set the replica count yourself. Scaling up during a peak only helps new documents, because existing editing sessions stay where they are. Plan replica counts for the busiest hour you expect, such as term start or a quarter-end close, and confirm with your partner how the team will change counts during an incident and how that change is tested before it reaches production.
Sticky routing by WOPISrc
Load balancers must route by the WOPISrc parameter so that every user editing one document reaches the same pod. Without this, co-authors land on different pods and lose the shared session. Verify the routing rule in your ingress, then test it with at least two browsers editing one file, and with a session that is left idle and resumed. Ask whether the rule also holds after a pod restart or a node drain.
Ingress controller compatibility
The Collabora chart supports Nginx, HAProxy and OpenShift Router ingress. Pick the one your platform team already operates and confirm that its WebSocket and long-lived connection timeouts are set for editing sessions. Check that TLS terminates where your security policy requires and that WOPI traffic is restricted to known file platform hosts. A misconfigured timeout often looks like random disconnects, so include an idle-session test in acceptance.
File platform as the WOPI host
The file platform, such as Nextcloud, Seafile or another WOPI host, is the component that authenticates users, checks permissions and hands the editor a document session. Collabora lists Nextcloud and Seafile among its WOPI integrations, and ONLYOFFICE Docs integrates with both. Confirm the connector version against your platform release, the trust relationship between the two systems, and which group permissions map to view versus edit rights.
Storage and identity connections
Document content flows between the file platform, the editor and the storage backend, and user identity flows through the file platform's directory integration. Each hop adds latency and a failure point, so measure save times on your actual object or file storage. Ask how the editor reaches storage, how temporary files are cleaned up, and how a directory outage affects users who already have an open session. Confirm these behaviors in a staging environment before rollout.
Phased rollout from a pilot to peak load
This sequence moves browser editing from a single-node proof of concept to a sized, monitored deployment that can absorb peak concurrent use. Each phase closes with a written output that the next phase depends on, so capacity is proven before users are moved onto it.
Confirm edition and support for the user count
Before any infrastructure is built, the platform owner confirms which editor edition covers the expected number of named users and concurrent editors, and which support terms apply. For Collabora Online, the pricing page states that the Business plan covers up to 99 users and the Enterprise plan applies from 100 users, while CODE is described as not recommended for production. For ONLYOFFICE, scaling for thousands of users is listed as an Enterprise Edition feature, so the Community Edition is not a substitute for a large production rollout. Output: a written edition decision, a named support contract, and a confirmed user and concurrency estimate signed off by the business owner.
Build a reference deployment with manual replicas
The infrastructure team builds a Kubernetes or Docker reference environment that matches the target production layout, with editor pods, the file platform, the WOPI host and the ingress. Because the Collabora Helm chart disables horizontal pod autoscaling, replica counts are set by hand in configuration under change control, and the team records the replica count and the per-pod resource requests and limits in the deployment repository. Output: a version-controlled reference build that can be redeployed from scratch, with a documented replica count for each environment.
Configure WOPISrc routing and test document pinning
The network team configures the load balancer or ingress (Nginx, HAProxy or the OpenShift Router, which the Collabora chart supports) to route every request by the WOPISrc parameter, so all editors of one document reach the same pod. The team then opens one document from several browsers and file platform accounts and confirms that each session lands on the same editor pod. It also tests what happens when a pod is removed and a new session starts. Output: a routing test log showing pinning holds for at least one multi-user session, plus a recorded behavior for pod loss that the operations team has accepted.
Run load and failover tests with representative documents
The QA and performance team builds a test corpus from real templates, including large spreadsheets, documents with images and embedded fonts, and presentations, then scripts concurrent sessions that edit, paste and save. They measure per-pod CPU and memory against the Collabora chart's recommended production limits of 8 CPU cores and 8000 MiB of memory with requests of 4 cores and 6000 MiB, and they record how many concurrent editors one pod sustains before latency or memory pressure appears. Failover is tested by terminating pods mid-session. Output: a capacity table per document type and a signed pass or fail decision on the replica count.
Set monitoring and alerts on pod CPU and memory
The operations team connects per-pod CPU, memory, restart counts and WOPI request errors to the monitoring stack and sets alerts at thresholds derived from the load test, not from defaults. Because autoscaling is off, an alert is the trigger for a person to add a replica, so the alert routes to an on-call owner with the runbook link. Output: working dashboards and a tested alert that fires in a controlled test and reaches the named on-call group.
Cut over by department
Users move onto the editor in waves, starting with a single department whose documents and editing patterns are well understood, then adding departments once the first wave runs without incident. Each wave has a rollback path that re-points the file platform to the previous editing setup, and the team reviews pod metrics and support tickets at the end of each wave. Output: a cutover log per department, a completed rollback test, and a go or no-go record before each subsequent wave.
Document the runbook for adding replicas
The platform team writes a runbook that covers how to add or remove an editor replica, how to confirm that WOPISrc routing still pins new sessions correctly, how to check resource headroom on existing pods, and when to escalate to the vendor or the support partner. The runbook is tested by someone who did not write it, and it is linked from the alert. Output: a reviewed runbook with a tested replica change, owned by a named team and kept under version control alongside the deployment configuration.
Evidence the scaled editing platform must produce
This table maps each piece of evidence a scaled editing platform should produce to the component that generates it and the requirement it supports. Use it to ask a partner what will be delivered at handover and on an ongoing basis. Independent auditors decide whether the controls behind this evidence are sufficient.
| Evidence | Produced by | Supports this requirement |
|---|---|---|
| Load test report per pod size | Load testing run against the Collabora or ONLYOFFICE document server at the planned concurrency, before go-live | Capacity planning for peak term-start or month-end editing |
| Routing configuration export | Ingress or load balancer config (Nginx, HAProxy or OpenShift Router) showing routing by the WOPISrc parameter | Proof that all editors of one document reach the same pod |
| Per-pod CPU and memory metrics | Kubernetes metrics and monitoring stack against the chart's requests and limits | Evidence that pods run within the sized resource envelope |
| Replica change log | Manual replica changes recorded in change tickets, since autoscaling is disabled in the Collabora chart | Change control over capacity adjustments |
| Access logs tying sessions to users | WOPI host (file platform) logs plus document server logs, correlated by user and document identifier | Audit controls over who opened and edited which document |
| Signed update and patch records | Update records from the edition's release channel and the change record for each applied version | Evidence that software updates are authorized and tested |
| Edition and support contract | Vendor support agreement for the chosen Collabora or ONLYOFFICE edition, with its named support scope | Confirmation that a supported, patched component is in production |
| Restoration test results | Backup and restore exercise covering document storage and the WOPI host configuration | Evidence of recoverability for business-critical documents |
How much does scaling self-hosted editing cost and how long does it take?
What does it cost to run self-hosted editing for thousands of users?
The cost has four parts: the editor edition and any per-user subscription, the server capacity needed for peak concurrent editing, the ingress and monitoring around it, and the engineering time to integrate and support it. Community builds carry no license fee, but production use usually needs a paid edition for support and signed updates. The Collabora pricing page lists its Business plan at 3 euros per user per month for up to 99 users, with the Enterprise plan for 100 or more users quoted with volume discounts. Ask for the per-user rate at your exact user count, because the price tier changes at that threshold.
Which costs are one-time and which recur every year?
One-time costs include design, initial deployment, integration with your file platform, load balancer configuration, font and format testing, and staff training. Recurring costs include subscription fees, cloud or data center capacity for the editor pods, monitoring, backups, and the support plan. Upgrades and security patches also recur, because each new editor release has to be tested against your templates and WOPI integration before rollout. Ask any quote to split these lines so you can see what continues after go-live.
How much server capacity does peak concurrent editing need?
Capacity depends on how many people edit the same documents at the same time, not only on total user count. 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. Because autoscaling is disabled and replicas are set by hand, you must size for peak load plus headroom for failover. Ask the partner to model peak concurrent sessions from your usage data and to show the number of pods that model requires, along with the cost of running them.
How long does a scaled self-hosted editing rollout take?
Timing depends mainly on user count, the number of file platforms that connect to the editor, and how many document formats and templates must be tested. A single file platform with a standard set of Office templates moves faster than several platforms with custom macros or legacy formats. Clustered deployments also need load balancer rules, sticky routing by document, and a staged rollout to avoid disruption at term start or quarter end. DeployOpen plans most engagements as fixed scope, so the timeline is written into the agreed scope before work starts. Request a timeline that lists each phase and the client dependencies behind it.
How do integrations change the cost and schedule?
Each connection to a file platform, identity provider or storage backend adds configuration, testing and support work. Collabora lists WOPI integrations with platforms such as Nextcloud, Seafile and Mattermost, and ONLYOFFICE lists integrations with Nextcloud, Seafile and other WOPI-compatible systems. A single integration with a current platform is usually the simplest case. Deeper work, such as custom permission mapping, audit logging or single sign-on, adds scope and time. Ask for each integration to be listed separately in the quote with its test cases.
What does the client need to provide for the engagement?
The work needs named owners on the client side, typically a platform owner, a security contact, a network or load balancer owner, and a business owner who signs off on templates and test results. It also needs representative test documents, including the .docx, .xlsx and .pptx files your staff actually use, and the fonts they depend on. Network access must be in place early, covering the editor hosts, the file platform, the identity provider and the cloud or data center accounts where the servers will run. Delays in any of these usually cost more time than the technical build.
Can our own team run scaled editing without an implementation partner?
Yes, many teams with container and load balancer skills can run it, especially when they use a community build for testing. Production scale adds work that is easy to underestimate: manual replica management, document-level routing, capacity testing, patch testing and a support contract. The Collabora pricing page notes that its Business plan includes long-term support, a service level agreement and signed security updates, while the free CODE edition is described as not recommended for production. Compare the internal staffing hours for these tasks against a partner quote before deciding.
What should a quote for scaled editing include?
A useful quote lists the scope, deliverables, assumptions, client dependencies and acceptance tests in writing. It should name the editor edition and the user count it covers, the sizing model for peak concurrent editing, each integration, the ingress and monitoring components, and the support or retainer terms. It should separate one-time work from recurring items such as subscriptions, support and upgrades. Ask the provider to state which assumptions would change the price, such as a higher user count or additional platforms, so you can compare quotes on equal terms.
Questions to ask a partner before sizing a large editor deployment
Start by asking how the partner pins sessions per document. Collabora's Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, and it requires the load balancer to route by the WOPISrc parameter so every editor of one document reaches the same pod. Ask the partner which ingress it will configure (the chart supports Nginx, HAProxy and OpenShift Router), how it sets replica counts by hand, and how it proves that two browsers opening the same file land on one pod. For ONLYOFFICE, ask how it handles document server clustering and whether the design depends on a paid edition. Ask for the routing configuration in writing before work starts.
Next, ask how the partner load tests with real document mixes rather than synthetic text. A useful test uses your own large spreadsheets, long presentations and templates with embedded images and fonts, run at your expected peak concurrency. Ask what per-pod CPU and memory the test used against the Collabora chart's production guidance of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB, and whether it reports results per pod. Also ask which edition it recommends for your user count and why. The Collabora pricing page lists its Business plan for up to 99 users, and the Enterprise plan for 100 or more users is quoted, so confirm the tier in writing. Ask whether the partner has checked the current ONLYOFFICE Community limits against its own load results before recommending that edition, and confirm the answer against the vendor's current edition comparison.
Then ask how the partner handles pod failure during an active session, and what users see when it happens. Ask what the design does to unsaved edits, how the routing layer reassigns a document after a pod is lost, and how it tests that failure with a live co-editing session. On updates, ask how signed packages are verified, who applies them, in what window, and whether a staging environment mirrors production before each change. Finally, ask what the handover runbook covers: pod sizing, routing rules, scaling steps, restart procedures, log locations, and escalation paths. Confirm in writing before fixed-scope work starts the acceptance criteria for load tests, failover behavior, the edition and support terms, and who owns the runbook after handover.
How DeployOpen scopes and runs a scaled editing deployment
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For scaled browser editing, that means agreeing in writing how many editor pods, which routing layer and which edition your user count requires before any build work starts.
How we scope
- Written scope names the editor, the file platform it connects to and the expected peak number of concurrent editors per document
- Scope records which ingress layer routes by the WOPISrc parameter and how sticky routing is verified
- Scope confirms whether Collabora or ONLYOFFICE is the target and which edition covers your user count and support needs
How we build
- Replica counts are set manually with per-pod CPU and memory limits sized from documented starting values and load tests on your data
- Routing tests confirm that every editor of one document reaches the same pod during failover and rolling restarts
- Container images, fonts and integration with your file platform are tested against your own sample Office templates
How we hand over
- Handover includes runbooks for scaling pods by hand, draining nodes and recovering a document session after a pod restart
- Configuration, sizing assumptions and load test results are documented so your team can repeat them at the next user growth step
- Update, backup and restore procedures are written and rehearsed with your operators before go-live
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainer scope should cover edition updates, security patch review, re-sizing when user counts change and routing regression checks
- Ask your partner to confirm response expectations in writing, since DeployOpen sets these per engagement
