OnlyOffice в Docker Compose: готовый файл

MAATRIX

Если команда работает с .docx/.xlsx/.pptx, а Google Docs не подходит по политике безопасности или геополитике, остаётся два варианта: покупать корпоративную лицензию Microsoft 365 или поднять собственный офисный сервер. OnlyOffice Document Server — open-source движок, который редактирует документы прямо в браузере и совместим с форматами Office почти без потери форматирования. Ниже — рабочий docker-compose.yml, который поднимает сервер за один запуск, плюс всё, что вокруг него обычно ломается: JWT, домен, SSL и интеграция с файловым хранилищем.

Что такое OnlyOffice Document Server и зачем он нужен

OnlyOffice Document Server — это не облачный сервис, а самостоятельный компонент, который сам по себе не хранит файлы. Он получает документ по URL, рендерит его в браузере через связку JavaScript + Web Components и отдаёт обратно изменённую версию. Хранилищем и точкой входа для пользователей выступает другая система — Nextcloud, ownCloud, Seafile, собственное веб-приложение через API, или связка с почтовым/CRM-сервисом.

Отсюда практический вывод: сам по себе Document Server — это "движок редактирования", а не готовый файловый портал. Если нужен именно портал с папками, правами доступа и историей версий "из коробки", разумнее сразу разворачивать Nextcloud на Ubuntu 24.04 и подключать к нему OnlyOffice как плагин редактирования. Если же нужен только движок для встраивания в собственное приложение через REST API — хватит связки из этой статьи без Nextcloud.

Есть два дистрибутива: Community Edition (бесплатная, с ограничением на одновременные подключения — по данным вендора, порядка 20 одновременных соединений на редактирование, но это лимит именно у Community-сборки, а не жёсткое ограничение Docker-образа) и Enterprise Edition (платная, без лимита, с поддержкой). В этой статье — Community Edition, её достаточно для команды до 15-20 человек с умеренной интенсивностью совместного редактирования.

Требования к серверу

Document Server — тяжёлый компонент: внутри контейнера крутятся конвертеры документов (на базе LibreOffice-совместимых движков), а совместное редактирование держит WebSocket-соединения на каждого активного пользователя.

Официально вендор рекомендует для продакшена от 4 CPU и 8 ГБ RAM — это ориентир для рабочей нагрузки с несколькими одновременными редакторами, конкретные цифры у вас будут отличаться в зависимости от размера документов и числа параллельных сессий. Для тестового стенда или личного использования 1-2 пользователями реально хватает 2 vCPU и 4 ГБ RAM, но конвертация больших файлов (презентации с изображениями, таблицы на десятки тысяч строк) будет заметно медленнее и может упираться в память.

Диск важен не только под сам образ (весит несколько гигабайт), но и под временные файлы конвертации и кэш — при активной работе с большими документами кэш растёт быстро, стоит закладывать запас.

Готовый docker-compose.yml

Минимальная рабочая конфигурация — один контейнер с встроенными сервисами (PostgreSQL, RabbitMQ, Redis идут внутри образа для базовой нагрузки, отдельно поднимать их не нужно):

version: "3.8"

services:
  onlyoffice-documentserver:
    image: onlyoffice/documentserver:8.2
    container_name: onlyoffice-documentserver
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
    environment:
      - JWT_ENABLED=true
      - JWT_SECRET=${ONLYOFFICE_JWT_SECRET}
      - JWT_HEADER=Authorization
      - JWT_IN_BODY=true
    volumes:
      - onlyoffice_data:/var/www/onlyoffice/Data
      - onlyoffice_log:/var/log/onlyoffice
      - onlyoffice_cache:/var/lib/onlyoffice/documentserver/App_Data/cache/files
      - onlyoffice_forgotten:/var/lib/onlyoffice/documentserver/App_Data/docbuilder
      - onlyoffice_fonts:/usr/share/fonts/truetype/custom
    shm_size: 1gb
    ulimits:
      nofile:
        soft: 65536
        hard: 65536

volumes:
  onlyoffice_data:
  onlyoffice_log:
  onlyoffice_cache:
  onlyoffice_forgotten:
  onlyoffice_fonts:

Порт контейнера привязан только к 127.0.0.1:8080 — наружу сервис отдаёт Nginx, о нём ниже. shm_size: 1gb не опциональный параметр: конвертер документов активно использует /dev/shm, и с дефолтными 64 МБ Docker конвертация больших файлов будет падать с непонятными ошибками в логах.

Секрет для JWT храните в .env рядом с compose-файлом:

# .env
ONLYOFFICE_JWT_SECRET=сгенерированная-длинная-случайная-строка

Сгенерировать строку можно так:

openssl rand -hex 32

JWT, переменные окружения и persistent-данные

JWT (JSON Web Token) — обязательная вещь для продакшена, не опция "для параноиков". Без него любой, кто знает адрес вашего Document Server, может отправить на него запрос конвертации произвольного файла — это открытая точка входа без аутентификации. С JWT_ENABLED=true каждый запрос между вашим приложением (или Nextcloud-коннектором) и Document Server подписывается общим секретом, и сервер отклоняет всё, что подписано неверно.

Ключевой нюанс: секрет из ONLYOFFICE_JWT_SECRET должен совпадать с тем, что вы укажете в настройках коннектора — например, в приложении OnlyOffice для Nextcloud. Если секреты не совпадают, документы просто перестают открываться с ошибкой вида "download failed" без внятного объяснения причины.

Volumes в конфиге выше — это не формальность:

• onlyoffice_data — шаблоны, кэш конвертации, служебные данные самого сервера;
• onlyoffice_log — логи, полезны при отладке (сервер логирует довольно подробно);
• onlyoffice_cache — файлы, которые редактируются прямо сейчас (совместные сессии хранят состояние здесь);
• onlyoffice_forgotten — "забытые" документы, которые не успели сохраниться при сбое соединения — полезная страховка, не удаляйте этот том без причины;
• onlyoffice_fonts — сюда можно докинуть кастомные шрифты (например, кириллические, которых не хватает в базовой сборке), чтобы документы с ними корректно рендерились и конвертировались.

Проверить, что контейнер поднялся и внутренние сервисы стартовали, можно через встроенный скрипт диагностики:

docker exec -it onlyoffice-documentserver bash -c "supervisorctl status"

Все процессы (docservice, converter, spellchecker, metrics и т.д.) должны быть в статусе RUNNING. Если что-то в FATAL — почти всегда причина в нехватке памяти или в правах на volume.

Публикация через Nginx и SSL

Document Server слушает 127.0.0.1:8080, наружу его отдаёт reverse-proxy с доменом и SSL-сертификатом — без HTTPS браузер будет блокировать часть функций редактора (например, доступ к буферу обмена), да и передавать документы по открытому HTTP небезопасно в принципе.

Если Nginx на сервере ещё не настроен как reverse-proxy — вот подробная инструкция: Nginx как reverse-proxy на VPS. Конфиг для домена office.ваш-домен.ru:

server {
    listen 80;
    server_name office.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name office.example.com;

    ssl_certificate     /etc/letsencrypt/live/office.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/office.example.com/privkey.pem;

    client_max_body_size 100m;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /doc/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }
}

Блок /doc/ с заголовками Upgrade/Connection — не косметика, а обязательное условие. Именно через этот путь идут WebSocket-соединения совместного редактирования; без него редактор откроется, но realtime-совместная работа не заработает или будет рваться каждые несколько секунд.

Сертификат получаете стандартно через certbot — подробный разбор с частыми ошибками есть в статье про Let's Encrypt на VPS. Если хотите вообще не думать про продление сертификатов вручную — Caddy с автоматическим SSL тоже подходит как альтернатива Nginx для этой связки.

После публикации проверьте здоровье сервера открыв в браузере https://office.example.com/healthcheck — должен вернуться просто true.

Интеграция с Nextcloud, ownCloud и другими системами

Самый частый сценарий — подключение к Nextcloud. Порядок действий:

1. В Nextcloud устанавливаете приложение "ONLYOFFICE" через встроенный каталог приложений (Settings → Apps).
2. В настройках приложения (Settings → Administration → ONLYOFFICE) указываете адрес Document Server — https://office.example.com/.
3. Вставляете тот же JWT-секрет, что в .env вашего compose-файла.
4. Сохраняете — Nextcloud проверит соединение и покажет "Successfully connected" при успехе.

После этого клик по .docx/.xlsx/.pptx файлу в Nextcloud открывает его прямо в браузере через OnlyOffice, а не скачивает на диск. Совместное редактирование, комментарии и история версий работают через связку Nextcloud (хранение) + Document Server (рендеринг).

Для собственных приложений интеграция идёт через прямой REST API и JavaScript SDK Document Server — на страницу редактора подключается скрипт api.js с самого Document Server, и в конфиг редактора передаётся URL документа, callback-адрес для сохранения и подписанный JWT-токен. Это чуть больше кода, чем готовый Nextcloud-плагин, зато не тянет за собой весь Nextcloud, если он вам не нужен как файловое хранилище.

Отдельная база данных и очередь сообщений (PostgreSQL + RabbitMQ) из compose-файла выше работают внутри контейнера и достаточно для одного инстанса. Если планируете горизонтальное масштабирование (несколько Document Server за балансировщиком под высокую нагрузку), их нужно вынести наружу через переменные DB_TYPE, DB_HOST, AMQP_URI и так далее — но для одного сервера, о котором эта статья, это избыточно.

Частые вопросы