The compose file ships with JWT validation commented out

Four JWT variables, all of them commented out

The compose file in the repository root is the fastest way to see how this image expects to be deployed, and its environment block is four commented lines.

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

So token validation is implemented and available, and the shipped default is off. Nothing else in the file turns it on, and the README does not tell you to enable it. The variable names describe the whole surface: whether to validate, which secret to use, which header carries the token, and whether the token may arrive in the request body rather than the header.

That default matters because the same file publishes ports 80 and 443 to the host. A compose file that is ready to expose a document server on both HTTP and HTTPS, with request authentication available but switched off, is a deployment decision that belongs to whoever installs it rather than to the template.

The rest of the service block is careful: a named container, `restart: always`, a 60 second stop grace period, `stdin_open`, and a health check with a 30 second interval, five retries, a 60 second start period and a 10 second timeout.

The health check asks a port the file never publishes

The health check is the other line in that file worth reading twice.

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8000/info/info.json"]

The published ports are 80 and 443. The health check asks port 8000, inside the container, for an info endpoint. That is a deliberate arrangement rather than a mistake, since a check has to run inside the container and does not go through the published mapping, but it means the port in the health check is not the port a user reaches.

For anyone debugging a container that will not become healthy, that is the first thing to know: the failure will come from a request to port 8000 on the container's loopback, while your traffic goes to 80 or 443 on the host. The 60 second start period is also worth noting, because a large office suite image takes longer than 30 seconds to be ready and the check is given a minute of grace before it starts counting failures.

The volumes in that file are anonymous, which is the other half of the default posture. Paths are given without a host directory, so the data lands in Docker managed volumes rather than anywhere you can point a backup at.

Two Docker requirements in one README that do not agree

The requirements section lists Docker 1.9.0 or later. The overview tells you to update docker-engine to the latest version, naming 20.10.21 as of the writing, before using the image at all.

Both statements are in the same file, and the reason for the second one is given: the base image is Ubuntu 24.04, and older versions of Docker have compatibility problems with it. So the 1.9.0 floor describes the oldest engine the image is nominally compatible with, and the 20.10.21 advice describes the oldest one that will actually work with this base.

The rest of the requirements section is equally concrete and is worth reading as a sizing guide rather than a suggestion. 4 GB of RAM or more, a dual-core 2 GHz CPU or higher, at least 2 GB of swap, and at least 2 GB of free disk space. The swap requirement is the one that matters most in practice, because an office suite that renders documents in a browser will be asked to do work it cannot do in memory and will fall back to disk.

For the operating system itself the list is a kernel version requirement rather than a distribution list: a 64-bit Red Hat, CentOS or compatible distribution with kernel 3.8 or later, or a 64-bit Debian, Ubuntu or compatible distribution at 3.8 or later.

Six data paths, and the Community image mounts three

The storing data section names six locations inside the container, and they are worth having in one list because a restore depends on knowing all of them.

Logs go to `/var/log/onlyoffice`, certificates to `/var/www/onlyoffice/Data`, the file cache to `/var/lib/onlyoffice`, and then three more that exist because the image bundles services: the database at `/var/lib/postgresql`, the message broker at `/var/lib/rabbitmq`, and the cache at `/var/lib/redis`.

That last group is the edition split. The Community example mounts three volumes:

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

The Enterprise and Developer examples mount six, adding the database, broker and cache paths, with a note that PostgreSQL, RabbitMQ and Redis are bundled in those images and a comment on the image name line naming the enterprise and developer tags. Same application, different persistence surface.

The README also says something reassuring and slightly unusual: normally you do not need to store container data, because the container's operation does not depend on its state. Three cases are named where you should, easy access to logs such as for support, removing the size limit on data inside the container, and running those three services outside the container instead.

The port example is missing half a command

The first run command in the README is complete and is the one most people will copy.

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

Then the section on running on a different port gives its example as `sudo docker run -i -t -d -p 8080`, which is not a command that will run. There is no image name at the end, and a port mapping needs two sides, so `-p 8080` on its own is not the mapping described in the prose above it, which says you would execute that command to make the portal accessible on port 8080.

It reads like an editing slip where the tail of the line was lost, and it is the kind of defect that costs a reader more time than it should, because the failure mode is a Docker error about the run command's arguments rather than anything about the image.

The rest of that section is truncated in the source, so what follows it, including the HTTPS material with Let's Encrypt certificates, self-signed certificates, hardening steps and the table of available configuration parameters, is all listed in the table of contents at the top but not present in the text that arrives.

That gap is worth knowing about when you are evaluating this repository as documentation: the anchors all resolve to sections further down the page.

The image installs htop, nano, netcat and a policy script that blocks services

The Dockerfile is where the real dependencies are, and it is worth reading as a list of what an office suite needs beyond an editor.

The base is Ubuntu, with the version passed as a build argument defaulting to 24.04, and the maintainer label names Ascensio System SIA. A PostgreSQL major version of 16 and a package suffix for 64 bit builds are also build arguments.

The package list includes the graphics and input stack a headless renderer needs, `libgtk-3-0`, `libcairo2`, `libasound2`, plus `libcurl`, `libxml2` and `libnss3`. Then the pieces that show the deployment model: `nginx-extras` as the web server, `supervisor` to manage processes, `cron` for scheduled work, and `certbot` for certificate handling. `xvfb` is there because rendering happens without a screen.

And then the ones nobody puts in a production image on purpose: `htop`, `nano` and `netcat-openbsd`, plus `pwgen` for generating passwords. They come from the same install line as the libraries.

Two more details are worth knowing. A `policy-rc.d` script is written that exits 101, which stops package installs from starting services during the build. And the Microsoft core fonts installer is accepted non-interactively, by writing a debconf selection and setting an acceptance variable, which is how the EULA for those fonts is agreed to inside an image build.

Oracle Instant Client is downloaded and then trimmed

One dependency comes from outside the distribution, and the build does something specific with it.

A set of environment variables composes a path and a download URL pointing at the Oracle site for the Linux Instant Client, with the release, revision and date assembled from four separate build-time values. The file suffix and version directory are derived from the same values, so a change of release number moves the URL and the unpack location together.

The trimming tool is `bomstrip`, installed in the same package list. That combination, a large vendor archive fetched by URL during the build and a tool whose purpose is removing documentation and unused files from installed Oracle products, tells you the office server ships a database client it does not need at full size.

It also means the build has a network dependency outside the package manager. A rebuild years from now depends on that Oracle URL still resolving, which is a different kind of fragility from an apt mirror disappearing.

The fonts directory in the repository root is copied into the image during the build, which is where the typefaces that the core fonts installer provides come from, and the compose file mounts the host's font directory at run time on top of that.

Three compose files, three forge configs and one assistant file

The root listing lines up with the three editions and then adds a little noise.

There are three compose files, `docker-compose.yml`, `docker-compose.enterprise.yml` and `docker-compose.developer.yml`, which match the three editions the overview describes, and two Dockerfiles, `Dockerfile` and `production.dockerfile`, plus a `docker-bake.hcl` for building several targets at once. The compose file builds from the local context with an explicit target stage rather than pulling a published image, so a compose based deployment here compiles the image first.

Then the automation. There is a `.github/` directory, a `.travis.yml` and a `.gitea/` directory. Three CI or forge configurations for one repository means the build history is probably split across platforms that were used at different times.

`CLAUDE.md` sits at the root, an instruction file for an assistant tool, in a repository whose primary language is recorded as Shell.

The Makefile explains the release naming and is where the second base image discrepancy appears: the build target pulls `ubuntu:22.04` while the Dockerfile argument defaults to 24.04. The same target passes `TARGETARCH=amd64` explicitly, so the image it produces is single architecture by construction. Package versions are suffixed with `~stretch`, a Debian 9 codename, on a 24.04 base. Images are tagged under a repository name containing `4testing`, and the default build channel is nightly, which is why a tag built by default carries no branch name. The repository's own default branch is master while the Makefile defaults its branch variable to develop.

The licence is AGPL-3.0, the last push was on 2026-10-03, and the repository publishes no GitHub releases.

Editorial conclusion

Deploy this if you want a self-hosted office suite with real-time editing and can accept the AGPL terms and the operational weight of an image that bundles a web server, a database, a broker and a cache. Do not expose the default compose file to a network as it stands, because JSON Web Token validation is present but disabled and the ports published are 80 and 443. Three things to settle before the first deploy: whether you are turning JWT on, which the compose file leaves to you with four commented lines; which Docker version your host has, since the requirements list and the overview recommend different ones; and which of the three editions you actually mounted, because the Community image mounts three volumes and the Enterprise and Developer images mount six.

Frequently asked questions

Official sources

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