Architecture · Documents
Two document engines,
one integration layer.
Office Unbound is designed to work with either Collabora Online or ONLYOFFICE Docs as its browser editor. One layer sits between the platform and the engine, so the rest of Office Unbound does not depend on which one a deployment selects.
Project status Phase 1 design. The abstraction layer is planned and both engines are under evaluation; nothing on this page has been built or tested.
Why two engines
Their strengths differ, and so do their editions and license terms. Different operators will need different ones.
Collabora Online and ONLYOFFICE Docs are both mature browser editors for documents, spreadsheets and presentations, and both are used with file platforms such as Nextcloud. They are not interchangeable underneath. Collabora Online is built on the LibreOffice core. OpenDocument (ODF) is its native format, and it handles Office files through LibreOffice’s import and export filters. ONLYOFFICE Docs works natively in Office Open XML (DOCX, XLSX, PPTX) and edits ODF files through internal conversion.
The editions differ at least as much. Which edition supports mobile web editing, clustering, multi-tenancy, own branding or commercial support is not the same for the two vendors. Their open-source licenses (MPL-2.0 for Collabora, AGPL-3.0 with additional terms for ONLYOFFICE) also place different obligations on someone who modifies or redistributes them. A business self-hosting for forty people, an MSP hosting two hundred customers and an organization with mostly ODF archives will weigh these differently.
Supporting both through one layer has two further purposes. A deployment is less exposed to one vendor’s licensing decisions; these do change, as ONLYOFFICE’s removal of its Community Edition connection limit in version 9.4.0 showed. That is an option to change, not a free exit: a switch is a controlled cutover with format and feature trade-offs, described below. And the parts of the platform that matter most to users, such as where files live, who may open them and what counts as a version, stay in Office Unbound rather than in the engine.
- Concept An idea or design direction; not yet committed to the roadmap
- Under evaluation Being assessed; no choice made yet
- Planned Committed to the roadmap; work not started
- In development Being worked on now
- Implemented Code exists in a public repository
- Tested Passed published tests
- Production-ready Shipped in a supported release
| Capability | What it means | Status |
|---|---|---|
| Document engine abstraction layer | One internal interface for launching, saving, locking and monitoring documents, whichever engine is configured. | Planned |
| Collabora Online backend | Integration through WOPI, with CODE or a Collabora subscription or partner build. | Under evaluation |
| ONLYOFFICE Docs backend | Integration through the ONLYOFFICE Docs API or its WOPI mode, with Community, Enterprise or Developer edition. | Under evaluation |
| WOPI as the common file interface | One WOPI host in the file service, used by both engines where its gaps are acceptable. | Under evaluation |
| Engine selection per deployment | An administrator setting under Settings → Documents → Editing engine. | Planned |
| Controlled engine cutover | A scheduled, drained and reversible switch from one engine to the other. | Planned |
The abstraction layer
Twelve planned responsibilities, each designed as one contract inside Office Unbound with an adapter per engine. Where the engines differ, the layer is designed for the gap, not the average.
- Editor launch
Common: an “open session” request with the file, the user, their permission and any interface options, returning the editor address and the payload the browser posts to it. Collabora: the editor URL from its WOPI discovery document, opened with a WOPI access token and its expiry. ONLYOFFICE Docs API: a JWT-signed editor configuration carrying the document key, the file URL and a callback URL. The client-side message channels (Collabora’s PostMessage interface, ONLYOFFICE’s editor events) are wrapped by the same layer.
- File access
Common: the file service is the only place files are read from or written to. For Collabora, and for ONLYOFFICE in WOPI mode, that means one WOPI host implementing CheckFileInfo, GetFile, PutFile, PutRelativeFile and RenameFile. In Docs API mode, ONLYOFFICE fetches the file from a URL Office Unbound signs and returns the result through its callback.
- Authentication and authorization
Common: users sign in to Office Unbound, never to the engine. Each session gets a short-lived credential scoped to one file and one user. Collabora uses WOPI access tokens. ONLYOFFICE uses JWT in Docs API mode and WOPI proof keys in WOPI mode.
- Permissions
Common: view, comment, review and edit, derived from file-service permissions. Collabora receives them as CheckFileInfo fields (UserCanWrite, UserCanOnlyComment and others, plus options such as DisableExport and WatermarkText). ONLYOFFICE receives them as the editor mode and document permissions (edit, comment, review, fill forms, download, print, copy). The portable model is the intersection; engine-specific extras are applied where the engine supports them.
- Session management
Common: an Office Unbound session record per file and content revision, holding both engines’ identifiers. Collabora keys a session by the file’s WOPI URL, which stays the same. ONLYOFFICE keys it by a document key, which must change after every successful save, so Office Unbound derives it from the file and its current revision. Listing sessions, forcing a save and disconnecting users map to Collabora’s admin console and metrics, and to ONLYOFFICE’s command service (info, forcesave, drop).
- Locking
Common: locks belong to the file service. Collabora takes a WOPI lock when the host supports locks and renews it by sending LOCK again, every 15 minutes by default. ONLYOFFICE in WOPI mode locks on open and renews with REFRESH_LOCK every 10 minutes. In Docs API mode ONLYOFFICE takes no WOPI lock, so the file service holds its own lock based on the callback’s session events.
- Save and versioning
Common: Office Unbound decides what becomes a version. That covers the final save when the last editor leaves, a user-initiated save, and optionally timed autosaves. Collabora pushes saves itself as WOPI PutFile requests, flagged as autosave, exit save or user-modified. ONLYOFFICE reports through its callback: status 2 when the document is ready to save after the last editor closes, status 6 for a save during editing. ONLYOFFICE does not show its own forcesave versions in its history, so the file service’s history is the single source of truth.
- Collaboration
Common: real-time co-editing, the mode both engines offer. Collabora serves all editors of a document from one server, so a cluster routes by the document’s WOPI URL. ONLYOFFICE also offers a Strict mode that holds changes back until the user saves, but only through the Docs API; it is treated as an engine-specific option.
- File formats
Common: a per-extension capability table recording native editing, lossy editing, view-only and convert-on-open. Collabora publishes its actions in WOPI discovery and edits both ODF and OOXML. ONLYOFFICE lists DOCX, XLSX and PPTX as editable, ODT, ODS, ODP and RTF as lossy edits with conversion, and legacy DOC as view-only with conversion to a new file.
- Error handling
Common: one set of outcomes the interface can explain, namely locked by another editor, file changed since opened, save failed and engine unreachable. Collabora reports a stale write through a WOPI timestamp check that the host answers with a conflict. ONLYOFFICE reports save errors as callback status 3 or 7, and keeps a result the host never accepted as a “forgotten” file. The callback handler acknowledges a save only after the file is stored durably.
- Health checks
Common: is the engine reachable, is its version known, and can it actually open, edit and save a test file? Collabora exposes its discovery and capabilities endpoints and an authenticated metrics endpoint. ONLYOFFICE’s command service reports its version and license. A configuration is designed to be activated only after a real open-edit-save test, as in Flow F.
- Administrator configuration
Common: one settings screen for the engine, its edition, endpoint, shared secret and TLS, with the engine’s own trust settings generated from it. Collabora is told which WOPI hosts to trust. ONLYOFFICE’s WOPI mode is off by default and, since version 10.0, needs an explicit IP filter rule naming the WOPI host. Branding is configured only as far as the selected edition allows, and the notices ONLYOFFICE’s license requires are never hidden by the Office Unbound interface.
WOPI or the Docs API
WOPI is the obvious common interface. It does not cover everything ONLYOFFICE can do, so whether ONLYOFFICE runs in WOPI mode or through its own API is still being evaluated.
Collabora: WOPI only
Collabora Online integrates only through WOPI, extended with its own CheckFileInfo fields, save headers and a client-side PostMessage interface. An Office Unbound WOPI host is therefore required in any case, and it has to accept both engines’ habits: Collabora renews locks with LOCK rather than REFRESH_LOCK, and sends its save flags with both X-COOL-WOPI- and X-LOOL-WOPI- prefixes.
ONLYOFFICE: two interfaces
ONLYOFFICE Docs has its native Docs API: a JavaScript editor configured with a signed document key, a callback that delivers saved files, and a command service for session control. It has also supported WOPI since version 6.4. Using WOPI for both engines would mean one file interface and one locking model. Using the Docs API for ONLYOFFICE would mean a second adapter, a callback handler and host-side locking, in exchange for the features WOPI mode lacks.
ONLYOFFICE’s own comparison of its API and WOPI lists these as unavailable over WOPI:
- Strict co-editing mode (paragraph locking)
- Toolbar customization and branding, templates, the recent-files list and plugins
- JWT server-access restriction (WOPI proof keys are used instead)
- Mail merge, compare, action links, mentions and create-new
- Fill-forms, content-control and download rights
- Mobile viewing and editing
WOPI mode is off by default. ONLYOFFICE 10.0.0 also fixed several WOPI security issues, including an SSRF in the WOPI endpoints and co-editing session hijacking over WOPI, so the minimum supported version matters.
Editions and licensing, side by side
Four editions, not two products. What a deployment may do depends on the edition and the terms that come with it. Summarized from official sources, checked November 14, 2026.
| Topic | Collabora CODE | Collabora Online (commercial) | ONLYOFFICE Community | ONLYOFFICE Enterprise & Developer |
|---|---|---|---|---|
| License | MPL-2.0 source; proprietary theming and branding | MPL-2.0 source; binaries under a subscription agreement | AGPL-3.0-only with section 7 additional terms | Commercial |
| Source obligations | Source of covered files when distributing binaries; none for hosting | MPL for the source; binaries per agreement | Modified and offered over a network: offer the source | Per commercial license |
| Hosting rights | Not forbidden; Collabora does not recommend CODE for production | The intended route, through the partner program for hosting providers | Allowed by the AGPL; positioned for non-critical use | Developer edition is designed for SaaS platforms |
| Redistribution | Allowed; modified builds must drop Collabora’s marks | Not outside the subscription or partner agreement | Under the AGPL, carrying the section 7 terms | Per contract |
| Branding and embedding | No product-name or logo settings; rebranding needs a source build | Theming; white-label terms through sales or partners | ONLYOFFICE logo and notices must stay | Enterprise: customization. Developer: white label |
| Mobile web editing | Yes | Yes | No; view only | Yes, through the Docs API only |
| Technical connection limit | None by default, with welcome and feedback prompts; home mode caps at 20 connections and 10 documents | Licensed per user; “no formal limit” on simultaneous editors | None since 9.4.0 | Licensed connections or users, per plan |
| Recommended deployment scale | Development, testing and home use; not recommended for business production | Sized by subscription and server resources | Up to 20 users, per ONLYOFFICE’s edition table | As in the pricing plan |
| Clustering | Replicas routed per document; Helm chart autoscaling disabled | Same chart, plus the COOL Controller for document migration | Single node only | Cluster add-on |
| High availability | Controller availability for CODE not stated | COOL Controller: leader election and HA | No cluster or disaster recovery | Disaster recovery add-on |
| Multi-tenancy | No tenant concept; can trust several WOPI hosts | Same mechanism; no published feature | No | Add-on, with per-tenant config, secret and license |
| Production support | Community forum; rolling release, no SLA | Subscription with LTS, SLA and signed security updates | Forum and GitHub; no guaranteed response | Basic, Plus or Premium, with response times |
| Integration | WOPI, with extensions | WOPI, with extensions | Docs API, or WOPI (off by default) | Same, plus licensed features |
| Native format | ODF; OOXML through filters | ODF; OOXML through filters | OOXML; ODF as lossy edit | OOXML; ODF as lossy edit |
This table does not rank the engines. Each is the better fit for some deployments and not for others. Editions differ, terms change, and several points depend on agreements that are not published, such as Collabora’s white-label and multi-tenant terms and the commercial terms of ONLYOFFICE’s editions. Any organization choosing an engine or edition must check the current terms directly with Collabora Productivity and with Ascensio System SIA (ONLYOFFICE), and take legal advice where the stakes justify it.
Connection limits. The 20-connection limit often quoted for ONLYOFFICE Community no longer exists. Version 9.4.0 (May 19, 2026) removed it, though ONLYOFFICE still recommends the edition for up to 20 users. A technical limit, a vendor’s recommended scale, production support and the right to host for others are separate questions: removing the cap did not change the edition table, the support terms or the license. Collabora CODE’s default build is unlimited, but its welcome and feedback prompts cannot be switched off. A “home mode” removes them and caps use at 20 connections and 10 documents.
Not confirmed. Which connection settings Collabora uses for its official CODE packages; whether official subscription builds enforce a hard connection cap; whether the COOL Controller is subscription-only; and whether ONLYOFFICE restricts WOPI by edition. These are recorded as open questions.
Selecting an engine
A deployment decision, recorded as one setting rather than a rebuild: Settings → Documents → Editing engine.
The engine is designed to be chosen once per deployment, or per tenant where the operator runs separate instances. The administrator picks the engine and edition, enters its endpoint, shared secret and TLS details, and reviews the license terms and edition limits shown alongside. A connection test then opens, edits, saves and co-edits a test file in each format family. Nothing changes for users until the administrator confirms activation. The sequence is drawn step by step in Flow F.
The questions that usually decide it are practical. Are the organization’s files mostly ODF or mostly OOXML? Does anyone need to edit on a phone’s browser? Will one instance serve several customers, and does it need to cluster or fail over? Is own branding required? Which vendor’s support terms suit the operator? The answers point to different engines and editions for different deployments.
They can also point to a cost. Collabora’s supported production builds come with a subscription licensed per user, and ONLYOFFICE’s Enterprise and Developer editions are licensed by connections or users. Office Unbound’s own code being open source does not change those terms: a deployment that needs one of those editions pays the vendor for it.
Proposed interface concept Not released · example data · subject to change
Collabora Online
Selected · connected
Built on LibreOffice technology · WOPI
ONLYOFFICE Docs
Available
Office Open XML editors · WOPI
Other WOPI-compatible providers
Future
Not available yet
- WOPI discovery reachable
- TLS certificate valid until 3 Mar 2027
- Test document opened and saved
- Allowed host list matches Files
Last tested today 10:42 by Maya Okafor
- Collabora Online · in useSubscription through Ridgeline IT for supported production use. The free CODE edition is meant for testing and small teams.
- ONLYOFFICE DocsCommunity Edition under AGPL-3.0 with additional terms. Mobile web editors, multi-tenancy and clustering need a commercial edition.
Check each vendor’s current terms before choosing an edition.
| Feature | Collabora Online | ONLYOFFICE Docs |
|---|---|---|
| Real-time co-editing | Yes | Yes |
| Track changes | Yes | Yes |
| Comments and mentions | Yes | Yes |
| Native format | ODF (ODT, ODS, ODP) | OOXML (DOCX, XLSX, PPTX) |
| Other format family | OOXML via filters · test layouts | ODF supported · test layouts |
| Mobile web editing | Varies by edition | Varies by edition |
| Rendering | On the server | In the browser |
Changing engines is a controlled workflow, not a toggle.
- 1Assess open sessionsWho is editing, which files are open
- 2Schedule a maintenance windowUsers are told in advance
- 3Drain editing sessionsSave and close open documents
- 4Validate documentsOpen a sample set in the new engine
- 5Switch enginePoint Files at the new provider
- 6TestCo-editing, saving, sharing
- 7Roll back if neededPrevious engine kept ready
Switching engines: a controlled cutover
Planned as a scheduled administrative operation, not a live swap. Planned
Two engines must never hold the same file open at once. Each keeps its own in-memory copy of the document, and the last one to save would overwrite the other. A switch is therefore designed to drain every session on the old engine, prove the new one works on the organization’s real files, and keep a way back. It is drawn in Flow G.
Assess open sessions
List active documents and users on the current engine, from Collabora’s admin console and metrics or ONLYOFFICE’s command service.
Identify compatibility risks
Run a sample of the tenant’s files, including tracked changes, comments and complex layouts, through the new engine. Note features users will lose, such as mobile web editing when moving to ONLYOFFICE Community.
Schedule a maintenance window
Agree the window with the customer and tell users. Blocking risks stop the switch here, before anything changes.
Drain sessions
Stop issuing new sessions on the old engine, then wait for a definite “closed and saved” signal per document. For Collabora, that is the final PutFile flagged IsExitSave, followed by UNLOCK; a document with no edits sends no save, so the unlock or the session’s disappearance counts. For ONLYOFFICE, it is callback status 2 (saved) or 4 (closed without changes). Status 6 means a save during editing, so the session is still live. ONLYOFFICE can be forced with forcesave and drop. Any forgotten files are then listed, retrieved and imported before the engine is retired.
Validate the new engine
Run the connection and open-edit-save tests against the new endpoint with the drained tenant’s settings.
Switch
Point the abstraction layer at the new engine. New document keys are generated from current revisions, and no lock from the old engine is carried over.
Test with users
Open, edit and co-edit real documents, and confirm a full save cycle reaches version history.
Keep the rollback path
The old engine stays deployed but closed to new sessions until the new one has completed a full save cycle for every active tenant. Rolling back is the same procedure in reverse; no files need restoring, because they never lived in the engine.
What does not carry over
Files, permissions and version history stay in Office Unbound, so they survive a switch. Engine state, and the way each engine renders a file, do not.
ONLYOFFICE document keys
ONLYOFFICE caches documents by key, and reusing an old key can open an old cached version. Keys are never reused after a switch, including a switch back; they are generated from the current revision.
Lock state
Lock tokens are formatted differently by each engine, and the new engine must not inherit the old one’s. Old locks are released during the drain or left to expire; WOPI locks expire after 30 minutes.
Rendering differences
The same file can lay out differently in the two engines: fonts, pagination, charts, SmartArt and form controls in particular. Installing the same fonts on both reduces this. Tracked changes and comments are stored in the file, but each engine imports the other’s markup with differences.
ODF and OOXML handling
Collabora edits ODF natively and OOXML through filters. ONLYOFFICE edits OOXML natively and ODF as a lossy edit, converting internally and saving back in the original format, so an ODF-heavy tenant risks losing features on the first save. Legacy DOC, XLS and PPT files open in ONLYOFFICE view-only and are converted into new OOXML files. Collabora edits them in place.
History panels differ too. Versions saved through one engine carry none of the change data ONLYOFFICE uses to highlight edits, so after a switch its history shows full versions without highlighted changes.
Sources (verified 2026-11-14)
- Collabora Online COPYING and MPLv2 terms: MPL-2.0 source, proprietary executable conditions
- Collabora CODE and Collabora FAQs: CODE not recommended for production; no formal simultaneous-editor limit
- Collabora EULA, subscriptions and partner program: subscription binaries, support tiers, hosting route
- Collabora trademark policy: use of Collabora marks in product names and modified builds
- configure.ac, COOLWSD.cpp and coolwsd.xml.in: home mode, connection limits, save timing, lock refresh, WOPI host aliases
- WopiStorage.cpp and discovery.xml: WOPI locking, PutFile headers, format actions
- Collabora Online Helm chart and COOL Controller: routing by document, autoscaling disabled, controller HA
- ONLYOFFICE DocumentServer LICENSE and license FAQ: AGPL-3.0 section 7 terms, logo retention, source obligations
- ONLYOFFICE DocumentServer README: edition table (mobile web editors, cluster, multi-tenancy, white label, support)
- ONLYOFFICE CHANGELOG, 9.4 release post and commit c635713: Community connection limit removed in 9.4.0; 10.0.0 WOPI fixes
- ONLYOFFICE license and trademark guide (May 2026) and Developer Edition: commercial services, SaaS use
- ONLYOFFICE Help Center: mobile web editors: view-only in the Community version
- ONLYOFFICE WOPI overview, API vs WOPI and WOPI REST API
- ONLYOFFICE callback handler, command service, co-editing and saving: status codes, document keys, forcesave
- ONLYOFFICE document formats and server default.json: edit, lossy-edit and convert actions; tenants; WOPI settings
- license.js, wopiClient.js and DocsCoServer.js: Community license flags, WOPI lock behavior, license checks
Collabora’s SDK documentation could not be read during this check; Collabora integration details come from its published source. ONLYOFFICE’s trademark policy page did not render, so trademark points come from its license, license FAQ and May 2026 guide.
Run either engine in production?
If you operate Collabora Online or ONLYOFFICE Docs today, what broke during upgrades, scale-out or a format migration is exactly what this design needs to account for.