Embedding document editing in your own application

Embedding document editing in your own application: when your product is the host

If your product or customer portal needs Office editing inside its own screens, the decision comes down mainly to two options: Collabora Online integrated through the WOPI protocol, or ONLYOFFICE Docs integrated through its API. The licence edition often decides the question before features do, because commercial embedding in a service you sell to customers is treated differently from running an editor for your own staff. Confirm the embedding terms in writing with each vendor before you commit, since the Community and paid editions carry different rights and support.

Treat the host application, the editor and the document server as three separate components. Your host application (the portal, document platform or SaaS product) has its own licence, which may be permissive or copyleft depending on the code you ship. The editor and document server have their own licences: Collabora Online server code is under MPL-2.0, while ONLYOFFICE Docs Community Edition is under AGPL-3.0, and the AGPL obligations apply to the network service you run, so count them in your legal review. Each component also scales differently, so a single load figure for the whole stack will mislead your capacity planning.

Before you write integration code, run a short internal check: list every component that receives document content, which licence governs each one, and whom you would need to notify or supply source to if you distribute changes. Ask the chosen vendor which edition permits embedding for your model, what support and signed security updates that edition includes, and how the WOPI or API connection authenticates the host. The answers determine whether your team builds the connector or buys it, and they set the scaling plan you must size against your peak concurrent editing load.

Requirements a host product must meet before embedding

This table compares the licensing, integration and operational requirements a host product must satisfy before it embeds browser editing. Read each row as a decision point: the build column explains what it means for your architecture, and the confirm column lists what to verify with the vendor or counsel before committing.

Requirement	What it means for the build	What to confirm with the vendor or counsel
WOPI or API integration	Collabora Online integrates through the WOPI protocol, so your host must act as a WOPI host serving file metadata and contents. ONLYOFFICE Docs is reached through its API, so your host calls the document server and serves files to it.	Confirm which host endpoints your version requires, how access tokens are issued and validated, and which WOPI operations your flows need.
Edition that permits commercial embedding	ONLYOFFICE Community Edition is AGPL-3.0 and its Developer Edition is sold under a commercial license for vendors embedding editors in services to customers. Choosing the wrong edition can put your distribution model out of scope.	Ask whether your service model, tenancy and white-labeling needs require the Developer Edition, and get the commercial terms in writing.
AGPL-3.0 obligations for ONLYOFFICE Community or modified server code	If you run the Community server and modify it, or offer it to users over a network, AGPL-3.0 source obligations may apply to your modifications. Unmodified use still carries license terms to review.	Have counsel map which components you modify, how users interact with them over the network, and what source must be published.
MPL-2.0 file-level obligations for Collabora source	The Collabora Online server is MPL-2.0, a file-level copyleft. Changes to MPL-covered files must be made available under MPL-2.0, while your own separate files can stay under other terms.	Ask counsel to confirm how your modifications and integration code are separated, and which files you intend to change.
Support and signed updates for production	Free community builds are not recommended for production by their publishers. A production host needs tested updates, security fixes and a support path, which usually means a paid edition or subscription.	Confirm the support level, update channel, signed-update process and long-term support terms for the exact edition you select.
Sizing for concurrent editing	Editor servers hold editing sessions in memory and CPU, so load depends on simultaneous editors and document complexity. Collabora does not support autoscaling for collaborative sessions, so capacity is set by hand and routing must keep each document on one server.	Ask the vendor for per-server concurrency figures, recommended resource limits and the routing method for your load balancer, then test against your own documents.
Session routing and document affinity	All users editing one document must reach the same editor instance. Without affinity, collaborative editing and copy and paste can break across instances.	Confirm the routing key your architecture uses, such as the WOPISrc parameter for Collabora, and test it under failover.
Identity and access control	Your host decides who may view or edit each file and issues the tokens the editor relies on. Permissions must be enforced in your application, not only in the browser.	Ask how tokens expire, how revocation works, and how edit versus view rights are passed to the editor.

Collabora Online through WOPI or ONLYOFFICE Docs through its API

Collabora Online is a collaborative office suite built on LibreOffice technology, and it reaches your application through the WOPI protocol. Your product acts as the WOPI host: it stores the file, answers the editor's requests for file info and contents, and decides who may read or write each document. Collabora's server then renders the editing interface in the browser, and your application embeds that interface in a frame. Collabora lists existing WOPI integrations with Nextcloud, ownCloud, Seafile, WordPress, Alfresco, Mattermost, Nuxeo, OpenText and xWiki, among others, so a team building a portal can study a working integration before writing its own.

Host obligations: Your service must implement the WOPI endpoints for file info, file contents and locks, and must check an access token on every request.
Deployment options: Collabora Online can run from Docker images, system packages or on Kubernetes, and the Collabora Online Controller is offered for large deployments.
Free and paid editions: The free CODE edition is described by Collabora as suited to testing, home use or small teams and not recommended for production, while the paid Collabora Online adds tested updates, security fixes and support.
Server code license: The server code is licensed under MPL-2.0, which applies to modifications of Collabora's own files, so review what your build must publish against your counsel's reading of that license.
Routing: Load balancers must route by the WOPISrc parameter so all users editing one document reach the same pod.

Before you commit, confirm the WOPI version and endpoints your target editor expects, and test saves, conflicts and lock expiry with your own templates.

What AGPL and MPL obligations mean for a commercial product

The core question is which code you must share, and when. The Collabora Online server code is licensed under the Mozilla Public License 2.0 (MPL-2.0), a *file-level* copyleft licence: if you modify MPL-covered files and distribute the result, those modified files must stay available under MPL-2.0, but your own separate files, services and product code can generally remain proprietary. ONLYOFFICE Docs Community Edition is licensed under AGPL-3.0, which is a *network* copyleft licence. Its key difference is that offering a modified version to users over a network can trigger the duty to offer the corresponding source to those users, even if you never distribute copies. For a product that puts editing inside a customer-facing portal, that network clause is the one to examine first.

The two licences also apply to different things. Under the AGPL, the scope of the obligation depends on whether your application is a modified version of the document server or a separate program that talks to it over an API, and that boundary is decided by the architecture and the way the components are linked and deployed. Under the MPL, the boundary is drawn around individual files. Write down, for each component, whether you modify it, which files change, how the components communicate and who receives access. Map every modification before you ship, because the source-offer obligation attaches to the modified code, not to the marketing description of the product. ONLYOFFICE also sells Enterprise and Developer editions under proprietary terms, and its Developer Edition is aimed at software vendors that embed the editors in services they provide to customers. Those commercial terms replace the AGPL terms for that build, so the licence you accept determines your obligations, not the open-source name of the product. Have counsel review the exact licence text for the edition and version you plan to use, the specific product architecture and your customer contracts, and record that review in writing before release. This page does not give legal advice on how any licence applies to your product.

Which editor fits a host product and why

Each option below answers a different question: which license lets you ship the editor to customers, which editor handles your file formats, and which edition can carry production load. Start with the license and the support model, then check how the editor attaches to your host product.

Collabora Online for WOPI hosts

Collabora Online is built on LibreOffice technology and attaches to a host platform through the WOPI protocol, so your application acts as the file host and the editor runs beside it. Its server code is licensed under MPL-2.0, which you should review with counsel before shipping modified files. Under the Business plan, pricing is quoted per user per month for up to 99 users, and the Enterprise plan is quoted for 100 or more users. Confirm which plan includes the signed security updates your customers will require.

ONLYOFFICE Docs Community Edition

The Community Edition is licensed under AGPL-3.0 and handles native .docx, .xlsx and .pptx files. Its README recommends it for teams of up to 20 users, although version 9.4 removed the 20 simultaneous connection limit. AGPL-3.0 network copyleft applies if you modify the document server and offer it to users over a network, so plan your source disclosure obligations before launch. Confirm whether the Community Edition's configuration-file-only administration meets your operations model.

ONLYOFFICE Developer Edition

The Developer Edition is sold under a commercial license for software vendors that embed the editors in services they provide to customers. It is the option to evaluate when AGPL-3.0 obligations would conflict with your distribution model or your customer contracts. The edition comparison lists the Enterprise features separately, so confirm which of them the Developer license includes, such as clustering, the admin panel and white labeling. Ask the vendor for the license terms in writing before design freeze.

CODE for evaluation only

CODE is Collabora's free development edition, released roughly once a month as a rolling build. Collabora describes it as suited to testing, home use or small teams and not recommended for production. Use it to prove the WOPI handshake, fonts and document fidelity against your own templates. Move to the paid Collabora Online edition before customers depend on the integration, since the paid edition adds tested updates, security fixes and support.

Host platforms that already embed editors

Nextcloud and Seafile show the pattern you would copy: the file platform owns identity, storage and sharing, and the editor is connected as a separate service. Collabora lists WOPI integrations with both, and ONLYOFFICE documents integrations with both as well. Use their configuration as a reference for how to route document sessions, pass access tokens and keep the editor on your own network. Confirm each platform's license terms and version compatibility before you adapt its connector.

Sizing document servers for concurrent sessions in a product

Size the document server around the sessions your product will actually run, and plan the routing before you plan the capacity. For Collabora Online, the official Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, so replica counts are set by hand. The chart's README also requires your load balancer to route by the WOPISrc parameter, so every user editing one document reaches the same pod. Your ingress (Nginx, HAProxy or the OpenShift Router, all supported by the chart) must be configured for this before go-live, and your integration tests should include two users opening the same file from different tenants or sessions to confirm they land on one pod.

For per-pod sizing, the chart's README recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Treat these as a starting envelope rather than a target. Each additional pod is an additional replica you manage manually, so your capacity plan should state how many replicas you will run at baseline, how you will add them ahead of predictable peaks such as month-end reporting or a product launch, and who on your team owns that change. Confirm with Collabora how many concurrent editors one pod supports under your document mix, since that figure depends on document size, images, and whether you use the optional AI assistant introduced in 26.04.

For ONLYOFFICE, the planning question is different. Clustering and scaling for thousands of users are Enterprise Edition features, and the Community Edition is configured through config files only, so you cannot rely on the free edition for horizontal growth in a multi-tenant product. Before you choose an edition, ask for the Enterprise scaling architecture in writing and map it to your tenancy model. In every case, measure your own session profile first: peak concurrent sessions per tenant, average document size, editing duration, conversion volume and how often users open many documents at once. Run a load test against a staging stack that mirrors your ingress and WOPI configuration, and size from the measured results, not from vendor figures.

How an embedding rollout moves from proof of concept to release

This sequence takes an embedded editor from a licence decision to a supported production release, with a written output at each gate so that product, security and operations sign off on evidence rather than demos.

Confirm licence and edition with written review
Product leadership and counsel review the editor licence before any code is written. For ONLYOFFICE Docs, the team confirms whether the AGPL-3.0 Community Edition fits its distribution model or whether the commercial Developer Edition, which ONLYOFFICE sells to software vendors that embed the editors in services they provide, is required. For Collabora Online, the team reviews the MPL-2.0 obligations for the server code it modifies and confirms which support tier it will buy. The output is a signed written memo naming the edition, the license obligations, the user counts and the support plan. Do not treat the free CODE build as production software, since Collabora describes it as not recommended for production.
Run an integration spike on one host endpoint
Engineers connect the chosen editor to one host endpoint, typically a single document type in a test tenant of your product. For Collabora Online this means implementing or configuring WOPI host behavior, including file info and file content endpoints and token handling. For ONLYOFFICE Docs it means the API integration and callback handling. The spike should prove that a document opens, edits, saves back to storage and reopens with the change intact. The output is a short demo log and a list of gaps between the product's file model and the editor's requirements, including permissions and versioning.
Test document fidelity on your own templates
The team collects the customer's real templates, contracts, financial models and branded forms, then opens and saves each one through the editor and compares the result with desktop Office. Fonts, tables, tracked changes, headers, macros and embedded objects are checked against a written list. Fonts must be available on the document server, so the team confirms the font set with the vendor and records any missing ones. The output is a fidelity register that marks each template as acceptable, acceptable with a workaround or out of scope, and that the product owner signs.
Size the servers with concurrent sessions and sticky routing
Performance engineers run a load test that simulates expected concurrent editors per document and per server, using realistic document sizes. For Collabora, the test must confirm that the load balancer routes every session for one document to the same pod using the WOPISrc parameter, because the official Helm chart disables autoscaling for this reason and sets replicas manually. The test records CPU and memory per pod against the chart's published production limits, and includes failover behavior. The output is a sizing sheet with replica counts, resource requests and limits, and the routing configuration that passed the test. Ask the vendor to confirm concurrency limits for the edition you bought.
Review WOPI traffic and storage access
The security team reviews how the host, the editor and the storage interact. The review covers which hosts may call the WOPI endpoints, how access tokens are issued, scoped and expired, how file content is protected in transit between the editor and the host, and which service accounts can read and write documents. It also checks audit logging for opens, edits and saves, and confirms that any optional AI feature is disabled unless approved. For systems holding regulated data, this review maps to the control expectations of the relevant framework, such as audit controls under the HIPAA Security Rule where ePHI is involved. The output is a signed threat model with findings tracked to closure.
Deploy to production with signed updates and support
Operations deploys the editor and document server into the production environment, using signed images or packages and a documented update channel. The support agreement for the chosen edition is active before go-live, and the team confirms how security fixes reach them and how they are tested before rollout. Backups of the document server configuration and the storage integration are verified by a restore test. The output is a production environment with a deployment record, a verified restore and a support contact matrix.
Release with a scaling and update runbook
The team hands the service to the operations group with a runbook covering how to add or remove editor replicas, how to apply a patch release, how to roll back, and how to read the health and load metrics that signal the need for more capacity. The runbook names the owner of each action and the escalation path to the vendor. A release review confirms that the runbook was exercised in a staging environment at least once. The output is an approved runbook, a release sign-off from product, security and operations, and a scheduled review of the sizing sheet.

Evidence product teams hand to customers and auditors

This table maps each piece of evidence a product team typically shares with customers or auditors to the component that produces it. Use it to decide which records your platform, host application and document server must generate before a review starts. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any attestation.

Evidence item	Produced by	What to confirm before a review
Architecture and data flow diagram	Your solution design, including host application, WOPI endpoints and document server	Show where document content, editing sessions and temporary conversion files are stored and which hosts can reach the document server
Licence inventory and edition record	Package manifests of the host platform, the ONLYOFFICE Docs or Collabora Online build, and fonts	Confirm the licence of each component (ONLYOFFICE Docs Community Edition is AGPL-3.0, Collabora Online server code is MPL-2.0) and whether your use needs a commercial edition
WOPI access control configuration	Host application and reverse proxy settings for allowed WOPI hosts, token lifetimes and TLS	Confirm which hosts may call the WOPI endpoints, how access tokens expire and how edit rights differ from view rights per user group
Audit logs from the host and document server	Host application access logs, document server logs and proxy logs	Confirm logs record who opened, edited, downloaded or converted a document and that they are retained and protected from change
Sizing test results	Load tests run against your own document sizes and concurrency targets	Confirm the test used realistic concurrent editing, measured CPU and memory per server and recorded the routing rule that keeps one document on one node
Update and patch records	Change tickets, image digests and release notes for each ONLYOFFICE or Collabora update applied	Confirm each update was tested in a staging copy, the version applied is recorded and security releases are tracked against a date
Support agreements	The vendor or partner contract for the chosen edition and support plan	Confirm the support level, response expectations and who receives signed security updates for the exact edition you run

Questions product teams ask before embedding an office editor

What does it cost to embed an office editor in our product?

The cost has four parts: the editor licence, the document server hardware or cloud capacity, the integration work in your application, and support. Collabora's published Business plan is 3 euros per user per month for up to 99 users, and its Enterprise plan for 100 or more users is quoted with volume discounts (per the Collabora Online pricing page). ONLYOFFICE prices its Developer Edition on request for vendors that embed the editors in services they provide to customers. The licence recurs per user or per tenant, while integration is mostly one-time. Ask every vendor for a quote that separates licence, server sizing assumptions, integration scope, and the support tier that includes signed security updates.

How long does an editor integration take?

The duration depends on how many host platforms you connect, how much of the editing experience you expose, and how your authentication and file permissions map to the editor. A single integration into a platform that already speaks WOPI is usually shorter than a custom integration against an API, because the file-handling contract is already defined. Timelines should be written into a fixed scope with named deliverables, not estimated from a general rule. Ask your partner which tests they will run on your own templates and documents, because format fidelity testing often sets the schedule.

What does our internal team need to provide during integration?

Your team needs an owner for the host application, someone who can change its file storage and permission logic, and an operations contact for the servers that will run the document server and editor. You will also need a decision on hosting location, TLS certificates, the internal DNS names the editor will call back on, and how user sessions are passed to the editor. For Collabora, your load balancer must route all editors of one document to the same pod by the WOPISrc parameter, so your network team should be involved early. Confirm these responsibilities in the written scope.

Can our engineers build the integration in-house?

Yes, if your team already runs containers, reverse proxies and identity integration, and has engineers who can maintain a WOPI or API integration over several releases. The harder part is operating the document server: sizing it for concurrent editing, applying updates, handling fonts and formats, and keeping evidence for your customers' security reviews. Many teams split the work, building the host-side file logic themselves and bringing in a partner for server hardening, testing and the ongoing update path. A partner can cover that work under a fixed scope, and retainers are available for upgrades and continuous support.

Which edition do we need for commercial embedding?

The answer depends on the editor and on how you deliver the product. ONLYOFFICE's Community Edition is AGPL-3.0 licensed, but its edition comparison describes Community support and configuration through files only, while ONLYOFFICE sells a Developer Edition under a commercial license for software vendors that embed the editors in services they provide to customers. Collabora Online's server code is MPL-2.0, and its free CODE edition is described by Collabora as not recommended for production, while the paid edition adds tested updates, security fixes and support. Have counsel confirm how your distribution model maps to each licence before you commit.

How do AGPL obligations change if we modify the document server?

AGPL-3.0 is a copyleft licence with a network clause: if you modify the program and users interact with it over a network, you generally must offer those users the corresponding source of your modifications. ONLYOFFICE Docs is AGPL-3.0, so any change to the server code you make and expose to users triggers that obligation, while separate code that talks to it through its API is a question for your counsel. Collabora Online's MPL-2.0 is a file-level copyleft licence, which generally applies to modified files rather than the whole product. Record every patch you apply, keep it in version control, and get a licence review before shipping modifications to customers.

How many servers will concurrent editing need?

Concurrency, document size, and the number of simultaneous co-authors drive server load, so the right number comes from a load test against your own documents. ONLYOFFICE Docs 9.4 removed the 20 simultaneous connection limit from the Community Edition, but clustering and scaling for thousands of users are Enterprise features. Collabora's Helm chart disables autoscaling because scaling breaks collaborative editing, sets replicas manually, and recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Ask your partner for the load test plan and the sizing assumptions in the quote.

What ongoing support and security updates should we expect?

Plan for recurring work: applying security updates, testing new releases against your integration, renewing licences, and monitoring the document server. Collabora's Business plan includes long term support, a service level agreement, signed security updates and customer portal access, while ONLYOFFICE's Enterprise support tiers are Basic, Plus or Premium. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope with terms agreed in writing before work starts. Ask each vendor and partner what they will patch, how fast, and who answers when an update breaks your integration.

What to ask an implementation partner before embedding

Start with the licence review, because it decides what you are allowed to ship. Ask the partner to write down which component carries which licence in your architecture: AGPL-3.0 for ONLYOFFICE Docs Community Edition, MPL-2.0 for the Collabora Online server code, and whether your use requires the ONLYOFFICE Developer Edition under its commercial licence for software vendors that embed the editors in services for customers. Ask who signs off that conclusion and whether it is reviewed by your counsel. Then ask which edition they recommend and why, and what user count and concurrency assumption that recommendation rests on. A partner who cannot tie the edition to your licence position and your support needs is not ready to scope the work.

Next, ask how the integration is tested and how the routing is configured. For Collabora, ask how the WOPI host implementation is verified against your portal, how access tokens and the WOPISrc parameter are handled, and how the load balancer keeps every editor of one document on the same pod. The official Collabora Online Helm chart README notes that horizontal pod autoscaling is disabled because scaling breaks collaborative editing, so ask how replicas are set and changed. For ONLYOFFICE Docs, ask how the API integration verifies document keys and callbacks. Ask how concurrent sessions are measured in a test, which tool generates the load, and what result they will hand over in writing. Ask how fidelity is tested on your own templates, including fonts, tables, tracked changes and any Office Open XML features your customers depend on.

Finally, ask how signed updates are applied and whether they will support modified server code. Ask whether the partner will apply vendor security updates to a staging copy first, how they verify signatures, and how long a rollback takes. If you plan to modify the document server, the AGPL-3.0 obligations in ONLYOFFICE Docs Community Edition may require you to offer the source of your modified version to users who interact with it over a network, so ask the partner to explain how they track modifications, publish source, and document the boundary between your code and the vendor code. Confirm the support model in writing, including who responds to a security advisory and within what window, since DeployOpen does not publish service levels and any commitment must come from the signed scope.

How DeployOpen scopes and supports an embedded editor build

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For an embedded editor, that means agreeing the editor edition, the host integration and the document server sizing in writing before any build work starts, then handing over a system your own team can run.

How we scope

Confirm the host application, its WOPI or API integration path, and which document formats must round-trip.
Record the editor edition decision, including whether the license terms and vendor support fit your distribution model.
Agree in writing the sizing inputs: concurrent editors, peak patterns, hosting targets and the separation of document servers by environment.

How we build

Deploy the document server and connector in your cloud account, data center or air-gapped network, using your own certificates and hosts.
Configure WOPI host trust, sticky routing by document and the ingress controls that keep editing traffic on approved endpoints.
Test fidelity on your own templates and fonts, and verify concurrent editing, copy and paste, and version handling before sign-off.

How we hand over

Document the architecture, configuration keys, update procedure and the license and AGPL-3.0 or MPL-2.0 obligations that apply to your build.
Provide runbooks for backup, restore, scaling of editor pods and rotation of WOPI secrets, tailored to your environment.
Deliver compliance-ready evidence such as configuration records, access logs and test results for your own auditors to review.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
Ask any implementation partner to confirm how vendor support tiers, signed updates and your own support contract fit together.

Embedding document editing in your own application