ONLYOFFICE Docker-DocumentServer: a self-hosted office suite in one container

What ONLYOFFICE Docker-DocumentServer is, and who it is for

This repository is the container packaging of ONLYOFFICE Docs, formerly called Document Server. The image contains viewers and editors for text documents, spreadsheets, presentations, PDFs and PDF forms, and the README states that the suite supports DOCX, ODT, XLSX, ODS, CSV, PPTX and ODP among other formats. Collaborative editing in real time, review and track changes, comments and chat are part of the editor feature set described there.

The audience is narrower than the feature list suggests. The README describes two usage paths: as a component of ONLYOFFICE DocSpace or ONLYOFFICE Workspace, or together with third-party sync and share solutions such as Odoo, Moodle, Nextcloud, ownCloud and Seafile. In both cases the container supplies the editing engine while something else owns the files, the user accounts and the sharing rules. If you want an office suite that people log into and store documents in, this image is one half of that system.

The free Community edition is what this image installs. The README points out that Document Server has three editions and that the Docker image gives you the Community one; the Enterprise and Developer editions appear as separate images, onlyoffice/documentserver-ee and onlyoffice/documentserver-de, in the volume-mounting examples.

The architecture the README exposes: nginx, PostgreSQL, RabbitMQ and Redis

The container is not a single process. The README lists six data directories that correspond to the moving parts inside: /var/log/onlyoffice for logs, /var/www/onlyoffice/Data for certificates, /var/lib/onlyoffice for the file cache, /var/lib/postgresql for the database, /var/lib/rabbitmq for the message broker and /var/lib/redis for cache. A running instance therefore includes a web server, a relational database, a queue and a cache, which is why the recommended footprint is 4 GB of RAM and a dual-core 2 GHz CPU rather than a few hundred megabytes.

The README is explicit about which of those are bundled. In the Enterprise and Developer editions, PostgreSQL, RabbitMQ and Redis are described as bundled in the image, and the corresponding volumes are mounted in the example command. The Community example mounts only logs, Data and lib. That distinction matters when you plan storage: the README notes that saving container data is normally unnecessary because the container does not depend on its state, and that mounting volumes is useful for log access, for lifting the size limit on data inside the container, and for running services such as PostgreSQL, Redis or RabbitMQ outside the container.

The healthcheck in docker-compose.yml probes http://localhost:8000/info/info.json every 30 seconds with a 60 second start period and five retries, so port 8000 is the internal endpoint the maintainers consider authoritative for readiness. The exposed ports in the same file are 80 and 443.

Running the image with docker run

The README gives a single command for a standalone install. It publishes port 80 and detaches the container:

sudo docker run -i -t -d -p 80:80 onlyoffice/documentserver

The README warns that docker-engine should be updated to the latest version, citing 20.10.21 at the time of writing, because the image uses ubuntu:24.04 as its base and older Docker releases have compatibility problems with it. Check your engine version before you start.

For anything beyond a trial, mount the data directories so logs and certificates survive a container replacement. The README's Community example is:

sudo docker run -i -t -d -p 80:80 \
    -v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice  \
    -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data  \
    -v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice \
    onlyoffice/documentserver

To listen on a different port, the README says to change the -p argument, giving port 8080 as the example. Once the container is up, the editor interface is served on the published port, and the host application you connect it to will call into that address.

Installing with docker-compose and enabling JWT

The repository ships a docker-compose.yml that builds the documentserver-community target from the local context, names the container onlyoffice-documentserver, publishes 80 and 443, restarts always, and allows 60 seconds for a graceful stop. It also declares the volumes for Data, logs, the file cache, the example public files and system fonts.

The environment block is where the interesting decision sits. It contains four commented-out variables for JSON Web Token validation:

    environment:
      # Uncomment strings below to enable the JSON Web Token validation.
      #- JWT_ENABLED=true
      #- JWT_SECRET=secret
      #- JWT_HEADER=Authorization
      #- JWT_IN_BODY=true

As shipped, the file enables none of them, so a stack brought up from this compose file runs without token validation. If the editor endpoint is reachable from anywhere other than your application server, uncomment JWT_ENABLED and set a JWT_SECRET before exposing it. The other two keys control which header carries the token and whether it is also accepted in the request body.

Separate compose files exist for the other editions. docker-compose.enterprise.yml and docker-compose.developer.yml sit alongside the community one at the top level of the repository, matching the three editions the README describes.

Limits, failure modes and when this is the wrong tool

The most common mistake is treating the container as a document management system. It is not one. The README positions it as an editing component for DocSpace, Workspace or third-party sync and share platforms, so files, permissions and sharing have to come from elsewhere. Deploy it alone and you get editors with no library behind them.

The resource requirements are real, not conservative rounding. A bundled PostgreSQL, RabbitMQ, Redis, nginx and the document processing services share the container, and the README asks for 4 GB of RAM, 2 GB of swap and at least 2 GB of free disk. On a small VPS that already runs a database and a web application, this is the container that will trigger the out-of-memory killer first.

Unmounting volumes is a legitimate choice the README endorses, since the container does not depend on its state. The consequence is that anything you did not mount is lost when the container is replaced. Certificates under /var/www/onlyoffice/Data and logs under /var/log/onlyoffice are the two directories where that hurts most, which is why both appear in every example command.

Finally, the README does not document a rollback procedure for a failed upgrade, and it does not state a supported migration path between editions. If you move from the Community image to the Enterprise one to get the bundled PostgreSQL, RabbitMQ and Redis, plan that transition yourself rather than expecting the documentation to walk you through it.

How it differs from running LibreOffice in a container

The obvious alternative for self-hosted document handling is a container built around LibreOffice, which people search for as LibreOffice Docker. The difference is in what each one is for. LibreOffice in a container is typically a headless conversion engine: you hand it a file, it produces a PDF or another format, and the process ends. There is no persistent editing session and no collaboration model.

ONLYOFFICE Docker-DocumentServer is built around live sessions instead. The README describes collaborative editing in real time, review and track changes, comments and chat, plus a plugin system for features outside the OOXML format, with links to the plugin API and the plugins repository. The container keeps a database, a message broker and a cache running so that multiple people can edit the same document while the host application mediates access.

That is also the cost. A conversion container can be short-lived and stateless; this one wants four gigabytes of memory and a permanent set of volumes. If your requirement is batch conversion of office files into PDFs, this image is heavier than the job needs. If your requirement is several people editing the same DOCX at once inside Nextcloud, a conversion engine will not do it.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-09-28, so it is being worked on. There are no releases recorded, which means version tracking happens through the Docker image tags rather than through GitHub releases; the Makefile builds tags of the form $(PRODUCT_VERSION).$(BUILD_NUMBER) with a branch suffix for non-nightly channels, and pushes to a docker image named $(DOCKER_ORG)/4testing-$(PRODUCT_NAME)$(PRODUCT_EDITION). That naming suggests the tags you pull from the registry are produced by this build pipeline rather than hand-published.

The licence is AGPL-3.0. For a self-hosted deployment this is the part to read carefully rather than skim: the AGPL's network clause has implications when you offer modified software to users over a network, and the three-edition structure in the README means the Community image is not the only distribution channel. Nothing here is legal advice, and if you plan to modify the image or embed it in a product, take your own reading of the licence text in LICENSE before you ship.

Upgrade cost is dominated by the data directories. Because PostgreSQL, RabbitMQ and Redis hold state under /var/lib, an image upgrade without those volumes mounted discards the database. Mounting them, as the README's Enterprise example does, is what makes an upgrade a container swap instead of a rebuild.

Editorial conclusion

Adopt it if you already run a sync-and-share platform such as Nextcloud, ownCloud, Seafile, Moodle or Odoo and need OOXML editing that stays on your own hardware, and if you can give the container 4 GB of RAM, 2 GB of swap and at least 2 GB of disk. Do not adopt it as a standalone document portal: the image ships the editors, not the file storage, accounts or sharing layer, so without a host application there is nowhere for documents to live. Before you commit, verify three things in your own environment: that your Docker engine is recent enough for the ubuntu:24.04 base image, that your host application is listed among the supported connectors, and whether you need JWT_ENABLED for your deployment. The docker-compose.yml in the repository leaves JWT_ENABLED commented out, so a default stack accepts unauthenticated requests to the editor service.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. ONLYOFFICE/Docker-DocumentServer on GitHub
4. README