What a Collabora Online implementation involves
A Collabora Online implementation is the planning and build of a browser editing service that a WOPI host calls. The host, such as Nextcloud, passes a file reference to the coolwsd server, which renders the editor in the user's browser. The work covers server layout, load balancer and reverse proxy routing, TLS endpoints and the host settings that let the two systems talk. Desktop installs of an office suite are outside this scope, so plan the project as a server and network build.
Three triggers usually start the project. The first is replacing a commercial editor, such as Office for the web or Office Online Server, inside an existing host. The second is adding editing to a host that only stores and shares files today. The third is moving from a CODE test instance into production. Each trigger changes the scope: replacing an editor brings format and template checks, a new host integration brings configuration design, and a move to production brings sizing, monitoring and support decisions. Confirm which trigger applies before requesting a quote.
Teams with solid Linux, reverse proxy and container skills can build this in-house, using the Docker image or system packages. Partners are usually engaged for fixed-scope delivery, capacity sizing, hardening evidence and handover to your operations team. If you use a partner, ask for written deliverables your security reviewers and auditors can read, and confirm who keeps the configuration and runbooks after go-live.
The Collabora Online server code is licensed under MPL-2.0, a file-level copyleft license, so your legal team should review how any changes to Collabora's own files will be shared. The edition choice is a commercial decision as well as a technical one. Collabora describes free CODE as suited to testing, home use or small teams and not recommended for production. Subscription plans add long-term support, a service level agreement, signed security updates and customer portal access. Decide the edition together with finance and the support model you need.
What the fixed-scope work includes
A typical written scope covers six workstreams, each ending in a deliverable you keep. Compare any partner's scope against this list to see what is included and what is still open.
WOPI host selection and configuration
Confirm which WOPI host will call Collabora Online and which version it runs, because the host sets the editor URL, token handling and group rules. Record the host settings the rollout depends on, and check that the host appears in Collabora's list of supported integrations before the build starts. Deliverable: a host configuration record.
Deployment method and replica plan
Choose between Docker images, system packages or Kubernetes, since this decides how upgrades and replicas are handled. The Helm chart README disables autoscaling because scaling breaks collaborative editing, so replicas are set by hand and sized against its recommended production limits of 8 CPU cores and 8000 MiB per pod. Deliverable: an architecture document with the method, replica count and capacity assumptions.
Reverse proxy and TLS termination
Set up the ingress layer in Nginx, HAProxy or OpenShift Router, the three options the Helm chart supports, or in the proxy your environment already runs. Route by the WOPISrc parameter so all users editing one document reach the same server, and confirm how certificates are issued and renewed. Deliverable: configured environments with proxy configuration and certificate records.
Host allow list and server URL settings
Restrict WOPI requests to the Collabora server addresses and set the server URL to the same protocol as the Nextcloud installation, preferably HTTPS, as the Nextcloud administration manual recommends. Mismatches are easiest to catch by opening a test document from each host and server pair. Deliverable: a settings record and test evidence for each pair.
File format and editing rights testing
Test the formats your users actually exchange, such as docx, xlsx and pptx, plus PDF, RTF, CSV or Visio files where they matter. Confirm the group rules that decide who may use the editor and who may edit a document versus only view it. Deliverable: test evidence listing each format, role and result, with failures logged for retest.
Monitoring and operational runbooks
Define what is watched on each coolwsd server and proxy, such as availability, resource use and concurrent sessions, and agree alert thresholds with the team that will respond. Write runbooks for restarts, replica changes, certificate renewal and rollback to the prior release. Deliverable: a runbook set and a handover session with the operations team.
Phases and the output of each
Each phase closes with a named deliverable, so the scope, design, build, test, cutover and handover can each be approved before the next one starts.
Confirm requirements and scope
Discovery sessions with your platform, security and operations owners record the WOPI host, user counts, expected peak concurrent editing, file formats, identity model and edition choice. The phase closes with a signed-off scope document listing what is in and out. Ask the partner for a schedule built around your environment and approval steps.
Design architecture and size servers
The design covers the coolwsd topology, reverse proxy and TLS termination, WOPI allow list settings and how sessions route to the same server. The sizing worksheet turns expected concurrency into server counts and resource requests. The official Helm chart README gives production limits as a reference point, which you should confirm against your own load. The phase closes with a signed-off design and sizing worksheet.
Build in a non-production environment
The build runs in a staging environment that matches the approved design, using the deployment method and edition chosen in scoping. Configuration, certificates and the WOPI host connection are set up and recorded. Collabora describes the free CODE edition as not recommended for production, so the staging build should match the production edition. The phase closes with a build record and a configuration baseline.
Run integration tests with the WOPI host
Testers open, edit, save and co-author documents from the WOPI host in staging, covering docx, xlsx and pptx files, group-based edit and view rights, reconnects and the failure of one server. Each case records the expected result, the actual result and any defect. The phase closes with a test report, and cutover waits until the agreed defects are resolved or accepted in writing.
Cut over to production
The team moves the WOPI host to the production Collabora endpoints inside an agreed change window, with a rollback path defined before the change starts. The team checks document opening, saving and permissions from real user accounts after the switch. The phase closes with a change record showing the times, steps taken, checks passed and the rollback decision.
Hand over with runbook and support terms
The handover delivers a runbook covering start and stop procedures, certificate renewal, update steps, log locations, capacity checks and escalation contacts. Operators walk through the runbook with your team and confirm which support and update terms apply, including any subscription terms with the vendor. The phase closes when your owner accepts the runbook and handover in writing.
What drives cost and duration
This table lists the main drivers of Collabora Online rollout effort and cost, why each one moves the work, and how to keep it manageable.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Concurrent editors and peak load | Peak simultaneous sessions set replica count and memory. Autoscaling is not used because it breaks co-editing. | Measure peak concurrency first. Use the Helm README's production limits of 8 CPU cores and 8000 MiB per pod as an input, then test. |
| WOPI hosts and tenants | Each WOPI host, such as Nextcloud, adds allow lists, sessions and user groups to configure and test. | Standardize settings across hosts where possible. Document each host's allow list and server URL. |
| Hosting model and environments | Kubernetes needs cluster, ingress and Helm work. VMs need package, service and patch runbooks for each environment. | Choose one hosting model for the estate. Clone production settings into test and staging. |
| Reverse proxy and ingress | Nginx, HAProxy or OpenShift Router must route by WOPISrc so one document reaches the same pod. | Reuse the ingress type your team already runs. Test routing with two users on one document early. |
| Edition and support tier | CODE is free but not recommended for production. Business costs 3 euros per user per month for up to 99 users (Collabora pricing page). | Compare subscription fees with the support effort you would otherwise carry. Illustrative: 40 users at that rate is 120 euros per month. |
| File formats and template testing | Fidelity of docx, xlsx and pptx files, fonts and templates drives test hours and rework before cutover. | Test a representative sample of documents and templates from each department before go-live. |
| Branding and customization | Themes, fonts and CheckFileInfo behavior changes need design, build and regression testing. | Limit branding to logo and colors at first. Move custom integrations to a later phase. |
| Identity integration and compliance evidence | Sign-in runs through the WOPI host's identity. Assessors expect access rules and change logs as evidence. | Reuse the host's SSO and group rules. Keep configuration exports and change records from the start. |
| Air-gapped or restricted networks | Offline package mirrors, image transfer and blocked update endpoints add build and patch steps. | Confirm package mirror and update paths before design sign-off. Confirm whether any optional features need outbound access. |
What usually goes wrong and how to prevent it
Most Collabora Online rollouts stall for a small set of predictable reasons. Each card names the failure, why it matters for the plan and cost, and the step that prevents it.
Running CODE in production
CODE is free and released roughly monthly as a rolling build, and Collabora describes it as suited to testing, home use or small teams rather than production. Teams that adopt it for production inherit no long term support, no service level agreement and no assured signed security updates. Before scoping, decide whether the subscription or a supported build is required, and price that line in the quote.
Sizing from user counts
Headcount says little about load, because the server works per active document session rather than per licensed user. Estimate peak concurrent editors per document type and per office hour, then size coolwsd capacity from that figure. Ask the vendor or your architect to confirm per-pod capacity against the resource requests in the Helm chart before buying hardware.
Load balancer ignoring WOPISrc
The official Helm chart documentation states that load balancers must route by the WOPISrc parameter so that everyone editing one document reaches the same pod. A balancer that uses round robin or cookies alone splits co-editors across pods, which breaks live collaboration and copy and paste. Test routing with two sessions on one file during acceptance, and confirm the ingress you choose supports this rule.
Allow list blocking or left open
The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers. An allow list that omits the WOPI host breaks every document open, while one left open accepts requests from any host. Document the WOPI host addresses in the design, configure them explicitly, and retest after every change to the host's network path.
Mixed protocols between host and server
The Nextcloud administration manual advises using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. A mismatch causes blocked content, failed token exchanges or editing that loads but does not save. Fix the protocol on both sides in the design, terminate TLS at the reverse proxy, and check the server URL in the host settings before user testing.
Skipping format tests
Collabora supports docx, xlsx and pptx alongside OpenDocument formats, but real files carry embedded fonts, macros, tracked changes, complex tables and custom templates that render differently. Skipping tests on representative files from each department shifts defects to users after go-live. Build a test set of real documents from each format and sign off rendering and saving before cutover.
Late AI assistant decisions
Collabora Online 26.04 adds an optional AI assistant across Writer, Calc and Impress. It is off by default, and administrators must choose the AI provider and whether it runs externally or on their own infrastructure. Leaving that choice to the end of the project creates data handling and procurement gaps. Record the decision in the scope, keep the feature disabled until the provider is approved, and budget for its review as a separate item.
Which parts teams keep in-house and which they outsource
This table shows who typically owns each Collabora Online work package, the skills it needs and whether partners are commonly used, so you can split the work between your team and a partner.
| Work package | Typical owner | Skills needed | Partners commonly used |
|---|---|---|---|
| WOPI host configuration | In-house, with host admin support | Nextcloud or other WOPI host administration, group rules, allow lists | Sometimes, for group access design and testing |
| coolwsd build and container or package work | Shared, depending on Linux packaging experience | Docker or system packages, Linux service management, image versioning | Often, when the team has not run the server before |
| Reverse proxy and TLS | In-house | Nginx or HAProxy configuration, certificate management, WebSocket handling | Rarely, unless the network design is complex |
| Sizing and load testing | Shared, with a partner for test design | Capacity planning, load tooling, reading concurrent editing metrics | Often, for planned peak tests and written results |
| Format and template testing | In-house, with business owners | Knowledge of your docx, xlsx and pptx files, templates and fonts | Sometimes, for a structured test corpus and sign-off records |
| Edition and vendor contract decision | In-house (procurement and leadership) | Licensing review, user counts, support requirements | Sometimes, for a written comparison of editions |
| Change control and handover | In-house, with partner-written runbooks | Change records, runbooks, access reviews, update procedures | Often, for documentation and handover sessions |
How the plan changes by starting point
When Nextcloud is the only WOPI host, the first decision is whether to use the built-in CODE server or a dedicated Collabora server. Collabora describes CODE as suited to testing, home use or small teams and not recommended for production, so most production plans need a dedicated server or a subscription.
- Scope: mostly configuration of the Nextcloud Office app, including the server URL, WOPI allow list and group edit rights, covered in the Nextcloud integration topic.
- Phases: a pilot on one account group can run quickly, while a dedicated server adds host build, TLS and reverse proxy work.
- Effort drivers: the expected number of users and whether the built-in server can carry them, plus who patches the editor server.
- Cost: CODE has no subscription fee. Collabora's pricing page lists the Business plan at 3 euros per user per month for up to 99 users, so confirm which edition the quote assumes.
Moving documents from Office for the web, Office Online Server or another editor changes the plan mainly through file testing, user change management and cutover timing. The migration topic covers format checks for docx, xlsx and pptx, templates, fonts and staged cutover in detail.
- Scope: an inventory of document types, templates, macros and externally linked content, which becomes the test set for the build.
- Phases: a discovery phase is added before the build, and a parallel-run period decides how long both editors stay available.
- Effort drivers: the volume and complexity of templates and macros, and whether the old editor also serves other applications that must keep working.
- Cost: license spend on the old editor may continue during overlap, so ask for the overlap period to be stated in the written scope and quote.
Large deployments usually run on Kubernetes with the official Helm chart and, for large fleets, the Collabora Online Controller. The chart README disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, so replica counts are set by hand and the load balancer must route by WOPISrc.
- Scope: cluster readiness, ingress choice among Nginx, HAProxy and OpenShift Router, and WOPISrc routing, as set out in the Helm and high availability topics.
- Phases: capacity testing at fixed replica counts comes before go-live, since the platform cannot scale the service automatically.
- Effort drivers: peak concurrent editing, the existing platform team's skills, and pod sizing. The chart recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB.
- Cost: most recurring cost is node capacity and platform operations, so ask how the quote splits one-time build from ongoing operation.
On a virtual machine or Docker host, the plan is smaller but still needs its own host build, reverse proxy, TLS and update routine. Installs can use system packages or Docker images, and the free CODE image is published as collabora/code for x86-64, ppc64 and arm64.
- Scope: host build, TLS termination, WOPI allow list and a monitored update routine, with lockdown detail in the security hardening topic.
- Phases: a single host can be built quickly, but a second host for availability adds routing and session design.
- Effort drivers: the chosen install path, how the host is patched, and the number of concurrent editors each server must carry.
- Cost: recurring work is the update routine plus any subscription fee, so confirm which package channel and edition the quote covers.
In an air-gapped or restricted network, the plan centers on how packages, images and updates reach the server without direct internet access. Each update must pass through the same transfer and validation path as any other controlled software.
- Scope: an internal mirror of packages or images, an offline update process and confirmed licensing for the chosen edition.
- Phases: each release needs a transfer and approval step, so the operate phase should budget for it from the start.
- Effort drivers: how often the change process allows updates. Security advisories such as CVE-2026-23623, fixed in 25.04.7.5, show why the window matters.
- AI features: the 26.04 release adds an optional AI assistant that is off by default, with the provider hosted externally or on your infrastructure, so keep it disabled unless it is approved.
- Cost: recurring transfer and validation effort per release. Ask the vendor whether a subscription is needed for signed packages and support in your environment.
What the client needs to provide before the quote
A fixed-scope quote for Collabora Online depends on the inputs you give us before scoping starts. The most important are the WOPI host and its version, since the host determines how documents are opened, saved and authenticated. Confirm whether you run Nextcloud, ownCloud, Seafile or another host, and which version, because the integration steps and allow list settings differ by host.
Next, supply sizing data: expected total users, peak concurrent editing, and the mix of documents you expect people to open. Include the document types and templates in use, such as docx, xlsx, pptx, PDF or Visio files, and any heavy templates or macros that change load. Also state the hosting target (your data center, a private cloud or a public cloud account), the network zones that will host the servers and proxy, and whether editing must stay inside a restricted segment.
Name owners for each control point before the quote is written. You should identify who owns the DNS records, the TLS certificates and their renewal process, the reverse proxy configuration, and administrative access to the hosts. Identify also who controls the identity groups that decide edit and view rights in the WOPI host, and whether those groups come from your directory. Missing owners are one of the most common causes of delayed go-live.
Finally, decide on the edition and support tier. Confirm whether the free CODE build is acceptable for a test or limited pilot, or whether production requires a subscription, and which support level you need. Collabora's pricing page lists different plans for smaller and larger user counts, so your expected user count directly affects the subscription choice. Your written scope and these inputs together determine the quote. DeployOpen does not publish a price list.
Questions buyers ask before hiring help
Is CODE safe to use in production for document editing?
Collabora does not recommend CODE, its free edition, for production. According to the CODE page, it is suited to testing, home use or small teams, and it is released on average once a month as a rolling release. For production, the subscription editions are the option Collabora offers. According to the Collabora pricing page, the Business plan includes long term support, a service level agreement, signed security updates and customer portal access. Confirm with Collabora whether these terms fit your user count and risk profile before you choose an edition.
What does the Collabora Business plan include compared with Enterprise?
According to the Collabora pricing page, Business 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. Enterprise is for 100 or more users, is quoted with volume discounts, and adds integration support, customization services and roadmap input. Confirm response times, support hours and what the service level agreement covers directly with Collabora, because those terms decide whether a plan fits your operating model.
What drives the cost of a Collabora Online implementation?
Cost follows the written scope. The main drivers are the number of WOPI hosts to connect, the number of coolwsd servers or Kubernetes replicas needed for peak concurrent editing, reverse proxy and TLS work, file format and template checks, branding or integration work, and the subscription edition you choose. Split the quote into one-time work such as design, build, testing and cutover, and recurring items such as subscription fees, infrastructure and updates. Ask for each line to be priced separately so you can see what changes if the scope moves.
Is a Collabora Online rollout fixed-scope, and how long does it take?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. No duration is stated here because it depends on the number of WOPI hosts, server topology, user numbers, document migration and your approval steps, none of which are known until scoping is done. Ask for phases with a deliverable and a date for each, and confirm which dependencies sit with your team, such as DNS, certificates and the WOPI allow list settings on the host.
What must we provide, and what do we get at handover?
You provide access to your cloud accounts, data center or air-gapped network, DNS and certificate control, administrator access to the WOPI host, the user and group data that sets edit and view rights, and named staff for approvals and testing. At handover, the agreed scope should deliver the documented configuration, the reverse proxy and TLS setup, test results and an operating runbook. Confirm the exact deliverable list in the written scope before signing, since handover content varies by engagement.
Can our own team deploy Collabora Online without a partner?
Many teams can, provided they have Linux, reverse proxy, TLS and WOPI host administration skills and time to test. The Nextcloud administration manual recommends restricting WOPI requests to the Collabora server IP addresses and using HTTPS for the server URL, which shows the host-side work involved. The Helm chart README states that horizontal autoscaling is disabled and that load balancers must route by the WOPISrc parameter so all users editing one document reach the same pod, a detail that is easy to miss. A partner adds the most value in scoping, testing and documented handover.
How DeployOpen scopes and delivers this work
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and that is how we approach a Collabora Online rollout. The engagement starts with a written scope that fixes what gets built and delivered before any work begins.
How we scope
- The written scope names the WOPI host, the expected editing users and the file formats to be opened and saved.
- Sizing covers coolwsd server count, CPU and memory per server, and planned peak concurrent editing sessions.
- The scope records the reverse proxy, TLS termination and how WOPI traffic is restricted to the Collabora server addresses.
- We confirm whether the team will use free CODE or a Business or Enterprise subscription, and document the decision.
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
How we build
- We deploy Collabora Online with Docker images, system packages or Kubernetes, depending on your platform standards.
- Load balancing is configured so all users editing one document reach the same server, routed by the WOPISrc parameter.
- The WOPI host connection is configured and tested, including the server URL and the group rules for edit and view rights.
- Document format tests cover the OpenDocument, docx, xlsx and pptx files your users actually open, before go-live.
- Each build step is checked against the agreed scope and recorded so the rollout can be repeated in other environments.
How we hand over
- Handover includes architecture diagrams, configuration records, sizing assumptions and the routing and TLS setup.
- Runbooks describe how to restart services, rotate certificates, apply point releases and check editing health.
- Operators are trained on the update process, including how Collabora publishes release branches and security advisories.
- Test evidence, such as format checks and failover results, is delivered so your team can review what was verified.
- Open items and risks are listed in writing, with the owner and the next step for each.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Point releases and security fixes can be planned into a regular change window agreed with your operations team.
- Capacity reviews can be scheduled as concurrent editing grows, so sizing stays aligned with real use.
- Confirm with Collabora which support tier and service levels apply to your chosen Business or Enterprise plan before you rely on them.
- Support scope, response expectations and fees are set in the written agreement, and we provide a quote from that scope.
