Fix ONLYOFFICE Co-Editing Lag on a Self-Hosted Docker Server

If ONLYOFFICE co-editing feels slow on a self-hosted Docker server, do not start by changing undocumented editor parameters. First separate the problem into three measurable areas: server resource pressure, reverse-proxy/WebSocket behavior, and storage or container-level errors. Co-editing depends on long-lived, real-time communication, so a server that opens documents successfully can still feel sluggish when several people type at once.

This guide uses a hypothetical example throughout: a small team runs ONLYOFFICE Docs in Docker behind NGINX. One or two users can edit normally, but when six people open the same document, cursor updates arrive late and other users' changes appear after a noticeable pause. This example is only a teaching scenario, not a benchmark or a report of a real deployment.

As of October 2026, ONLYOFFICE Docs 9.4 is the current release listed in the official changelog. Version 9.4 also changed the Community Edition architecture by removing dependencies on RabbitMQ and databases, so advice written for older releases may no longer match a current Community Edition container. Always confirm your installed edition and version before copying tuning advice from an older forum post.

1. Measure the lag before changing anything

In the hypothetical case, the first mistake would be to restart random services and hope the lag disappears. Instead, create a repeatable test. Open the same document from several browser sessions or test accounts, type short edits, and note what is delayed: keystrokes on the local screen, remote cursor movement, the appearance of another user's text, saving status, or the initial document load.

These symptoms point to different bottlenecks. If the editor itself freezes on the local browser, client-side CPU or a very complex document may be involved. If local typing is immediate but remote edits arrive late, examine the network path and WebSocket session. If every action slows when more documents are opened, inspect server CPU, memory, swap, and disk I/O.

ONLYOFFICE describes its Docker deployment and baseline requirements in the official Docker installation guide. For Docker Compose, use the official Docker Compose instructions.

2. Check CPU and memory pressure while users are editing

On the Docker host, run:

docker stats

Watch the Document Server container while the test group edits. Also inspect host resources with tools such as:

free -h
uptime
vmstat 1
df -h

ONLYOFFICE's official Docker requirements specify at least 4 GB of RAM and at least 40 GB of free disk space for the documented configurations, with swap requirements as well. Enterprise guidance also makes clear that capacity depends on concurrent active users and on the number, type, and size of documents. Those figures are baselines, not a promise that 4 GB will provide smooth collaboration for every workload.

In our example, suppose docker stats shows the Document Server container repeatedly consuming most available CPU whenever six people type at once. That is meaningful evidence: adding proxy timeouts will not create more CPU. The next step is to remove an overly restrictive Docker CPU limit, move the container to a faster host, or reduce concurrent workload. By contrast, if CPU remains modest, keep investigating before buying hardware.

The official reference for published capacity guidance is the ONLYOFFICE Docs Docker system requirements.

3. Check disk space, mounts, and the file cache

ONLYOFFICE's Docker documentation identifies persistent locations including /var/log/onlyoffice for logs and /var/lib/onlyoffice for file cache. Check the filesystem that backs those paths, not just the host's root filesystem.

df -h
docker inspect documentserver --format '{json .Mounts}'

If a bind mount points to a slow network filesystem or an overloaded disk, document opening, conversion, and cache activity can add latency. If the disk is nearly full, fix that before doing application tuning. ONLYOFFICE's Linux troubleshooting documentation specifically identifies insufficient disk space as a possible cause of conversion problems.

The project also recommends storing relevant data outside the container when you need persistent logs, cache storage, or external database/Redis/RabbitMQ services. See the official Docker volume guidance.

4. Verify the reverse proxy preserves the real-time connection

Many self-hosted deployments put ONLYOFFICE behind NGINX, Apache, HAProxy, or Traefik. The official ONLYOFFICE proxy documentation explicitly requires forwarded headers such as X-Forwarded-Proto and X-Forwarded-Host. The configuration shipped by ONLYOFFICE also uses HTTP/1.1 and WebSocket upgrade handling.

For NGINX, compare your configuration with ONLYOFFICE's official example rather than pasting a generic WebSocket snippet from another product. A representative pattern includes:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Forwarded-Host $the_host;
proxy_set_header X-Forwarded-Proto $the_scheme;

Las directivas circundantes mapy las ubicaciones de los proxies son importantes. Utilice el ejemplo completo del proveedor para su topología. Las configuraciones compatibles se publican en Uso de ONLYOFFICE Docs detrás del proxy .

En el equipo hipotético, supongamos que el host de Docker tiene suficiente CPU y RAM, pero el navegador se reconecta repetidamente al canal de colaboración a través de una capa NGINX corporativa. Esto apunta a la ruta del proxy, no a la capacidad de procesamiento del servidor de documentos.

5. Confirma la sesión WebSocket en el navegador.

Abra las herramientas para desarrolladores del navegador, seleccione el panel Red, filtre el tráfico de WebSocket y recargue el editor. Un establecimiento de conexión WebSocket exitoso generalmente muestra HTTP 101 Switching Protocolsy una conexión que permanece abierta. No considere un WebSocket "pendiente" prolongado como un fallo; se espera que un WebSocket activo permanezca abierto.

Lo que importa es el comportamiento repetido de desconexión/reconexión, los fallos en el protocolo de enlace, los errores de proxy o las largas pausas que se correlacionan con el retraso en la colaboración. Si las ediciones remotas se retrasan en los mismos momentos en que se reconecta el WebSocket, entonces tienes un problema de red concreto que resolver.

Verifique la terminación TLS, los tiempos de espera de inactividad del proxy, las reglas del balanceador de carga, las políticas del WAF y cualquier intermediario que pueda afectar el tráfico de WebSocket. Si hay más de una capa de proxy, pruebe cada salto en lugar de asumir que la instancia pública de NGINX es la única involucrada.

6. Verifique los contenedores esperados y la arquitectura específica de la edición.

Correr:

docker compose ps
# or
docker ps

No asuma que todas las implementaciones modernas de ONLYOFFICE deben tener la misma colección de contenedores Redis, PostgreSQL o RabbitMQ. Aquí es donde la versión importa. ONLYOFFICE indica que, a partir de la documentación 9.4, la edición Community de código abierto se simplificó a una arquitectura de un solo proceso y se eliminaron las dependencias de RabbitMQ y las bases de datos. Las versiones Enterprise, Developer, las implementaciones Community anteriores y las pilas Compose personalizadas pueden diferir.

Esto significa que un artículo de solución de problemas de 2023 que afirma que "RabbitMQ debe ser el cuello de botella" puede resultar irrelevante para una instancia actual de Community Edition. Identifique la imagen y la versión que realmente utiliza:

docker inspect documentserver --format '{.Config.Image}'
docker image ls onlyoffice/documentserver

El registro de cambios oficial de ONLYOFFICE Docs indica que la versión 9.4.0 se lanzará el 20 de mayo de 2026. El anuncio de lanzamiento de Docs 9.4 del proveedor explica el cambio de arquitectura de la edición Community.

7. Habilite temporalmente el registro de depuración y correlacione este con el retardo.

ONLYOFFICE proporciona una variable de entorno de Docker documentada para el registro de depuración. Para una breve ventana de solución de problemas, agregue:

DS_LOG_LEVEL=DEBUG

A continuación, recree o reinicie el contenedor correspondiente según su método de implementación y siga los registros:

docker logs -f documentserver
# Docker Compose:
docker compose logs -f documentserver

La documentación oficial indica que los registros de Docker también están disponibles dentro /var/log/onlyoffice/documentserverdel contenedor y en el directorio de registros correspondiente montado en el host, si se monta. El registro del convertidor es útil cuando la apertura o conversión de archivos es lenta, mientras que los problemas de coautoría deben correlacionarse con los registros del servidor de documentos y las observaciones del navegador y la red.

Desactive la depuración (DEBUG) después de recopilar la información necesaria. El registro detallado (verbose logging) sirve para el diagnóstico, no como una configuración de rendimiento permanente. Siga el procedimiento del proveedor en la sección " Habilitar el registro de depuración" de la documentación de ONLYOFFICE .

8. Actualice con cuidado si está utilizando una imagen antigua.

Si la implementación está muy por detrás de la versión compatible, una actualización puede incluir correcciones de errores y mejoras de arquitectura. Sin embargo, «descargar la última versión y reiniciar» no es una solución segura para optimizar el rendimiento en un servidor de colaboración en producción.

Primero, registra la etiqueta de imagen actual, el archivo de composición, la configuración JWT, los volúmenes montados, la configuración del proxy inverso y la configuración de integración. Utiliza una versión fija cuando tu proceso de cambio requiera reproducibilidad. La guía de instalación de Docker de ONLYOFFICE documenta cómo especificar una versión concreta, y el registro de cambios oficial te indica qué se ha modificado.

Antes de detener intencionadamente un servidor de documentos de producción con mucha actividad, siga las instrucciones de apagado de ONLYOFFICE para su edición e implementación, de modo que las sesiones de edición activas se gestionen de forma segura. No utilice un documento de referencia que contenga trabajo de usuario sin guardar para realizar la prueba de actualización.

Cómo el caso hipotético reduce las posibilidades de encontrar la solución real.

Regresa al equipo de ejemplo con seis coeditores. El resultado de la resolución de problemas depende de lo que observes:

Una base práctica para implementaciones de Docker

Para una instalación pequeña autoalojada, comience con los requisitos mínimos publicados por ONLYOFFICE, pero ajuste el tamaño según su actividad concurrente real en lugar del total de usuarios registrados. Mantenga registros persistentes y la caché en un almacenamiento con latencia predecible. Evite límites estrictos de CPU o memoria a menos que haya medido la carga de trabajo. Evite que el propio host de Docker utilice la memoria virtual durante la edición normal.

Instale ONLYOFFICE detrás de una configuración de proxy inverso basada en los ejemplos compatibles del proveedor, conservando las actualizaciones de WebSocket y los encabezados de host/protocolo reenviados. Supervise el servidor durante la edición colaborativa, no solo cuando esté inactivo. Si necesita información más detallada, habilite temporalmente el registro de depuración y correlacione las marcas de tiempo del registro con el comportamiento de WebSocket del navegador y las métricas del host.

Qué no hacer

• No modifiques valores no documentados local.jsonsolo porque una publicación en un foro los denomine "ajustes de rendimiento".
• No dé por sentado que un WebSocket persistente que aparece como "pendiente" está roto; se espera que los WebSockets tengan una vida útil prolongada.
• No añada Redis, RabbitMQ ni PostgreSQL solo porque un diagrama de despliegue antiguo los utilizara. Primero, compruebe la arquitectura de su edición y versión.
• No desactive la verificación TLS, la seguridad JWT ni las protecciones de proxy como atajo para reducir la latencia.
• No compare la métrica de un servidor inactivo con el período en el que los usuarios realmente reportan retrasos.
• No actualice una instancia de producción sin conservar los volúmenes, la configuración y una ruta de reversión.

En resumen

La lentitud en la edición conjunta de ONLYOFFICE se soluciona más fácilmente si se trata como un problema de sistema cuantificable. Reproduzca la demora, observe los recursos de Docker y del host bajo carga, verifique el almacenamiento, confirme que el navegador mantiene una conexión WebSocket estable a través de cada proxy e inspeccione los registros solo durante el intervalo de tiempo en que se produce la lentitud. Una vez que sepa si el cuello de botella se debe a la capacidad de procesamiento, la memoria, el disco, el comportamiento de la red/proxy o un cambio específico de versión/configuración, la solución será específica en lugar de especulativa.

Para obtener detalles sobre la implementación actual, consulte la documentación de instalación de ONLYOFFICE Docker , los ejemplos oficiales de proxy inverso , la guía de registro de depuración y el registro de cambios de Docs oficial .