Embedding Collabora Online in a SaaS product

Embedding Collabora Online in a SaaS product: why the WOPI host is your work

A SaaS team that wants document editing inside its own product should treat Collabora Online as the editing component, not the product's document platform. Collabora Online renders and edits documents in the browser through the WOPI protocol, but the integrating application keeps responsibility for document storage, user authentication and the WOPI host that answers Collabora's requests. The Collabora FAQ states this split directly, and it sets the scope of the work before any code is written. The team builds and operates the endpoints that serve file contents, check who may open or save a file, issue and validate access tokens, and record what happened to each document.

For product, the decision is what the editing experience promises to users: which file types open, whether users see view-only or edit rights, how branding appears, and how licensing maps to your customers. Each of those choices lands in your WOPI host code and in the permissions your application grants per request, not in a Collabora setting. For security, the WOPI host becomes part of your attack surface, so token lifetimes, permission checks on every file request and the list of hosts allowed to call your endpoints need review by your own security team. Confirm with Collabora which hardening options apply to your version before you rely on them. For operations, you own upgrades of both your host and the Collabora servers, monitoring of the connection between them, and the support path when a customer's document fails to open.

Which SaaS requirements shape the embedding build

This table maps the vendor and regulatory requirements that apply when Collabora Online is embedded in a SaaS product to the build decisions they force. Read each row as a question to settle before design starts, since most of them change the WOPI host, the network layout or the licensing model. The main takeaway is that storage, authentication and routing are your responsibility, not the editor's.

Requirement	What it means for the build	What to confirm
WOPI host responsibility	Your application stores documents, authenticates users and issues access for each session, because Collabora Online is a component integrated through WOPI.	Which service owns file storage, versioning and per-user authorization in your architecture
WOPISrc-aware routing	Load balancers must send every session for one document to the same pod, since horizontal autoscaling is disabled and replicas are set manually.	How your ingress hashes on the WOPISrc parameter and how tenants are spread across pods
Restricting WOPI requests	Limit WOPI traffic to the Collabora server addresses so your host does not accept calls from arbitrary sources.	Whether your firewall or ingress rules list the editor egress addresses for each region
HTTPS for the server URL	Use the same protocol for the Collabora server URL as for your application, preferably HTTPS, so browsers and the WOPI exchange work without mixed content.	Certificate management for each customer domain or subdomain
Group-level edit permissions	Your product must separate view and edit rights per user or group, since the host decides who can open the editor and who can change content.	How your permission model maps to view, edit and read-only modes in each session
MPL-2.0 licensing	The server code is under MPL-2.0, so you can run and modify it, but you must follow its file-level source obligations for any changed files you distribute.	Legal review of your distribution model, including hosted use and any patches you keep private
Business plan terms	Per-user pricing at 3 euros per user per month for up to 99 users includes long term support, an SLA, signed security updates and portal access, per the Collabora pricing page.	Whether your per-user model and tenant counts fit the plan, and what the SLA covers
Enterprise plan terms	For 100 or more users, volume pricing applies and the plan adds integration support, customization services and roadmap input, per the Collabora pricing page.	Written quote covering integration support scope, custom work and response commitments

Components to design: host, tokens, permissions and branding

Embedding Collabora Online means your application becomes the WOPI host that Collabora Online calls back into. The cards below cover the decisions your team must settle before writing code, because each one shapes how documents are stored, who can open them, and what your customers see. Work through them in order, since token design and permission mapping depend on the file endpoints you build first.

WOPI host and file endpoints

Your application must answer the WOPI requests Collabora Online sends: reading file metadata, streaming file contents, and saving changes back. Decide which of your services owns these endpoints, how large files are streamed rather than buffered, and how versions are written. Lock handling is equally important: you must accept lock, unlock, refresh and get-lock calls consistently, or two users can overwrite each other's edits. Test lock behaviour with concurrent sessions before anything else is built on top of it.

Access token design and lifetimes

Every editing session is opened with an access token that your host issues and validates. Decide what each token encodes (user, file, permissions, tenant), how long it lives, and how it is renewed for long editing sessions. Short lifetimes limit exposure if a token leaks, but expiry during an open session must degrade cleanly rather than lose work. Confirm with your security team whether tokens are single-file, single-session, or reusable, and document the rule so your audit evidence matches the code.

Permission mapping to view and edit

Map your application roles to what WOPI calls read-only and editable access, and decide where that mapping lives. Customers often expect a viewer role to never reach the editor, so the host must make the decision on every request, not only when the document opens. Also decide how sharing links, revoked users and archived documents behave while a session is already open. Write the mapping as a table your product and support teams can both check.

Discovery and allow lists

Collabora Online publishes discovery information that tells your host which file types and actions it supports, and your host should only accept requests from the Collabora servers you operate. Decide how the Collabora URL is configured per environment and per tenant, and whose IP addresses or network paths are allowed to call your endpoints. Keep the protocol consistent across both sides, preferably HTTPS. Revisit the allow list whenever you add a Collabora node or change load balancer addresses.

Branding and UI options

Decide which interface elements your customers can change, such as logos, colours, and which toolbar or menu options are exposed in the embedded editor. Branding requirements often conflict with licence terms and with upgrade paths, so check what the chosen edition permits before promising white-labelling to customers. Keep branding configuration in your own settings store rather than in per-customer forks of the editor, so one upgrade serves every tenant.

Per-user licensing data

Collabora's commercial plans are priced per user per month, so your application must record which users opened the editor, when, and under which tenant. Decide what counts as an active editing user, how you report it to the vendor, and how you reconcile your counts with the licence you buy. The Business plan is listed at 3 euros per user per month for up to 99 users, so usage data determines the bill. Confirm the counting rules in writing before launch, because disputes often start with unclear definitions.

How a document session flows from your app to the editor

This sequence shows how your application stays in charge of who opens which file and with what rights, while the Collabora server handles only the editing session. Each step has a clear output, so your team can test and verify the flow before any customer touches it.

Confirm the user is authorized in your app
Your SaaS product authenticates the user and checks that they may open the requested document, using your own session and access model. Collabora Online does not handle sign-in or storage, so this decision stays entirely in your application. The step is done when your backend has a yes or no answer tied to a specific file and user, and a denial returns without contacting the editor.
Issue a token bound to the file and permission
Your backend creates an access token for that user, scoped to one file and one permission level, such as view or edit, and sets an expiry. Your WOPI host serves the file metadata and content endpoints that the editor will call, so the token must be valid for those routes only. The output is a token your team can decode in a test environment to confirm the file ID, user and permission match the request.
Build the editor URL and launch the session
Your application asks the Collabora server for the editor entry point for the file's type, then builds a URL that carries a WOPISrc parameter pointing back to your WOPI host. The browser opens an auto-submitting form or frame that sends the access token to the editor. This is also where a multi-server setup must route every request for the same WOPISrc to the same Collabora pod, which is why load balancing has to respect that parameter. Done when the editor frame opens with the correct document title.
Load the document from your WOPI host
The Collabora server calls back to your WOPI host with the token to request file information, then fetches the document contents. Your host checks the token on each call and returns the file only if the token is valid and unexpired. Your storage system remains the source of truth, and Collabora Online does not keep a permanent copy. You know this step worked when the document renders in the browser and your logs show the callback with the expected file ID.
Return edits and saves to your host
As the user types or changes cells and slides, the editor sends changes through its session and saves back to your WOPI host through the PutFile or related calls. Your host validates each write against the token's permission, so a view-only token must be refused on write. Confirm this by testing a read-only token and checking that writes are rejected and logged.
Close the session and revoke access
When the user closes the editor, the session ends and no further calls should succeed with that token. Your application should expire tokens after a defined period and handle sharing changes by refusing new tokens for users who lost access. Ask your team to confirm the exact lifetime and revocation behavior against the version you deploy, since these settings depend on your implementation. The step is complete when a closed or revoked session cannot read or write the file.
Keep audit and monitoring at the SaaS boundary
Record token issuance, file access, save events and denials in your own logs, keyed by tenant, user and file. Your monitoring should also track callback errors between the editor and your host, because a failing host shows up to users as a broken editor. Review these logs against your compliance obligations, such as the processor duties under GDPR Article 28(3) if you hold personal data. The output is a log trail that shows who opened what, with which right, and when.

Running Collabora Online for many customers without mixing their documents

The core decision for a multi-customer deployment is whether tenants share a Collabora Online pool or each receive a dedicated pool. A shared pool lowers the number of servers you run and simplifies capacity planning, but every tenant's editing sessions compete for the same CPU and memory, and one heavy customer can slow the others. A dedicated pool per tenant or per tenant tier isolates performance and failure domains, at the cost of more pods to size, patch and monitor. Your choice also determines how you route WOPI traffic. In your WOPI host, the WOPISrc value identifies the document, and the load balancer must send every request for that document to the same pod. Confirm that your ingress (Nginx, HAProxy or the OpenShift Router, as the Helm chart supports) can route on that parameter in both pool models, and test it with two users editing one file from different networks.

Sizing starts from the per-pod resource figures in the official Helm chart README, which 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 point for a single pod, not a capacity figure for your customers. Count concurrent editing sessions per tenant, the document sizes and the formats they use, then load test with representative files before you commit to a pod count per pool. Replica counts are set manually. The same README states that horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so a traffic spike does not add capacity automatically. Plan headroom for peaks, and scale pools by changing the replica setting during a planned window.

Before you rely on a shared or dedicated design for paying customers, confirm the multi-tenant terms with Collabora. Ask whether its licensing and support cover your hosting model and how it counts users across tenants, and read the current Collabora Online pricing page alongside the written answer. Ask which security advisories apply to your version and how fixes reach your pools on a schedule your customers can accept. Ask your own team to write down the isolation guarantees you offer, then verify them: document access must be checked by your WOPI host before a token is issued, and logs must show which tenant each session belongs to. Those checks belong in your test plan before the first customer goes live.

How per-user licensing changes the cost model

The CODE edition is the free build of Collabora Online, distributed as a rolling release that Collabora describes as suited to testing, home use or small teams and not recommended for production. Its licensing cost is zero, but the cost moves into your team's time: you own upgrades, security response and any incident that reaches your customers. For a SaaS product, CODE is best treated as a prototyping and integration-testing target rather than the editor you sell.

Release cadence: CODE ships on average once a month, so each upgrade is a rolling change you must test against your WOPI host.
Support: No vendor SLA or long term support is included, so your on-call rota covers editor failures.
Security patches: You track advisories and apply fixes yourself, without signed update commitments from the vendor.
Customer contracts: Check whether your own customer terms allow you to rely on an unsupported editor build.

Before you ask for a quote, confirm with Collabora in writing whether the CODE terms cover your planned production use and what changes when you move to a paid tier.

Questions SaaS teams ask before embedding Collabora Online

How much effort does building a WOPI host take, and what drives it?

The effort depends mostly on how much your application already does: storage access, user identity, and permission checks. Collabora Online is a component integrated into a web application through WOPI, and document storage and authentication stay with your product. Your WOPI host must answer file info and file content requests, handle write-back, issue and validate access tokens, and map each user's rights to read-only or edit. Effort rises with the number of storage backends, the complexity of your permission model, versioning and locking rules, and how much branding and per-tenant configuration you need. Ask any partner to split the quote into WOPI host work, deployment work and testing work.

Can our team build the WOPI integration alone?

Often yes, if you have engineers who know your storage layer and authentication well and can read the WOPI interface closely. The hard parts are rarely the endpoints themselves. They are token lifetimes, permission edge cases, concurrent editing, and failure handling when a document is locked or storage is slow. Collabora Online also needs routing rules that keep all users of one document on the same server, so someone on your team must own the deployment. A fixed-scope engagement with DeployOpen covers the parts you choose to outsource, and the written scope shows what your engineers keep.

How long does it take to reach a first working editor?

No duration is fixed in advance because it depends on your storage model, your identity setup and the environment Collabora Online will run in. A first working editor usually means one test deployment, a WOPI host that opens and saves a document, and a permission check for one role. Confirm with any partner which milestones they commit to in writing, and which depend on your access to test accounts, networks and environments. Plan separately for hardening, file format testing and multi-customer rollout, since those extend the timeline after the first editor works.

What do our engineers and product owners need to provide?

Engineers need access to the storage layer, a test environment that can reach the Collabora Online server, and time to review token and permission design. Product owners need to decide which document types, roles and actions (view, edit, comment, export) each customer can use, and how branding should appear. Both groups should agree early on the document formats that matter, because format fidelity is tested against those files. Expect ongoing input from both during testing, since most problems surface when real customer documents are opened.

How does licensing scale when our product has many users?

Licensing depends on the Collabora Online plan you choose and how many users access editing. The Collabora Online pricing page lists the Business plan at 3 euros per user per month for up to 99 users, including 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. Ask your vendor how a multi-tenant product should count users, whether the count is per customer or per installation, and what terms apply to your resale model. Confirm these terms in writing before you price your own offering.

Is CODE suitable for running a production SaaS product?

No. The CODE page describes Collabora Online Development Edition as suited to testing, home use or small teams, and states it is not recommended for production. CODE is a rolling release, published on average once a month, so its update cadence differs from a supported branch. Use CODE for prototyping your WOPI host and testing integration. For production, plan a supported subscription, check the long term support and security update terms, and confirm the monitoring and patch process you will follow for your customers.

How are upgrades handled for a multi-customer deployment?

Upgrades follow Collabora Online's release branches. For example, the 25.04 branch received point releases into 2026, with 25.04.13 released on September 21, 2026, and the release notes record security fixes such as CVE-2026-23623 in 25.04.7.5. Your plan should cover how quickly you apply point releases, how you test them against your WOPI host and file samples, and how you roll them out across customer environments. Major branch moves need a separate test cycle. Agree on the upgrade responsibilities with your partner or internal team in writing, including who watches the release notes and who signs off each rollout.

Compliance questions a SaaS embedding raises

Embedding Collabora Online makes your product a host in a document editing chain, so regulators and auditors will ask who holds which duty. The cards below separate the questions that depend on your role, your audit scope and your own product obligations. DeployOpen prepares systems, controls and evidence for these reviews, but independent auditors and certification bodies issue any report, attestation or certificate.

GDPR processor duties

Whether your SaaS is a controller or a processor for the documents customers edit, the contracts must bind every party to process personal data only on documented instructions, including for transfers, and to apply the security measures Article 32 requires. Confirm where the Collabora server runs, which logs record document identifiers and user names, and whether any AI assistant features send document content to an external provider. Map each of these to a sub-processor entry in your data processing agreement.

SOC 2 scope for the editing path

A SOC 2 examination covers the system you describe, so the editing path must be inside or explicitly carved out of that description. The path runs from your WOPI host through the token issuer, the Collabora server and back to document storage. Auditors will test access reviews, change management for the Collabora version, and logging for document sessions. Decide early whether Collabora is a subservice organization, and confirm with your auditor how its controls are evidenced.

ISO 27001 controls for the host

ISO/IEC 27001:2022 Annex A groups its 93 controls into organizational, people, physical and technological themes. For an embedded editor, the technological controls on access restriction, secure configuration, logging and vulnerability management apply to the Collabora servers you operate. Map each control to a named owner and a piece of evidence, such as a configuration baseline or a patching record. Accredited certification bodies, not ISO, decide whether your organization is certified.

NIS2 and Cyber Resilience Act duties

If your SaaS falls within NIS2 as a cloud or managed service provider, the Implementing Regulation (EU) 2024/2690 sets technical measures you must document. Separately, if you ship your product in the EU, the Cyber Resilience Act places obligations on software providers, including vulnerability handling and reporting. Treat the Collabora Online version you embed as a component you must track, patch and report on. Confirm with counsel which regime applies to your product and to your hosting.

Data Act switching duties

The EU Data Act 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. For an embedded editor, this means documents, metadata and document-to-user mappings must be exportable in open formats, and the editing function must be replaceable without losing customer data. Ask who controls the export tooling, and test a full export before you need it.

Rollout from a prototype to multi-customer production

This sequence moves a document editing feature from a single-tenant prototype to a multi-customer service, with each stage gated by a written check. The result is a production deployment whose permissions, endpoints and capacity have been tested before customers depend on it.

Define scope and the permission model
Your product team and DeployOpen agree which document types, editing modes and roles are in scope, and map each role to what a user may view, edit or export. The integrating product remains responsible for document storage and authentication, so this step also records where those decisions live in your application. Fixed-scope work is agreed in writing before any build starts, and the signed scope document is the output that closes this step.
Build the host prototype against a test server
Engineers implement the WOPI host endpoints in your application and connect them to a Collabora Online test server that is not shared with customers. The prototype covers file retrieval, saving, and access token issuance for a small set of internal test accounts. Completion means a test user can open, edit and save a document of each in-scope type, with every save written back to your storage and logged.
Review tokens and allow lists
A security review examines how access tokens are issued, scoped to one file and one user, expired and revoked, and whether the Collabora server accepts requests only from your WOPI host addresses. Reviewers also check TLS on every endpoint and how the host handles proof keys. The step closes with a written list of findings, each marked fixed, accepted with a reason, or still open before pilot traffic begins.
Run a pilot with a limited customer group
Invite a small group of customers whose documents and usage patterns are known, and keep the group small enough that a problem affects few tenants. Monitor save failures, session errors and document fidelity reports from real files, and collect feedback on the editing experience. The pilot ends when your team has reviewed the error log and agreed with DeployOpen on the changes required for production, recorded in the same written scope.
Size production and set up monitoring
Capacity is planned from observed concurrency during the pilot, not from assumptions about the full customer base. Load balancers must route all requests for one document to the same server by the WOPISrc parameter, and replica counts are set manually because autoscaling is not recommended for collaborative editing. Dashboards and alerts for connection errors, WOPI rejections and save latency are tested with a deliberate fault before go-live.
Expand in stages across customers
Customers are onboarded in waves, with each wave checked against error rates and support tickets before the next opens. Licensing is confirmed with the vendor for the expected user counts, since the Business and Enterprise terms differ by user volume and support level. The expansion is complete when every customer group is live, the runbook for tenant onboarding and offboarding is tested, and the support handoff to your operations team is signed off.

How DeployOpen scopes and delivers a Collabora Online embedding

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a SaaS embedding of Collabora Online, we start from your application's document model, tokens and tenancy, then build and hand over a WOPI host that runs in your cloud accounts or data centers, with the evidence your customers and assessors will ask for.

How we scope

Engagements are fixed-scope, with the WOPI host, token and permission model, and branding agreed in writing before work starts.
The written scope names which document types, editing permissions and tenant boundaries your product must support on day one.
We confirm which licensing model, Collabora edition and support level your customer contracts require before any build begins.

How we build

We implement the WOPI host endpoints, access token issuance and document permission checks against your storage and authentication.
Routing is configured so every session for one document reaches the same Collabora Online instance, with sizing based on your measured concurrency.
Each build step is tested with representative documents in docx, xlsx and pptx, and results are recorded for your sign-off.

How we hand over

You receive architecture notes, configuration as code, runbooks for tenant onboarding and a documented upgrade procedure.
Security settings such as WOPI host allow lists, TLS and access controls are documented so your team can review and audit them.
Knowledge transfer sessions cover operations, troubleshooting and how to plan Collabora Online version upgrades in your environment.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Retainers can cover monitoring, applying point releases such as those Collabora publishes for its supported branches, and re-testing after changes.
Before you sign a support arrangement, confirm with Collabora which subscription tier fits your user counts and service expectations.