Как установить и настроить Collabora Online на VPS

MAATRIX

Если вы уже перенесли файлы в Nextcloud или другое самостоятельно размещённое облако, рано или поздно упрётесь в то, что документы там можно только скачать и открыть локально — редактировать прямо в браузере нечем. Collabora Online закрывает эту дыру: движок на базе LibreOffice, который рендерит и редактирует .docx/.xlsx/.pptx и .odt/.ods/.odp прямо в веб-интерфейсе, без утечки файлов на сторонние сервисы. Разберём установку на VPS через Docker, настройку HTTPS и подключение к Nextcloud с рабочими конфигами.

Что такое Collabora Online и когда он нужен

Collabora Online (в контейнерах чаще фигурирует под именем CODE — Collabora Online Development Edition) — это серверный движок редактирования офисных документов, построенный на кодовой базе LibreOffice. Сам по себе он не хранит файлы и не имеет файлового менеджера: это WOPI-сервер, к которому подключается «клиент хранения» — Nextcloud, ownCloud, ONLYOFFICE-подобные интеграции через кастомный WOPI-хост или ваше собственное приложение по REST/WOPI-протоколу.

Практический смысл: у вас уже есть Nextcloud на VPS, в котором пользователи хранят документы, но открыть .docx можно только через предпросмотр или скачивание. Ставите рядом Collabora — и в интерфейсе Nextcloud появляется полноценное редактирование в браузере, включая совместную работу нескольких человек над одним файлом в реальном времени.

Ключевое отличие от OnlyOffice (о нём мы писали отдельно — установка OnlyOffice на VPS) — в движке рендеринга: Collabora ближе к «настоящему» LibreOffice и точнее воспроизводит сложное форматирование .odt/.ods, но интерфейс редактирования у части пользователей субъективно выглядит менее современно, чем у OnlyOffice. Однозначного победителя нет — выбор часто определяется тем, какие форматы документов реально ходят в вашей организации и что уже стоит на серверном хранилище.

Как и OnlyOffice Document Server, Collabora — не лёгкий сервис. Каждый открытый документ держит отдельный процесс LibreOffice в памяти, поэтому под несколько одновременных редакторов нужен запас CPU и RAM, а не минимальный тариф «на попробовать».

Требования к серверу и подготовка

Для комфортной работы на 5-15 одновременных редакторов закладывайте:

Память — узкое место в первую очередь: каждый открытый в редактировании документ добавляет 100-200 МБ поверх базового потребления самого контейнера (ориентировочно, зависит от размера и сложности файла — не воспринимайте как гарантированную цифру). Если ставите Collabora на тот же VPS, где уже крутится Nextcloud с базой данных, закладывайте суммарные требования обоих сервисов, а не только Collabora.

Что нужно заранее:

• отдельный поддомен для Collabora, например office.example.com — он не должен совпадать с доменом Nextcloud, WOPI-протокол требует разных origin;
• DNS A-запись на этот поддомен, указывающая на IP вашего VPS;
• установленный Docker и Docker Compose;
• сгенерированный пароль для admin-консоли Collabora — потребуется на этапе настройки.

Проверьте, что порт 443 открыт в файрволе:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp

Установка Collabora Online в Docker

Официальный образ Collabora публикуется в Docker Hub под именем collabora/code. Заводим отдельную директорию под проект:

mkdir -p ~/collabora
cd ~/collabora

Создаём docker-compose.yml:

services:
  collabora:
    image: collabora/code:latest
    container_name: collabora
    restart: unless-stopped
    ports:
      - "127.0.0.1:9980:9980"
    environment:
      - domain=nextcloud\\.example\\.com
      - username=admin
      - password=ЗАМЕНИТЕ_НА_СВОЙ_ПАРОЛЬ
      - DONT_GEN_SSL_CERT=1
      - extra_params=--o:ssl.enable=false --o:ssl.termination=true
    cap_add:
      - MKNOD

Пояснения по переменным:

• domain — регулярное выражение с адресами хостов, которым разрешено обращаться к Collabora (обычно домен вашего Nextcloud). Точки экранированы обратным слешем — это требование формата, не опечатка.
• username/password — учётные данные для встроенной admin-консоли Collabora (доступна по /browser/dist/admin/admin.html внутри контейнера, наружу её лучше не публиковать напрямую, см. раздел про безопасность).
• DONT_GEN_SSL_CERT=1 вместе с ssl.termination=true — Collabora не занимается TLS сама, шифрование терминирует внешний Nginx, а Collabora слушает голый HTTP на 9980 только на loopback-интерфейсе (127.0.0.1:9980) — наружу порт не торчит вообще.

Поднимаем контейнер:

docker compose up -d
docker compose ps

Проверить, что сервис ответил, можно локально:

curl -s http://127.0.0.1:9980/hosting/discovery | head -c 200

Если в ответе пришёл XML с перечнем MIME-типов — контейнер поднялся и готов принимать запросы через реверс-прокси.

Настройка Nginx как reverse-proxy с SSL

Публиковать 9980 наружу без обёртки не стоит: Collabora рассчитывает на TLS-терминацию перед собой и на корректную проксировку WebSocket (без него не будет совместного редактирования в реальном времени). Если Nginx на сервере ещё не настроен как reverse-proxy — сначала пройдите базовую настройку Nginx как reverse-proxy, а SSL получите через Let's Encrypt.

Конфиг для Nginx, /etc/nginx/sites-available/office.example.com:

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;

    # Статика Collabora
    location ^~ /browser {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
    }

    # WOPI-обмен
    location ^~ /wopi/ {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
    }

    # Capabilities / discovery
    location ^~ /hosting/ {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
    }

    # WebSocket-канал совместного редактирования
    location ~ ^/cool/(.*)/ws$ {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
    }

    location ^~ /cool/ {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $host;
    }

    client_max_body_size 200M;
}

Обратите внимание на proxy_read_timeout 3600s для WebSocket-локации — без увеличенного таймаута Nginx рвёт соединение при долгом простое во время редактирования, и совместная работа периодически «отваливается» с сообщением о потере связи.

Пути /cool/... актуальны для современных версий образа (раньше использовался префикс /loleaflet/) — если после установки какой-то путь возвращает 404, проверьте актуальную схему через curl http://127.0.0.1:9980/hosting/discovery — там перечислены реальные URL, которые отдаёт именно ваша версия образа.

Активируем конфиг и перезапускаем Nginx:

sudo ln -s /etc/nginx/sites-available/office.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Подключение Collabora к Nextcloud

Дальше — интеграция. В Nextcloud заходим под администратором в Приложения и ставим Nextcloud Office (в части версий приложение всё ещё называется «Collabora Online» или «richdocuments» — суть та же).

После активации идём в Настройки → Администрирование → Nextcloud Office и указываем URL вашего Collabora:

https://office.example.com

Nextcloud сам постучится по адресу /hosting/discovery и подтвердит, что сервер доступен и отвечает корректно. Если появляется ошибка «Collabora Online server is not reachable» — почти всегда дело в одном из трёх мест:

1. Nginx-конфиг не проксирует один из путей (/hosting/, /cool/, /browser) — проверьте построчно через curl -I.
2. Значение domain в docker-compose.yml не совпадает с реальным доменом Nextcloud (регулярка не матчится — Collabora отклоняет запрос).
3. Между Nextcloud и Collabora стоит файрвол/CDN-прокси (Cloudflare в проксирующем режиме и подобные), который режет WebSocket-апгрейд — для этого домена такие прокси обычно приходится переводить в режим DNS-only.

После успешного подключения откройте любой .docx-файл в Nextcloud — вместо предпросмотра должен запуститься полноценный редактор в отдельной вкладке интерфейса. Проверьте совместное редактирование, открыв один файл с двух разных аккаунтов — курсор второго пользователя должен быть виден в реальном времени.

Если позже понадобится сравнить это решение с готовым офисным пакетом на другом движке — у нас есть отдельный обзор OnlyOffice на VPS, архитектура интеграции с Nextcloud там похожая, но CPU/RAM-профиль и точность рендеринга сложных таблиц заметно отличаются.

Безопасность: WOPI, admin-консоль и ограничение доступа

По умолчанию встроенная admin-консоль Collabora доступна по пути /browser/dist/admin/admin.html через тот же порт 9980. Если вы проксируете /browser наружу (а без этого не заработает сам редактор), консоль администрирования тоже становится теоретически достижимой — защититься стоит на нескольких уровнях:

• Смените пароль по умолчанию в переменных username/password — оставленный дефолт это первое, что проверяют автоматические сканеры.
• Закройте admin-консоль на уровне Nginx отдельным правилом с ограничением по IP, если заходите туда только вы:

location ^~ /browser/dist/admin/ {
    allow 203.0.113.10;  # ваш IP
    deny all;
    proxy_pass http://127.0.0.1:9980;
}

• Ограничьте domain в docker-compose.yml реальным списком хостов, которым разрешено обращаться к WOPI — не оставляйте регулярку вида .*, которая пускает вообще любой источник.
• Включите fail2ban для Nginx, если сервис смотрит в интернет напрямую — это блокирует автоматический перебор и сканеры на уровне доступа к порту.
• Держите образ обновлённым: docker compose pull && docker compose up -d раз в 1-2 месяца — уязвимости в движке рендеринга документов закрываются регулярно, и откладывать обновления на офисном редакторе, через который проходят чужие файлы, не стоит.

Отдельно: если Collabora стоит рядом с Nextcloud на одном VPS, изолируйте контейнеры друг от друга через отдельные Docker-сети и не публикуйте порты сервисов наружу без необходимости.

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