Deploying and Integrating OnlyOffice Document Server with Docker and Kubernetes for Collaborative Editing

OnlyOffice is an open‑source office suite that enables online editing, preview, and real‑time collaborative editing of Word, Excel, PPT, and PDF files directly in a browser without installing client software.

The document server can be deployed either from source (requiring Redis, RabbitMQ, Nginx, PostgreSQL, etc.) or via Docker images; the guide recommends the Docker approach for simplicity.

Docker deployment steps:

1. Prepare a server with Docker, at least 2 CPU cores, 4 GB RAM, and 40 GB disk.

2. Pull the Docker image (version 5.4.2.46, the last version supporting 20 concurrent connections):

docker pull onlyoffice/documentserver

3. Run the container, mapping port 80 to host port 9000:

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

4. Access the service at http://localhost:9000/web-apps/apps/api/documents/api.js to verify it starts correctly (a UI page indicates success).

Connector development: Create an HTML page that loads the /web-apps/apps/api/documents/api.js script and supplies a config object. The config includes:

document : title, URL, file type, etc.

editorConfig : mode (desktop, mobile, embedded), language, UI options.

events : callbacks for document lifecycle events.

The connector also defines a callbackUrl that OnlyOffice calls after editing; the endpoint must return {"error":0} for successful saves. Status codes 0‑7 indicate various document states (e.g., editing, ready to save, error).

Cluster deployment and collaborative editing: The community edition limits concurrent connections to 20, so production use requires clustering. High‑availability is achieved with load balancing (NGINX + Docker) or, preferably, Kubernetes, which provides automatic failover and scaling.

To ensure that all users editing the same document connect to the same OnlyOffice instance, the connector generates a unique document.key for each file. A Redis cache stores the mapping between keys and service nodes; on first access a node is chosen randomly and recorded, subsequent accesses use the stored node, and the mapping is cleared when the document is closed.

The proposed architecture includes:

Maintaining a list of healthy OnlyOffice services with periodic health checks stored in Redis or external config.

Using the document.key to route requests consistently.

Deploying each OnlyOffice instance as a Kubernetes service for load balancing and fault tolerance.

Conclusion: For simple use, launching the Docker container and accessing it via a browser suffices. For production, consider server resource requirements (e.g., 16 CPU cores and 32 GB RAM for ~1000 concurrent users) and adopt a clustered, Kubernetes‑based deployment to ensure scalability and reliable collaborative editing.