ONLYOFFICE Docs (DocumentServer): Self-Hosted Collaborative Editing for OOXML Files

What ONLYOFFICE Docs solves, and who it is actually for

The problem is narrow and specific: you have documents in Office Open XML formats (.docx, .xlsx, .pptx) and you need several people to edit them at the same time, inside your own infrastructure, without asking every user to install a desktop suite or upload their files to somebody else's cloud. ONLYOFFICE Docs answers that with browser-based editors for texts, spreadsheets, presentations, forms, PDFs and diagrams, with collaborative editing in real time.

The README is explicit about the intended shape of a deployment. ONLYOFFICE Docs can be used as part of ONLYOFFICE DocSpace or ONLYOFFICE Workspace, or with third-party sync and share solutions such as Odoo, Moodle, ownCloud and Seafile, to enable collaborative editing inside their interface. Read that sentence carefully, because it defines the audience. The primary user is an integrator: someone who already has a place where files live and a user interface where people work, and who wants an editing surface dropped into it. The repository even splits itself along those lines, with separate components for the backend server layer, the conversion core, bundled fonts, the JavaScript SDK, the frontend web apps, spellcheck dictionaries, format metadata and document templates.

If you want a finished product with a file list, sharing links and user management, this repository is the wrong layer. The README directs that audience to DocSpace instead. What you get here is the editing engine and the server that drives it.

The component split behind real-time co-editing

The architecture is visible in the repository layout rather than in prose. The top level contains server, core, core-fonts, sdkjs, web-apps, dictionaries, document-formats and document-templates, and each is a separate repository pulled in as a submodule. That split tells you where the work happens.

core handles conversion between the popular office formats, and the README lists a wide set: DOC, DOCX, ODT, RTF, TXT, PDF, HTML, EPUB, XPS, DjVu, XLS, XLSX, ODS, CSV, PPT, PPTX and ODP. server is the backend layer that the README describes as the base for all other components. web-apps builds the interface users see, and sdkjs is the client-side JavaScript API that the interface is written against. core-fonts matters more than its name suggests: because rendering happens server-side, the fonts bundled in the image determine how a document looks when it is displayed or converted, and a missing font is a layout change, not a cosmetic detail.

The practical consequence is that the editors are not a static bundle you drop on a CDN. The server converts, renders and coordinates; the browser talks to it. Plugins extend the editors with features outside the OOXML format itself, and the README points to the plugin and macros API plus a separate plugins repository and a marketplace. That is the extension path if the built-in feature set is not enough.

Installing ONLYOFFICE Document Server and opening a first document

The README does not walk through installation step by step. It names the packages and sends you to the download pages, so the package names below are exactly as the README writes them, not a transcript of a run. The Community Edition ships as the onlyoffice-documentserver package, the Enterprise Edition as onlyoffice-documentserver-ee, and the Developer Edition as onlyoffice-documentserver-de. Pick one before you start; they are not interchangeable add-ons.

The README does not provide an install command, so the one thing you can verify from the repository is which package name belongs to which edition:

onlyoffice-documentserver
onlyoffice-documentserver-ee
onlyoffice-documentserver-de

Those are the three package names, in the order Community, Enterprise and Developer. Install the one that matches your edition through your distribution's package manager, then confirm the service is listening before you build an integration against it. The README does not document a default port or an initial URL, so that check is on you.

A container deployment is the other route the search data points at, and the image reference people use is onlyoffice/documentserver. The README does not state the container's environment variables, ports or volume layout, so there is no run command to copy from it. Check the image documentation before you put real files behind it.

The first real use is not opening a document by hand. It is handing the editor a document URL and a callback URL, so that when a user saves, the server posts the edited file back to your application. That callback is what makes the deployment useful, and it is the piece to get right first.

Where ONLYOFFICE Docs stops being the right tool

The clearest limitation is structural: ONLYOFFICE Docs is not a document management system. There is no file browser, no sharing model and no user directory in this repository. If you deploy it alone and point a browser at it, you have an editor with nowhere to store anything. The README's own framing confirms this by listing DocSpace, Workspace and third-party sync and share solutions as the ways it is meant to be used.

Licensing splits the same way. The repository is AGPL-3.0, and the README describes three editions with different pricing and licensing. The Community Edition package is the free one, described as suited to small teams and personal use; the Enterprise and Developer editions are separate packages with their own pricing pages. If your requirement is a commercial integration with vendor support, the free package is not the answer, and the README does not claim it is.

There is also an operational cost that the component list implies. Conversion and rendering are server-side, so CPU and memory scale with editing activity and with the format mix, not with the number of stored files. A deployment that converts large spreadsheets or opens many documents at once behaves differently from one that mostly displays text. The README gives no sizing guidance, so capacity has to come from your own load testing rather than from the project's documentation.

How it compares with Nextcloud plus Collabora Online

The nearest alternative for the same job is Nextcloud with Collabora Online. Both give you browser editing of OOXML files on your own hardware, and both are open source. The difference is where the file layer lives.

Nextcloud is a full file sync and share product first, and Collabora plugs an editing surface into it. You get storage, sharing, versioning and users from the same deployment. ONLYOFFICE Docs is the reverse arrangement: the editing engine is the product, and the file layer is something you already have or add separately, whether that is DocSpace, Workspace or a third-party sync and share solution from the connector list.

That makes the choice fairly clean. If you need a document store and an editor together and have no existing file platform, the Nextcloud route gives you both in one place. If you already run Moodle, Odoo, ownCloud, Seafile or an in-house application and only need the editing surface, ONLYOFFICE Docs is the smaller addition, because it does not ask you to migrate your files into a new store. The README also notes that ONLYOFFICE Docs can run inside third-party sync and share solutions, including ownCloud, so the two approaches are not mutually exclusive in every case.

Maintenance, upgrades and what the licence means in practice

The repository is not archived, and the last push was on 2026-07-22. Releases have been frequent: v9.3.0 on 2026-02-24, v9.3.1 on 2026-03-03 and v9.4.0 on 2026-05-19. The cadence suggests a project that ships on a regular schedule, and the CHANGELOG.md at the top level is where the project records what changed between them.

Upgrade cost is dominated by the deployment style you chose. A package install moves with your distribution's package manager; a container moves when you pull a new image tag. Neither is documented in the README in step-by-step form, so the version you are running is something you track yourself. The submodule layout adds a wrinkle for anyone building from source: server, core, core-fonts, sdkjs, web-apps and the rest are separate repositories, and a source build has to keep them in step. The repository includes an .mrconfig and an mr-update.sh script, which is how the project manages those checkouts.

The licence is AGPL-3.0. That is a strong copyleft licence, and the README separately describes Community, Enterprise and Developer editions with their own pricing and licensing terms. How AGPL obligations apply to your specific integration, especially one exposed over a network, is a question for your own legal review. What the repository tells you is the licence identifier and the existence of the commercial editions; it does not tell you which one your use case requires.

Editorial conclusion

Adopt ONLYOFFICE Docs if you already run a file store, LMS or ERP and need OOXML editing inside it, or if you want a self-hosted suite that never sends documents to a third party. Do not adopt it expecting a finished Drive-style product: the repository README points you at ONLYOFFICE DocSpace and Workspace for that. Before you commit, verify which of the three packages (onlyoffice-documentserver, onlyoffice-documentserver-ee, onlyoffice-documentserver-de) matches your use, and confirm your integration can supply the callback URL that lets the editor write files back. That callback is the boundary between a working deployment and a viewer that silently discards edits.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. ONLYOFFICE/DocumentServer on GitHub
3. Project website
4. README
5. Releases