Collabora Online for hosting providers and MSPs

Collabora Online for hosting providers: what changes when editing is a service you sell

A hosting provider or managed service provider that resells file sharing or groupware usually reaches the point where customers ask for in-browser editing of Office documents. Collabora Online fits that role because it works as a WOPI client, so it plugs into platforms such as Nextcloud, ownCloud and Seafile while the document editing servers run in infrastructure you control. The change for your operation is that editing stops being a feature of one customer's instance and becomes a shared service with its own capacity, routing and support obligations. Before you commit, confirm which WOPI host versions your tenants run, because the integration settings differ between them.

Routing is where multi-tenant setups most often break. The Helm chart documentation states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replicas are set manually, and load balancers must route by the WOPISrc parameter so that everyone editing one document reaches the same pod. Your load balancer and ingress design therefore has to keep document sessions sticky across tenants, and you should test it with concurrent sessions from several tenants before any customer depends on it. Sizing follows from the same design: the chart's production example uses 4 cores and 6000 MiB as requests and 8 cores and 8000 MiB as limits per pod, which is a starting point for your own concurrency tests, not a capacity promise.

Licensing and support change most in the commercial model. The free CODE edition is described by Collabora as not recommended for production, so a service sold to paying tenants needs a subscription. Collabora's pricing page lists a Business plan at 3 euros per user per month for up to 99 users, with long term support, an SLA, signed security updates and customer portal access, and an Enterprise plan for 100 or more users with volume discounts. Ask whether your resale model fits those per-user terms, who holds the contract, and how a tenant's support request reaches the right party. Also confirm what the Enterprise plan's integration support covers for your specific hosts, since that is the support boundary you will hand off to.

Hosting and MSP requirements that shape the Collabora Online build

This table maps each regulatory or technical requirement that applies to a hosting provider or managed service provider offering Collabora Online to the build decision it drives. Read each row as a question to answer in your design: what the rule asks, and what your architecture, contracts or runbooks must show.

Requirement	What it asks for	What it means for the build
NIS2 classification	Cloud computing providers and managed service providers are treated as high-criticality sectors under NIS2 Annex I.	Your Collabora Online service sits inside a regulated provider's scope, so availability, incident handling and supplier oversight must be designed in from the start, not added later.
Commission Implementing Regulation (EU) 2024/2690	Sets the technical and methodological requirements for NIS2 Article 21(2) measures for cloud, data center, managed and managed security service providers.	Confirm with your compliance lead which measures in this regulation apply to your service and map each one to a specific control, owner and evidence source in your Collabora Online environment.
GDPR Article 28 processor terms	Processor contracts must limit processing to documented instructions, including transfers, and require Article 32 security measures.	When you host documents for your customers, your Collabora Online logs, caches and any AI or external integration settings must follow those documented instructions. Confirm where document content is processed and stored.
Data Act switching rights	Data processing service providers must let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period.	Keep document storage, WOPI host configuration and tenant mappings portable and documented so a customer can move to self-hosted Collabora Online without losing files. Ask your legal team how the notice and transition periods apply to your contracts.
Data Act switching charges	From 12 January 2027, providers may not impose switching charges, and until then reduced charges may not exceed costs directly linked to switching.	Track the costs of exporting and re-pointing WOPI integrations per customer so any switching charges you set can be justified against the rule that applies on the date of the switch.
WOPISrc routing rule	The official Helm chart says horizontal pod autoscaling is disabled because scaling breaks collaborative editing, and load balancers must route by the WOPISrc parameter.	Multi-tenant routing must send every user editing one document to the same pod. Replica counts are set manually, so capacity planning and tenant placement need to be designed before growth, not during peak load.
Nextcloud WOPI restriction	The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers and using HTTPS for the server URL.	In shared hosting, network allow lists must be set per tenant platform. Confirm each customer's Nextcloud or WOPI host can reach only its assigned Collabora servers.
Patching and advisories	Collabora publishes security advisories, such as the 25.04.7.5 fix for CVE-2026-23623, and updates package signing keys for RPM and DEB users.	Your change process must track Collabora advisories and signing key changes for every tenant environment, with a documented window for applying signed updates across all servers.

Multi-tenant WOPI settings, scaling and integrations that matter for hosts

Tenant isolation in a shared WOPI setup starts with deciding who is allowed to reach the Collabora server and who is allowed to open or edit documents. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers and using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Those two settings protect the trust path between the file host and the editor, so they should be documented per tenant and checked after every change. Group-based controls add a second layer, because the Nextcloud manual describes limiting which groups can use the editor and which can edit rather than only view.

WOPI host allow list: Restrict WOPI requests to the IP addresses of your Collabora servers, and confirm the list again whenever nodes are added, replaced or moved behind a new address.
HTTPS for the server URL: Use the same protocol for the Collabora server URL as for the file host, preferably HTTPS, so that tokens and document traffic are not exposed in transit.
Group-based editing rights: Limit editing to the groups that need it and set other groups to view only, mapping these groups to your tenant structure.
Tenant mapping: Decide whether each customer gets its own group, instance or server pool, and record which option you chose and why in your service documentation.
Operator access: Confirm which of your staff can change allow lists or group settings, and log those changes.

Before you onboard a customer, check that a user outside their group cannot open or edit one of their documents, and that requests from unlisted addresses are refused.

How a document request reaches the same pod for every editor

In a multi-tenant setup, a tenant user clicks to edit a document in the hosting platform, which is the WOPI host. The WOPI host generates a WOPI access token and a WOPISrc value that identifies the file, then returns an editor URL that points at the Collabora Online endpoint. The browser then opens a connection to Collabora through your load balancer. The critical design point is that every editor of one document must land on the same Collabora pod, because collaborative editing state lives in that pod's memory. The official Helm chart documentation states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, and that load balancers must route by the WOPISrc parameter so all users editing one document reach the same pod. Your load balancer therefore needs to hash on WOPISrc, not on client IP or a plain round-robin rule, and your ingress choice (Nginx, HAProxy or OpenShift Router are the options the chart supports) must be configured to do so.

Walk the path with a test document before go-live. Open the same file from two tenant accounts in separate browsers, then check on the pods which instance served each connection. Confirm that the WOPISrc value survives every hop, including any reverse proxy or tenant-facing gateway you place in front of the load balancer, because a rewritten or truncated value will split editors across pods without any visible error. Also confirm that the WOPI host restricts requests to the Collabora server addresses, as the Nextcloud administration manual recommends for its own integration, and that the Collabora server URL uses the same protocol as the host, preferably HTTPS. Your platform team should decide whether the per-document routing rule is maintained by you or by a partner, and who owns changes when a tenant or pod is added.

Ask whether the COOL Controller is needed for your size. Collabora describes the Controller as offered for large deployments, so for a provider with many tenants and high concurrency, the question is whether manual replica management and hash-based routing remain manageable at your scale. Confirm with Collabora, through the product documentation or the sales team, what the Controller does in your topology, how it fits with your WOPISrc routing, and what it costs in a subscription. Until that answer is in writing, treat the routing design as provisional, and make sure the sizing exercise covers how many documents a single pod can hold open at once.

Scaling and sizing decisions that drive hosting cost

For a hosting provider, most of the Collabora Online cost is set by a handful of early choices: how many pods run, how much each one reserves, which edition sits underneath, and how tenants share capacity. Each decision below changes both the infrastructure bill and the support burden, so they should be settled together rather than one at a time.

Replica count set by hand

The official Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, so replica counts are set manually. Every extra pod is capacity you pay for around the clock, whether or not editing peaks. Ask your team to model peak concurrent editing sessions per region, then decide how much headroom is worth paying for and who changes the count when load shifts.

Pod requests and limits

The chart's production guidance is 8 CPU cores and 8000 MiB of memory per pod as limits, with requests of 4 cores and 6000 MiB. Requests decide how many pods fit on a node, so they drive node count and cost more than limits do. Set requests from measured use on your own documents, because a pod sized too small degrades editing for every tenant on it.

Free CODE or a supported subscription

CODE is the free edition, released roughly monthly as a rolling release, and Collabora describes it as not recommended for production. A hosting service sold to paying customers usually needs long term support, a service level agreement and signed security updates, which the Business plan includes. Compare the per-user subscription cost against the staff time spent absorbing unsupported releases and incidents.

Tenant grouping and isolation

Decide whether tenants share pods, share a cluster with dedicated pods, or get their own deployment. Shared pods lower cost but mean one tenant's heavy documents or a noisy neighbor can slow others, and logs and fault domains mix. Dedicated deployments simplify support and data separation but multiply replicas, upgrades and monitoring. Write the rule down so sales can price tiers against it.

Ingress choice and session routing

Load balancers must route by the WOPISrc parameter so every user editing one document reaches the same pod. The chart supports Nginx, HAProxy and the OpenShift Router, and each has different behavior for this routing and different operating skills in your team. Confirm the chosen ingress keeps sessions sticky through upgrades and failovers, and test it with two users on one document before go-live.

Dedicated or shared servers

A shared server pool reduces idle capacity but couples tenants through the same process limits, while dedicated servers isolate failures and fit tenants with strict contractual terms. Ask whether your customers' data-residency or contract clauses require separation, and whether your team can run that many instances. The answer determines whether your cost scales with tenants or with peak load.

Rollout for a hosting provider: from pilot tenant to general availability

This sequence moves a multi-tenant Collabora Online service from design on paper to general availability, with each gate proving the previous one before tenants are added. The output is a tested tenant model, a load-tested cluster, a documented support path and a routine that keeps every tenant patched.

Design the architecture and tenant model
The provider's platform team decides how tenants map to WOPI hosts, which Collabora Online deployment serves each tenant, how WOPISrc routing keeps all users on one document on one pod, and how allow lists, TLS and ingress are set per tenant. The design should also state which Nextcloud or other WOPI host instances connect to which Collabora endpoints, and which telemetry labels identify a tenant. The step is done when the design is written down, reviewed by security and operations, and every open question has an owner.
Build and test a pilot tenant
Stand up one internal pilot tenant on the planned topology, using the same images, ingress and WOPI host configuration you intend to sell. Run document fidelity tests with representative DOCX, XLSX, PPTX, ODF and PDF files, comparing rendering and saving against the expected results your customers will notice. The step closes when fidelity issues are logged, fixed or accepted in writing, and the pilot has run long enough to surface integration problems with the WOPI host.
Load test against realistic concurrency
Measure concurrent editing sessions, document open and save times, and resource use per pod against the sizing you assumed, not against a single-user test. Replicas are set manually because horizontal pod autoscaling is disabled in the official Helm chart, so the test should confirm how many replicas each expected concurrency level needs. The step is done when you have a documented capacity figure per pod and per cluster, and a clear rule for when a tenant gets its own replicas.
Set up partner subscriptions and support handoffs
Decide how your organization buys Collabora support for the service: whether CODE is only for testing, and which Collabora plan covers production, including the per-user Business plan terms and the Enterprise path for larger counts. Define who answers tenant tickets first, who escalates to Collabora, and what evidence (logs, versions, WOPI host details) is captured at handoff. The step closes when the subscription is in place, the support matrix is signed off, and a test escalation has been run end to end.
Onboard tenants in phases
Add tenants in small waves rather than all at once, starting with customers who accept a pilot-style rollout. For each wave, confirm the tenant's WOPI host allow list, group access settings for editing versus viewing, TLS and proof configuration, and that the tenant's load fits the capacity already measured. The wave is complete when the tenant's test users have edited and saved documents successfully and the monitoring dashboards show the tenant's traffic in its own view.
Run the upgrade and advisory patching routine
Agree a routine for applying Collabora point releases and security fixes across every tenant, with a staging environment that receives each release before production. Subscribe to Collabora's release notes and security advisories, and record which build each tenant runs. The routine is working when a recent advisory has been applied to staging, tested against the pilot tenant, rolled out to production and recorded in each tenant's change log.
Confirm general availability criteria
Before general availability, review the evidence from every previous step against written criteria: fidelity results, measured capacity, support path tests, onboarding records and patching history. The platform owner and the service owner sign the decision, and any gap found becomes a dated action with an owner. General availability is declared only when the criteria are met and the documentation your customers will read matches the service you run.

Compliance obligations hosts and MSPs carry into the service

A hosting provider or managed service provider that puts Collabora Online in front of customers takes on obligations as a service operator, not only as a software user. The cards below cover the EU rules, attestation frameworks and product obligations that shape what you must document, contract and disclose. DeployOpen prepares the technical controls and evidence for these reviews, but independent auditors and certification bodies issue the reports.

NIS2 duties for managed service providers

NIS2 Annex I places managed service providers and managed security service providers in the ICT service management sector, which it treats as highly critical. If your hosted document editing sits inside a service you sell to organizations in scope, your own risk management and incident reporting duties apply to that editing layer too. Confirm with counsel which of your customers and entities fall under the directive and how national transposition applies to you. Map the Collabora Online components, their update path and their logging to your existing NIS2 risk register.

Implementing Regulation 2024/2690 measures

Commission Implementing Regulation (EU) 2024/2690 sets the technical and methodological requirements for Article 21(2) measures for managed service providers and other digital providers. Read it against your own service architecture rather than assuming a generic control list applies. For a multi-tenant Collabora Online setup, the areas to document include tenant isolation between WOPI hosts, access control to administration interfaces, patch handling for the editing servers, and how you respond to a vulnerability disclosure affecting the stack.

GDPR processor contract terms

When you host customer documents, you act as a processor under GDPR Article 28(3). The contract must bind you to process personal data only on documented instructions, including for transfers, and to apply the security measures required by Article 32. Document-editing traffic carries full file content, so the contract should name where editing servers run, who can access logs, and how sub-processors are disclosed. Check that your customer agreement describes the Collabora Online components as part of the processing, including any optional AI features, which are off by default in 26.04.

Data Act switching rights and charge limits

The EU Data Act has applied since 12 September 2025 and requires data processing service providers to let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, providers may not impose switching charges, and until then reduced charges may not exceed costs directly linked to switching. For a hosted editing service, define in advance how documents, user records and sharing links are exported, and confirm with your engineers that the export works on a Collabora Online deployment you run.

SOC 2 scope and report types

SOC 2 examinations use the AICPA 2017 Trust Services Criteria, and the security common criteria CC1 to CC9 apply to every SOC 2 report. A Type 1 report describes your system and the suitability of control design as of a date, while a Type 2 report adds an opinion on operating effectiveness over a period. Decide early which of the five categories you include and whether editing availability and confidentiality belong in scope. Customers usually ask for Type 2 because it shows controls working over time, and SOC 2 reports are generally restricted to specified users.

ISO/IEC 27001 certification route

ISO/IEC 27001:2022 is certified by accredited certification bodies, not by ISO itself, and certificates follow a three-year cycle with at least one audit every calendar year. Its Annex A is organized into four themes of organizational, people, physical and technological controls. Scope the certificate to the service that includes Collabora Online, including its hosts, administration access and backup handling. Ask any certification body how they treat a hosted component delivered and maintained by a third party before you commit to a scope.

Cyber Resilience Act reporting for software

The Cyber Resilience Act applies to products with digital elements, including software, from 11 December 2027. Its Article 14 reporting obligations have applied since 11 September 2026 to in-scope products placed on the market. Whether your use of Collabora Online makes you a manufacturer depends on whether you place a product on the market, such as a packaged appliance or a commercially distributed application, versus running it only as an internal service. Confirm your role with counsel and track vulnerability disclosures from the upstream project so you can meet any reporting duty you hold.

Questions hosting providers ask before hiring outside help

What drives the implementation effort and cost for a hosted Collabora Online service?

The main drivers are the number of WOPI host integrations you will run, how many tenants share the editing servers, the concurrency you need to serve at peak, and how much of the routing, scaling and monitoring you want built as code. Software licensing is only one line. Most of the spend is the engineering time to design tenant isolation, WOPISrc-aware load balancing, the scaling layer and the runbooks your support staff will follow. Ask any partner for a quote built from a written scope that lists each tenant model, each WOPI host, the target concurrency and the handover deliverables. Separate one-time build work from recurring support, upgrades and subscription fees so you can compare options fairly.

What does the Collabora pricing page say about Business and Enterprise plans per user?

According to the Collabora Online pricing page, the Business plan costs 3 euros per user per month for up to 99 users. It 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. It adds integration support, customization services and roadmap input. Check the Collabora Online pricing page for current terms, because the figures there are the reference for your own calculation. Confirm with Collabora whether a hosted provider's end users count as per-user seats under your contract, since that changes the total cost.

Can our own team run a multi-tenant Collabora Online service without outside help?

Yes, many teams do, provided they have Kubernetes or Linux operations skills, a clear plan for tenant separation and someone who owns security patching. The official Helm chart documentation says horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replica counts are set manually. Your team must also route traffic by the WOPISrc parameter so all users editing one document reach the same pod. Assess the skills you have today against those tasks. An outside partner can build the initial design and runbooks, then hand them over, or you can keep a retainer for upgrades and testing.

How long does a hosting provider rollout take, and what sets the timeline?

No fixed duration applies to every provider, so treat any single number with caution. The timeline depends on how many WOPI hosts you connect, whether you need a separate scaling layer on Kubernetes or can start with fixed replicas, how many tenants must be isolated and how much testing your customers require before go-live. Ask for a schedule with milestones for design, a pilot tenant, load testing, security review and handover. Fixed-scope engagements agree the timeline in writing before work starts, so the schedule should appear in the signed scope.

What does the work need from our platform and operations team?

Your team typically needs to provide cloud or data center access, DNS and TLS certificates, the ingress layer you already run, identity and tenant metadata, and named owners for change approval. They also need to supply the file sharing or groupware platforms that will act as WOPI hosts, along with test accounts and representative documents. Expect your team to review the design, run acceptance tests and own the on-call rota after handover. Agree these responsibilities in the scope, so delays on your side are visible and do not appear as vendor slippage.

How are support handoffs and partner subscriptions arranged for a hosted service?

Define three things before signing: who answers first-line tenant tickets, who handles Collabora server defects and who pays for the Collabora subscription used by the service. Collabora's Business and Enterprise plans include support and security updates, so decide whether your subscription is held by you or by a partner and how end-user seats are reported. Write the escalation path, response expectations from each party and the handover checklist into the contract. For a Collabora-supported setup, confirm with Collabora how partner-held subscriptions are documented before you rely on them.

What security and patching obligations come with running editing for other customers?

You become responsible for patching the service and for showing that tenants are isolated. Collabora publishes security advisories for Collabora Online, and its 25.04 release notes record a fix released on January 29, 2026 for CVE-2026-23623 along with updated package signing keys for RPM and DEB users. Plan a patch process that tracks those advisories, tests each release, and records when fixes reached each environment. Also restrict WOPI requests to the Collabora server addresses, as the Nextcloud administration manual recommends, and use HTTPS for the Collabora URL.

Splitting support between the provider, the vendor and DeployOpen

Write the support split down before the first tenant goes live. In a hosted Collabora Online service, four parties can receive a ticket: the tenant (who reports that a document will not open or that editing is missing), the provider's operations team (who owns the loolwsd hosts, the load balancer, TLS certificates, the WOPI allow list and the storage that the file host reaches), the Collabora subscription channel (who handles product defects, long term support branches and security fixes), and DeployOpen if you have retained it for implementation and ongoing work. A common failure is a tenant report that bounces between the first two parties because nobody checked whether the problem sat in the WOPI host configuration on the file platform side or in the editing server. Assign a first responder for each tier and agree which evidence (tenant ID, document WOPISrc, timestamps, loolwsd logs) must accompany each escalation.

The partner agreement should state who patches what and on what schedule. Cover the Collabora Online version you will run, the branch you commit to (for example, whether you stay on a long term support branch or follow the newest release), who applies point releases, how quickly security advisories are triaged, and who signs off a change to the WOPI allow list or proof key settings. Set out what the tenant may and may not change. Name the escalation path to the Collabora subscription and to DeployOpen, with response targets only where they appear in a written contract. Before signing, confirm with Collabora exactly what the Business or Enterprise terms cover for a hosting provider reselling the service, including whether support, the service level agreement and signed security updates apply to each tenant, to the provider as the contracting party, or to both, and whether redistribution rights and per-user counts across tenants are permitted. Ask the same questions about any terms under the Collabora Online pricing page before you build billing on them.

Retained support from DeployOpen fits the second and third tiers: upgrade rehearsals, configuration reviews after advisories, sizing changes and incident analysis, scoped in writing. Keep the handoff notes in a runbook the provider owns, so a change in either partner does not leave the service without someone who knows the topology. Revisit the split whenever a tenant count, branch or node layout changes, because the answers to who patches and who signs off will change with them.

What to ask a partner before committing to a hosted editing service

How do you prove tenants cannot reach each other's documents?

Ask for a written description of how each tenant's documents, sessions and WOPI traffic are separated, and for the test evidence behind it. A capable partner should show how the WOPI host allow list, the Nextcloud or other host configuration, and the Collabora Online deployment keep one customer's files and editing sessions away from another's. Ask which tenants share a Collabora Online server, whether any shared component holds cached document data, and how that is cleared. Request a sample of the isolation test cases and the results from your own environment before signing. The Nextcloud administration manual recommends restricting WOPI requests to the Collabora server IP addresses, so ask how that restriction is applied per tenant.

Can you show WOPISrc routing working under load?

The first sentence to ask for is a routing test that proves every user editing one document reaches the same pod. The official Collabora Online Helm chart README says horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, and that load balancers must route by the WOPISrc parameter. Ask the partner to demonstrate two users opening the same file through separate browsers and landing on one backend, then to repeat the test after a pod restart and after a node drain. Ask which ingress controller they use (Nginx, HAProxy or OpenShift Router are supported by the chart) and how sticky routing is configured and monitored.

What does the scaling runbook cover when we add capacity?

Ask for a written runbook that covers adding and removing replicas, how documents in progress are handled, and who approves the change. Because replicas are set manually in the Helm chart, the runbook should state the replica change steps, the monitoring thresholds that trigger them, and the rollback steps. Ask how the partner sizes a pod against concurrency rather than user count, and which resource requests and limits they apply. The chart README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Ask what changes when the COOL Controller is used for larger deployments.

How quickly do you apply Collabora security advisories to our service?

Ask for the patch window, the notification process and the test step that comes before production rollout. Collabora publishes security advisories, and 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. Ask how the partner tracks new point releases, whether they test them on a staging tenant first, and how they confirm the signing keys match the vendor's published keys. Ask who decides on an emergency patch outside the normal window and what notice you receive. Confirm the agreed timing in the written scope, since no fixed window is implied by the vendor's release cadence alone.

What data processing terms apply to our customers' documents?

Ask for a data processing agreement that meets the requirements of Article 28(3) of the GDPR, if personal data is involved. Under that article, processor contracts must bind the processor to process only on documented instructions, including on transfers, and to take the security measures required by Article 32. Ask where documents and logs are stored, which subprocessors touch them, how long temporary files and backups are kept, and how deletion is evidenced for a tenant. If your service falls within NIS2 as a managed service provider or cloud provider, ask how the partner's controls map to Commission Implementing Regulation (EU) 2024/2690. Have counsel review the terms.

How do customers switch away from our hosted service?

Ask for a documented exit plan covering export of documents, configuration and tenant mappings, and a tested path to another provider or to on-premises infrastructure. The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025 and requires data processing service providers to let customers switch to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, providers may not impose switching charges. Ask the partner to confirm how they handle these obligations in their contract and what exit work is priced separately.

Who pays for the Collabora Online subscription, and what does it include?

Ask whether the partner runs the free CODE edition or a Collabora subscription, because production use is not what CODE is intended for. Collabora describes CODE as suited to testing, home use or small teams and not recommended for production. The published 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, according to Collabora's pricing page. Enterprise pricing for 100 or more users is quoted with volume discounts. Ask who holds the subscription, how it is billed to your tenants, and whether it is passed through or bundled into your service fee.

Which support tasks stay with us and which go to the partner?

Ask for a responsibility matrix that lists who handles tenant onboarding, incidents, patching, scaling, backups and customer-facing support, with response paths between your teams. A clear split prevents gaps during handoffs. Ask how the partner escalates to Collabora when a fault appears in the editing engine, and whether that escalation is included in your subscription. Ask how a support handoff to your own staff works, including runbooks, access rights and the documentation you will own at exit. Confirm the response times in the written scope rather than assuming them.

How DeployOpen scopes and supports Collabora Online for hosting providers

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For hosting providers and managed service providers, we start from how your tenants, WOPI hosts and support teams will work together, then build and hand over a Collabora Online service you operate.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
We map tenants, WOPI hosts, expected concurrency per tenant and the cloud or data center footprint you control.
The written scope names who operates the Collabora Online servers, the COOL Controller and the routing layer after go-live.

How we build

We configure multi-tenant WOPI setups with allow lists, TLS and tenant-level permissions for each hosted file platform.
We design WOPISrc-aware load balancing and replica counts with the COOL Controller where Kubernetes is the chosen runtime.
We test document fidelity, editing sessions and failover against your own sample files and tenant configurations before rollout.

How we hand over

You receive architecture diagrams, configuration records, runbooks for tenant onboarding and patch procedures for your operators.
Support handoff includes escalation paths between your service desk, your platform team and DeployOpen, defined in the scope.
We walk your operations and support staff through monitoring, common failure modes and the upgrade steps for each release branch.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped to your tenant count and release policy.
Retainers can cover patching against Collabora security advisories and checks after each new branch or point release.
Ask any provider to confirm which subscription tier, support terms and update channel your customers depend on before committing.

Collabora Online for hosting providers and managed service providers