Sizing Collabora Online servers starts with concurrent editors, not total users
Sizing Collabora Online starts with how many people will be editing at the same time, not how many accounts exist in the directory. Concurrent sessions, the mix of document types and the per-user resource figures that Collabora publishes for its product determine how many CPU threads, how much memory and how much bandwidth a deployment needs. A team that counts total users will almost always buy either too much or too little, because most licensed users open a document only a few times a week and many of those sessions are idle for long stretches.
Teams need this work at three points. The first is before purchase, when a Nextcloud or other WOPI host administrator is about to choose hardware or virtual machines and needs a defensible starting figure. The second is before a migration, when editing moves from a desktop suite or another hosted service onto a self-hosted server and the peak load changes shape. The third is before a growth step, such as adding a department, opening editing to external partners or enabling a feature that changes resource use. In each case, collect real session counts from the WOPI host logs and agree the peak window with the business before deciding.
This page does not give a per-server capacity figure. Any number of concurrent editors one server can handle must be confirmed from Collabora for the exact release you plan to run, because the figure depends on the version, the document mix and the host hardware. Ask Collabora for its current sizing guidance and check it against your own load test before you commit budget. Treat the Helm chart's production resource values as a reference point for pod requests and limits, not as proof of capacity.
Sizing options and when each fits
This table compares three ways to size Collabora Online: one server sized from reference values, a fixed server count sized from a concurrency estimate, and a pooled model sized for peak concurrent sessions. Read each row against your own user numbers and measurements, since the right choice depends on how many documents are open at once and how much headroom you can tolerate.
| Approach | When it fits | Headroom cost | What must be measured |
|---|---|---|---|
| Single server from reference values | Small teams or a pilot where total users and concurrent editing are low and downtime for one node is acceptable | Little headroom. Peak load from large spreadsheets or presentations can exhaust one server quickly | CPU and memory during real editing sessions, including the largest files your users open |
| Fixed number of servers from a concurrency estimate | Steady workloads with predictable office hours and a known number of simultaneous editors | Headroom is set once at deployment. Growth or a busy period needs manual adds, and idle servers still cost money | Concurrent sessions per server, document sizes, and how often the estimate is exceeded at peak |
| Pooled model sized for peak concurrent sessions | Organizations with large user bases, spiky demand or multi-tenant hosting where peaks drive the design | Highest standing cost because capacity is held for peak. Scaling must be manual, since autoscaling is not used for collaborative editing | Peak concurrent sessions over time, per-pod memory and CPU at peak, and recovery behavior when a server is lost |
| Reference values in the Helm chart | Kubernetes deployments as a starting point before measurement | The chart's production values are a baseline, not a capacity guarantee for your documents and users | Whether the reference limits fit your workload, confirmed in your own load tests |
How sizing differs for Docker, system packages and Kubernetes
Docker is the quickest way to run Collabora Online on a single host, and the official images are published as collabora/code for x86-64, ppc64 and arm64. Sizing with Docker is mostly about what you give the container. The container runs on the host's CPU and memory, so you control the ceiling through the host itself and any runtime limits you apply.
- Host sizing sets the ceiling: the container shares the host's CPU threads and memory, so size the host for the concurrent sessions you plan to run, not for the container alone.
- Runtime limits are optional: you can cap CPU and memory with your container runtime flags. Confirm with Collabora which limits suit your document mix before you enforce them, because a cap that is too low can slow large spreadsheets.
- Architecture matters: check that the image architecture matches your hardware before you size it. ppc64 and arm64 hosts should be tested with your own documents.
- Single-host limits: one Docker host is one failure domain. Additional servers need your own load balancer with WOPISrc routing.
- Free edition scope: CODE is a rolling release that Collabora describes as not recommended for production, so production Docker sizing should be tested against the edition you intend to run.
Before you commit to a host size, run a load test with documents that resemble yours and watch memory and CPU during the largest sessions.
Installing Collabora Online from system packages puts the server directly on a Linux host that you manage. There is no container boundary, so the host's operating system, libraries and fonts become part of your sizing and maintenance plan. Collabora publishes RPM and DEB packages, and the 25.04 release notes record signing key updates for both, which is a reason to follow the vendor's update guidance closely.
- Dedicated hosts are simpler to size: a host used only for Collabora makes CPU and memory usage easier to measure than a shared application server.
- Fonts and locale affect results: missing fonts change layout and page counts, so install the fonts your users rely on before measuring capacity.
- Process limits: confirm open file limits and process limits on the host, since many simultaneous sessions need them.
- Updates change the baseline: point releases can change performance, so repeat load tests after upgrades.
- Scaling is manual: each additional host needs its own configuration and a document-aware load balancer.
Before sign-off, record the package version, host specification and fonts installed, so you can reproduce the sizing result after a rebuild.
The official Helm chart README sets production resource values per pod: limits of 8 CPU cores and 8000 MiB of memory, and requests of 4 cores and 6000 MiB. These figures are a starting point from the vendor, and your own concurrency testing decides whether to change them. The README also states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replica counts are set manually.
- Requests and limits: requests reserve capacity for scheduling, while limits cap what a pod can use. Set both so the scheduler places pods on nodes that can hold them.
- Manual replicas: change the replica count deliberately, and plan maintenance windows for changes, since autoscaling is not used for this chart.
- WOPISrc-aware routing is required: when more than one pod handles documents, the load balancer must route by the WOPISrc parameter so every user editing one document reaches the same pod. The chart supports Nginx, HAProxy and OpenShift Router ingress.
- Node capacity: confirm your nodes can hold the per-pod requests after accounting for other workloads.
Before you go live, confirm the replica count, resource values and ingress routing rules in a staging cluster, and test one document opened by several users to confirm they land on the same pod.
How to size a Collabora Online deployment step by step
This sequence turns host platform usage data into a tested server plan, so you buy or allocate capacity based on measured peak load rather than guesses about total headcount. Each step produces a documented input or result that feeds the next.
Count users and concurrent editors from host logs
Pull user counts and editing activity from the host platform, such as Nextcloud, for at least one representative period that includes your busiest days. Separate total licensed or active users from the number who open a document in the browser at the same time, and record the peak concurrent figure per hour. Confirm the counts with the platform administrator and the business owners of the heaviest teams. The check is a single table showing total users, average concurrent editors and peak concurrent editors, with the source of each number written beside it.
Classify document types and file sizes
Group the documents people edit into text documents, spreadsheets and presentations, then record the typical and largest file size in each group. Ask the teams that own the largest workbooks and decks for real examples, because a few very large spreadsheets or image-heavy presentations often drive memory use more than average files do. Note which formats are common, including docx, xlsx, pptx, ODF and PDF, since format mix affects load behavior. The output is a short inventory with a typical and a worst-case file per type that you will reuse in the pilot.
Choose a reference configuration
Select a starting server shape with a defined CPU thread count, memory and network path, and write down the per-server editor count you expect it to carry. If you deploy on Kubernetes, the Collabora Online Helm chart README lists production resource limits and requests per pod, which you can use as a reference point, but confirm the values against your own version. Ask Collabora or your implementation partner to review the reference against your concurrency numbers before you commit to hardware. The check is a written configuration with a stated assumption for editors per server, so the pilot has something concrete to test.
Run a pilot with representative documents
Deploy the reference configuration in a non-production environment and connect it to a test instance of your host platform. Have a group of testers open, edit, save and close the typical and largest documents from step two, including simultaneous editing of the same file. Repeat the test with the number of concurrent sessions you expect at peak. The check is a pilot log that records any load time, save failure, or unresponsive session, linked to the document and the number of active editors at that moment.
Measure CPU, memory and bandwidth at peak
During the pilot and, where possible, during a live period, collect CPU utilization, memory use per server and network throughput between browsers, the host platform and the Collabora server. Use the metrics your monitoring stack already collects, and note sampling intervals so the numbers can be compared. Look for memory growth after large documents are closed, since it indicates headroom needs to be larger. The check is a peak table per server that shows the highest values reached and how many editors were active when they occurred.
Add headroom and plan the server count
Use the measured peaks to decide how much spare capacity to keep for growth, failover and large documents, and calculate the number of servers needed to hold peak load with one server out of service. Keep the headroom assumption written down so it can be reviewed when user numbers change. Where you plan to route users across several servers, the WOPISrc routing requirement means each document must stay on one server, so account for uneven distribution. The check is a sizing record that lists the peak figures, the headroom percentage chosen, the server count and the reason for each decision.
Confirm WOPI allow lists still match
Before and after any server or network change, confirm that the WOPI host configuration on the host platform still lists the addresses of the Collabora servers, and that the Collabora server URL uses the same protocol as the host, preferably HTTPS. The Nextcloud administration manual recommends restricting WOPI requests to the Collabora server addresses. Test by opening a document from the host platform after each change, including the scaled-out configuration. The check is a successful open and save from at least one document on every server in the plan, with the allow list entries recorded.
Confirm the plan with Collabora before purchase
Send the written sizing record, the pilot results and the chosen Collabora version to Collabora before you buy hardware or subscriptions. Ask them to review the assumptions, the server count and the support terms that apply to your user count, and ask what they would expect to change at higher concurrency. The Business and Enterprise plan details on the pricing page can inform the quote, but the quote follows from your confirmed scope. The check is a written reply from Collabora that either confirms the plan or lists specific changes you must make before you proceed.
Planning headroom for large spreadsheets and presentations
The per-user figures you size from are averages for typical documents, so the largest spreadsheets and image-heavy presentations in your estate decide whether a server holds up under load. A Calc workbook with many formulas, volatile functions or large linked ranges recalculates on the server side and holds its state in memory for the whole session. A deck with high-resolution photos, embedded video or heavy transitions needs memory to render each slide as the user moves through it. One such session can take a disproportionate share of a pod's CPU and memory, and because every session on that pod shares those resources, a few heavy editors can slow or stall everyone else routed to the same server.
Test with the files people actually use, not samples. Collect the largest workbooks and decks from each department, including the ones that are slow in desktop Office today, and open them in a staging deployment sized the way you plan to run production. Record memory and CPU on the Collabora server while several heavy files are open at once, then while one heavy file is edited by several people. Repeat the test with .docx, .xlsx and .pptx files, since format handling and fidelity can differ by type, and keep the results per format so the headroom you add reflects the heaviest realistic mix rather than the average.
Decide headroom from those measurements. Set aside capacity so that a realistic count of heavy sessions on one server still leaves room for ordinary editing, and treat any file that breaks the budget as a candidate for a separate pool or a size limit agreed with its owners. Confirm with Collabora, in writing, which file formats and document sizes they consider supported at your planned concurrency, how memory use scales with formula count and embedded media, and whether they have benchmark data for workloads like yours. Ask them to state the limits on the same resource figures your deployment will use, so the test results and the vendor guidance can be compared directly.
Security and operations that affect sizing decisions
Sizing is only useful if the deployment stays reachable, restricted and patched at the capacity you planned. The controls below limit which requests reach your Collabora servers, who can open documents, and how quickly you learn that the load has changed.
Restrict WOPI requests by source address
The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of your Collabora servers. Every server you add for capacity becomes another address to allow, so the allow list is part of the sizing change, not a separate task. Confirm how your load balancer or reverse proxy presents client addresses, because an allow list built on the wrong address can block legitimate editing or leave the endpoint open. Review the list whenever you add, remove or replace a server.
Use HTTPS for the Collabora URL
The Nextcloud manual recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Mixed protocols can break the editing session or push users toward insecure connections, which then shows up as failed sessions rather than as a capacity problem. Confirm the certificate chain on every Collabora endpoint behind the load balancer, since a renewal missed on one server can take that server out of rotation for part of your users.
Limit who can open and edit
In Nextcloud Office, administrators can restrict which groups may use the editor and which may edit rather than only view. Limiting access reduces the number of concurrent sessions your servers must carry, which makes your concurrency estimate more defensible. Map the groups that need editing against the headcount used in your sizing model, and recheck the figure after large onboarding or offboarding waves.
Track security advisories against your version
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 that package signing keys were updated for RPM and DEB users. Patching can change memory use, process behavior and timing, so re-run a short load test after an update before assuming the earlier sizing still holds. Confirm your branch receives point releases and check the release notes for each update.
Monitor resource use against your sizing
A sizing model is an estimate until production load confirms it. Track CPU, memory and network use per Collabora server, along with the number of active document sessions, so you can see when peak concurrency moves toward your planned limit. Compare those readings with the per-pod resource limits in the Helm chart if you run on Kubernetes. Set alerts before a server reaches its ceiling, and decide in advance who approves an added server.
Questions teams ask before sizing Collabora Online
What determines the cost of sizing Collabora Online and is it one-time?
The cost of sizing work is set by the agreed scope: how many document types and integration hosts you run, how many environments need sizing, how much usage data you can provide, and how many test runs are needed to prove the numbers. Sizing is usually a one-time piece of work that produces a capacity model, a node or thread plan and a set of thresholds to watch. Costs recur only if you ask for ongoing monitoring reviews, a retainer for capacity changes after growth, or re-testing after a major release. DeployOpen does not publish a price list, so a quote follows from a written scope that lists the deliverables, the inputs you will supply and the review points. Ask each bidder to separate one-time sizing from any recurring support so the two can be compared fairly.
How long does a Collabora Online sizing exercise take?
The length depends mainly on how well your usage is known, how many integration hosts and document types are involved, and whether load tests must be run against your own infrastructure. A team with clean logs and a single host such as Nextcloud will finish faster than one that must first measure concurrency across several platforms. Large spreadsheets and presentations add test cases, because their memory and CPU use differs from text documents. Ask the provider for a timeline tied to named milestones, such as input review, test runs, a draft sizing model and a final report, and confirm which of these are included in the fixed scope.
What must our team provide for a sizing exercise?
Sizing needs real usage evidence and a clear picture of your environment. Typical inputs are:
- Total named users and the groups allowed to edit, as set in your WOPI host configuration
- Usage logs or activity reports from your file platform showing peak concurrent sessions by hour
- Representative sample documents, including the largest spreadsheets and presentations your staff open
- Current hardware or cloud instance details, network paths and any reverse proxy in use
- Expected growth and the dates of planned rollouts
The Nextcloud administration manual also recommends restricting WOPI requests to the Collabora server addresses and using HTTPS for the server URL, so share the intended network design early. Confirm with your platform team which logs you can export and whether sample files can leave your environment.
Can our internal team size Collabora Online without outside help?
Yes, an internal platform team can size Collabora Online if it has someone who can run load tests, read server metrics and model concurrency from usage data. The main gaps teams report are a lack of representative test documents, no baseline for peak concurrent editing, and no time to repeat tests after configuration changes. Collabora's free CODE edition is suited to testing and small teams but is not recommended for production, so a test rig built on it should not be treated as proof of production behavior. Decide early which measurements you will take, who owns the results, and how the model will be checked once users are live.
Does the Business plan at 3 euros per user per month apply to my organization?
The Business plan, priced by the pricing page at 3 euros per user per month, covers up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan applies to 100 or more users and is quoted with volume discounts, adding integration support, customization services and roadmap input. Your user count, which may differ from total employees, determines the tier, so count the people who will actually open documents. Sizing does not change the plan choice directly, but support terms matter when you plan capacity headroom. Confirm current terms on the Collabora Online pricing page before you budget.
Why do large spreadsheets and presentations change the sizing numbers?
Large spreadsheets and presentations consume more memory and CPU per session than typical text documents, so the average user figure can understate peak load. Sizing should therefore test a range of document sizes and add headroom for the heaviest files your staff actually open. Measure memory per session and watch for sessions that stay open for long periods. Ask the provider to show how the headroom was derived from your test files rather than from a generic multiplier, and to state which document types were tested.
What risks should we ask a provider to address in a sizing scope?
The main risks are undersized servers during peak editing, unexpected load from new integrations, and sizing based on data that does not match real behavior. A written scope should name the peak scenario being tested, the acceptance criteria for response times and memory use, and the actions planned if results fall short. Ask how the work handles patching, since Collabora publishes security advisories and new releases that can change resource use. Clarify who keeps the sizing model current after go-live.
What should a written sizing scope include before work starts?
A written scope should list the deliverables, such as a capacity model, a recommended number of CPU threads, memory and bandwidth per server, and the monitoring thresholds to watch. It should state the inputs you will provide, the environments covered and the review points. It should also say what is excluded, such as load testing against production, configuration of the WOPI host or changes to network routing. Ask for the assumptions behind every number, so your team can revisit them when usage grows.
How DeployOpen scopes and delivers Collabora Online sizing
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For Collabora Online sizing, we start from written usage figures and an agreed scope, then deliver sizing that you can review, reproduce and maintain after handover.
How we scope
- Agree in writing which Collabora Online editing workloads, user counts and document types the sizing covers.
- Collect your concurrency assumptions, document mix, host platforms and target infrastructure before any estimate is made.
- Confirm which large spreadsheet and presentation cases need headroom, and record them as explicit scope items.
How we build
- Build the sizing model from your inputs and the vendor's published per-user figures, showing every assumption.
- Test representative documents at expected concurrency on infrastructure matching the planned server specification.
- Validate CPU, memory and bandwidth results against the model and adjust the recommendation where tests disagree.
How we hand over
- Deliver a sizing report with assumptions, formulas, test results and the conditions that would require a new review.
- Provide configuration for the chosen resource limits, replica counts and monitoring thresholds in your environment.
- Walk your operations and platform teams through the model so they can rerun it when user numbers change.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if you want DeployOpen to revisit sizing over time.
- Review sizing again after major Collabora Online branch upgrades, new host integrations or significant growth in users.
- Keep the scope, assumptions and test records current so your auditors and procurement teams can follow the reasoning.
