Docker-CommunityServer packages a whole office suite into containers

The repository is packaging, not the application

The project description calls this a collaborative system for managing documents, projects, customer relations and emails in one place, and the readme explains the split that matters for evaluation.

ONLYOFFICE Community Server is the free open source collaborative system. Starting from version 11, it is distributed as ONLYOFFICE Groups on terms of the Apache License, and it is one part of the wider ONLYOFFICE Workspace. The other parts are separate projects with their own repositories: the Document Server, distributed as ONLYOFFICE Docs, the Mail Server, and Talk, the instant messaging application. The Control Panel for administering the whole Workspace lives in yet another repository.

What this repository actually contains is the container side of that. The top level holds a Dockerfile and a Dockerfile.ami, run-community-server.sh as the entry point, a .env file, a build.yml, a config directory, hooks, assets, a 3rd-Party.txt, and three compose files: docker-compose.groups.yml, docker-compose.workspace.yml and docker-compose.workspace_enterprise.yml.

That set of compose files is the decision point. The groups file is the community suite on its own, the workspace file adds the document and mail servers, and the enterprise variant is a different configuration again. Picking the wrong one is the most common way to end up with a container that expects services you did not start.

The feature list is closer to an office suite than to a document server

The functionality list in the readme is long, and it is the clearest statement of what you are deploying.

The core is document management, file sharing, document embedding and access rights management, with integration listed for Google Drive, Box, Dropbox, OneDrive and OwnCloud. Around that sits a customisable CRM, a web-to-lead form and an invoicing system.

Then there is a project management half: projects, a Gantt chart, milestones, task dependencies and subtasks, time tracking and automated reports. And a collaboration half: blogs, forums, polls, a wiki, a calendar, an email aggregator and a people module described as an employee database. The system supports more than 20 languages, and the readme calls it a cross platform solution for Linux and Windows.

The important structural point is that the document editing itself comes from elsewhere. This repository does not contain an editor; the Document Server does, and it is a separate container in the workspace compose file. The same is true of mail. So the Docker-CommunityServer image on its own gives you the collaborative shell of the product, and the working document editor comes when you add the Document Server alongside it.

The prerequisites are directories and a bridge network

The installation guide does not start with a docker run command. It starts with a set of directories that the containers will mount, and the readme asks you to create them first.

For the MySQL server there are three paths, for the configuration, the data and the initdb directory that the container reads on first start.

sudo mkdir -p "/app/onlyoffice/mysql/conf.d";
sudo mkdir -p "/app/onlyoffice/mysql/data";
sudo mkdir -p "/app/onlyoffice/mysql/initdb";

And for the Community Server data and logs, the same pattern repeats, with a letsencrypt directory for certificates, plus directories for the Document Server, the Mail Server and the Control Panel, since the compose files expect all of them to exist.

Then the network. The containers talk to each other over a bridge network that you create by name, which is what lets the Community Server reach the database and the document server by container name rather than by host.

sudo docker network create --driver bridge onlyoffice

The recommended system requirements are modest but not small: 4 GB of RAM or more, a dual-core 2 GHz CPU or better, a swap file of at least 2 GB, 2 GB of free disk, a 64-bit Red Hat, CentOS, Debian, Ubuntu or compatible distribution on kernel 3.8 or later, and Docker 1.9.0 or later.

MySQL needs specific settings and its own accounts

The database preparation is the most hands-on part of the guide, and it is done by writing two files into the mounted directories before the container starts.

The first is the MySQL configuration. The values are not defaults: the SQL mode is set to NO_ENGINE_SUBSTITUTION, connections are capped at 1000, the maximum allowed packet is raised to 1048576000, and group_concat_max_len is set to 2048. The last two matter because the product stores and reads large values and builds large IN clauses from its filters.

echo "[mysqld]
sql_mode = 'NO_ENGINE_SUBSTITUTION'
max_connections = 1000
max_allowed_packet = 1048576000
group_concat_max_len = 2048" > /app/onlyoffice/mysql/conf.d/onlyoffice.cnf

The second file is an init script that creates the database users. The onlyoffice_user is required for the Community Server and mail_admin is required if the Mail Server is installed alongside it, and the script also sets the root password and grants privileges.

echo "ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'my-secret-pw';
CREATE USER IF NOT EXISTS 'onlyoffice_user'@'%' IDENTIFIED WITH mysql_native_password BY 'onlyoffice_pass';
CREATE USER IF NOT EXISTS 'mail_admin'@'%' IDENTIFIED WITH mysql_native_password BY 'Isadmin123';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
GRANT ALL PRIVILEGES ON *.* TO 'onlyoffice_user'@'%';
GRANT ALL PRIVILEGES ON *.* TO 'mail_admin'@'%';
FLUSH PRIVILEGES;" > /app/onlyoffice/mysql/initdb/setup.sql

The passwords here are examples printed in the documentation, and they are printed in full. Anyone who deploys this unchanged has a database with a known password, so replacing them is the first thing to do rather than the last.

The image is Ubuntu 22.04 with an embedded Elasticsearch

The Dockerfile shows what the container actually is, and it is more than a thin wrapper.

The base image is ubuntu:22.04, with build arguments for the release date, the version, the package system name and the source repository URL. The version default in the file is 8.9.0.190, which is an argument rather than the version you get, so the build pipeline overrides it.

The build installs systemd, locales, curl, wget and sudo, then creates a system group and a system user for the onlyoffice package with fixed ids, and does the same for an elasticsearch user with its own group. That last part is the giveaway: the environment variable ELASTICSEARCH_VERSION is pinned to 7.16.3, and the image ships its own Elasticsearch instance with directories for the index data and the index log.

So the container is not just the application plus a database connection, it is the application, its search engine and its service management all in one filesystem. The image also carries labels with the release date, the version, a description, a maintainer address and a security contact point in the well-known security.txt format.

The practical consequence is that this image is large and opinionated. You are not choosing where Elasticsearch lives or how it is tuned, and you inherit a specific search engine version that the product was validated against.

The licence is stated two different ways

There is a discrepancy here that deserves attention before deployment.

The project listing records the licence as MIT. The readme says something different: it states that starting from version 11, Community Server is distributed as ONLYOFFICE Groups on terms of the Apache License, and the badge in the readme points at the Apache 2.0 licence text. The repository also contains a LICENSE.txt file.

This is not a subtle difference in wording. MIT and Apache 2.0 differ in their patent grant and in their notice requirements, and the onlyoffice packages in the wider ecosystem are distributed under a mix of terms depending on the component and the edition. Since the readme says the community edition moved to the Apache License at version 11, and the releases in this repository are all version 12, the Apache terms are the ones that describe the code you would actually run.

The right move is to read LICENSE.txt and the third party notices file in the repository root, rather than trusting either the listing or a badge. That is not a legal opinion, it is a note that the two sources in front of you disagree, and that the file in the repository is the one that governs what you ship.

Pushes in 2026, tagged releases that stopped in 2024

The activity record needs reading in two parts.

The repository is not archived, and the last push was on 2026-04-22. So the files are being touched.

The tags tell a different story. The recent releases are v12.7.0.1936 from 2024-10-31, v12.6.0.1900 from 2024-02-29 and v12.5.2.1848 from 2023-07-31, while the readme badge still advertises release 11.0.0. So the last tagged image build is more than a year older than the last commit, and the two do not line up.

That pattern suggests the image tags are cut on a slower cycle than the source, which is normal for a product with a long release process, but it also means you should not assume the newest tag contains the newest commit. Pinning a tag is the safer choice for production, and the readme's own table of contents lists sections for upgrading the Community Server, for configuring the Docker image with stored data, for running on a different port, for exposing additional ports, and for running behind HTTPS with automatically generated Let's Encrypt certificates or self signed ones, which is the documentation to follow for anything beyond the first install.

One more thing to check before you commit: the readme's own instruction is to use only credentials for an application or use case that has been approved, and the passwords it prints for MySQL are documentation examples rather than secrets. Take them as examples to replace, and read the current documentation for the exact values your version expects.

Editorial conclusion

Docker-CommunityServer fits a team that wants self hosted document, project and CRM tooling from a suite that is otherwise a self hosted product, and that is prepared to create directories, configure MySQL by hand and wire containers onto a shared bridge network. It is the wrong choice if you only need an office suite for a handful of people, because the readme recommends 4 GB of RAM and a second service database before you even open a document. Check first that the licence recorded in the repository matches the one the readme describes, that the image tag you pin corresponds to a release you can upgrade from, and that the account and password examples in the readme are replaced before the database is exposed anywhere.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. ONLYOFFICE/Docker-CommunityServer on GitHub
4. README
5. Releases