Офисный пакет без облачной подписки: что ставить на свой сервер

MAATRIX

Если компания уже перевела мессенджер, видеосвязь или почту на свою инфраструктуру, рано или поздно встаёт последний и самый неудобный вопрос — куда девать совместное редактирование документов, таблиц и презентаций. Это не один продукт, который можно поставить одной командой, а связка из нескольких сервисов, которую нужно правильно собрать и не разочароваться в процессе. Разберём, из чего на самом деле состоит self-hosted офисный пакет, сколько ему нужно железа под реальную одновременную работу команды и где он честно не дотягивает до привычного облачного опыта.

Что закрывает облачный офисный пакет и из чего он состоит у вас

Google Workspace и Microsoft 365 продают ощущение единого продукта, но внутри это минимум три независимых слоя: хранилище файлов с историей изменений, движок совместного редактирования прямо в браузере и слой доступа — ссылки, права, комментарии, поиск по содержимому. В облаке вы этого не замечаете, потому что все три слоя разработаны одной компанией и склеены бесшовно.

На своём сервере эти слои приходится собирать из разных продуктов, и это первое, что нужно понять перед тем, как что-то ставить:

• Файловое хранилище с версиями — Nextcloud или Seafile. Здесь живут сами файлы, права доступа, публичные ссылки, история версий.
• Движок совместного редактирования — OnlyOffice Document Server или Collabora Online. Сам по себе он не хранит файлы, а подключается к хранилищу как плагин и открывает документы в браузере через протокол WOPI.
• База данных и кеш — PostgreSQL/MySQL и Redis под хранилище, плюс своя СУБД или очередь у некоторых сборок редактора.
• Reverse-proxy с SSL — обязательный слой, без него браузер откажется грузить редактор во фреймворке хранилища из-за смешанного контента.

Это не один сервис, а система из четырёх-пяти движущихся частей, которые нужно поднять, связать между собой и обновлять синхронно. Сложность разворачивания — не в каждом отдельном компоненте (каждый ставится за вечер), а именно в том, что их несколько и они зависят друг от друга. О переходе с других частей зарубежного цифрового периметра — почты, видеосвязи, подписок — мы писали отдельно, например про полную смету переезда с Google Workspace и про стоимость часа конференции в Zoom против своего Jitsi — офисный пакет в этой связке обычно самый трудоёмкий узел.

Файловый слой: Nextcloud или Seafile

Это фундамент, на котором держится всё остальное, — от него зависит, как хранятся версии документов и насколько удобно расшаривать файлы вовне.

Nextcloud — более тяжёлая, но и более функциональная платформа. Кроме файлов, она закрывает календарь, контакты, заметки, есть готовая экосистема приложений. Версионирование работает «из коробки»: при каждом сохранении файла создаётся снапшот, а retention-политика по умолчанию хранит версии по расширяющемуся интервалу — сначала все за последние сутки, потом по одной в день за неделю, потом по одной в неделю и так далее, пока не упрётся в квоту хранилища пользователя. Это управляется в config.php через параметр versions_retention_obligation, если нужен фиксированный срок вместо адаптивного алгоритма.

Seafile — более лёгкая архитектура, изначально заточенная под синхронизацию и версионирование, а не под универсальный «облачный комбайн». История версий здесь встроена на уровне библиотеки (repo history) и работает по блочному дедуплицированному хранению — при правках больших файлов Seafile пересылает и хранит только изменившиеся блоки, а не копию целиком, что заметно экономит диск при активной работе с большими таблицами и презентациями. Совместное редактирование через OnlyOffice/Collabora в Seafile тоже доступно, но интеграция и полнота функций отличаются от версии к версии — перед выбором стоит свериться с актуальной документацией на сайте Seafile для вашей редакции (Community/Pro), а не полагаться на то, что было верно год назад.

Прямое сравнение по ресурсам, скорости синхронизации и сценариям есть в отдельном разборе — Nextcloud или Seafile: что выгоднее и когда. Если решение уже склоняется в сторону Nextcloud как более распространённого и документированного варианта, пошаговая установка описана в статье как установить и настроить Nextcloud на VPS.

Движок совместного редактирования поверх хранилища

Сам по себе Nextcloud или Seafile умеет только хранить .docx/.xlsx/.pptx как обычные файлы — открыть их для совместного редактирования в браузере без отдельного движка нельзя. Здесь в игру вступает OnlyOffice Document Server или Collabora Online (CODE, обёртка над LibreOffice).

Оба подключаются как плагин к хранилищу через WOPI-протокол: хранилище отдаёт документ движку, движок рендерит его в браузере как отдельный iframe и синхронизирует правки нескольких пользователей в реальном времени, а сохранённый результат уходит обратно в хранилище как новая версия файла.

Выбор между ними — это компромисс между ресурсами сервера (Collabora легче) и совместимостью с форматами Microsoft Office (OnlyOffice точнее воспроизводит вёрстку сложных .docx/.xlsx для внешних контрагентов). Разбирать это подробно здесь избыточно — есть отдельная статья с таблицами и практическими критериями выбора: OnlyOffice или Collabora Online: что выгоднее и когда. Если коротко: для команды до 10 человек на бюджетном VPS с редким редактированием внутренних документов обычно берут Collabora, для активного обмена договорами и презентациями с внешними MS Office-пользователями — OnlyOffice.

Как всё собирается в одну систему

Полный стек на одном сервере через Docker Compose выглядит примерно так (упрощённый скелет, без переменных окружения секретов):

services:
  db:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_DB=nextcloud
      - POSTGRES_USER=nextcloud
      - POSTGRES_PASSWORD=ЗамениНаСложныйПароль
    volumes:
      - db_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    restart: always

  nextcloud:
    image: nextcloud:29-apache
    restart: always
    depends_on:
      - db
      - redis
    environment:
      - POSTGRES_HOST=db
      - REDIS_HOST=redis
    volumes:
      - nc_data:/var/www/html

  office:
    image: collabora/code:latest
    restart: always
    environment:
      - domain=cloud\\.example\\.com
      - extra_params=--o:ssl.enable=false --o:ssl.termination=true
    cap_add:
      - MKNOD

volumes:
  db_data:
  nc_data:

Перед контейнером office обязателен reverse-proxy (Caddy или Nginx) с проксированием WebSocket-соединений — Collabora держит постоянное сокет-подключение для синхронизации правок в реальном времени, и без правильных заголовков Upgrade/Connection совместное редактирование будет рваться каждые несколько секунд. Пример нужных директив для Nginx:

location /cool/ {
    proxy_pass http://127.0.0.1:9980;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_read_timeout 36000s;
}

Для OnlyOffice логика аналогичная, но проксируется другой набор путей и добавляется поддержка WOPI discovery на /hosting/discovery. Отдельно не забудьте client_max_body_size на прокси и в самом Nextcloud (php.ini, параметр upload_max_filesize) — иначе загрузка презентаций с видео или тяжёлых таблиц с картинками будет обрываться на дефолтных 1-2 МБ лимита PHP.

Сколько нужно железа под одновременное редактирование

Здесь у self-hosted стека принципиально другая экономика по сравнению с обычным файловым хранилищем: нагрузка растёт не от объёма данных, а от числа людей, которые редактируют документы одновременно прямо сейчас. Один открытый на просмотр документ почти ничего не стоит, один документ с 5-10 одновременными правками — уже заметная нагрузка на CPU движка конвертации.

Ориентировочные цифры по опыту эксплуатации, не результат стендового бенчмарка — у вас нагрузка может отличаться в зависимости от размера документов, версии ПО и типа правок (текст легче, чем таблицы со сложными формулами):

Практический вывод: для команды до 30 человек хранилище и редактор без проблем живут на одном сервере среднего размера. После 50 человек с активным одновременным редактированием редактор стоит выносить на отдельный VPS — иначе всплеск конвертации нескольких тяжёлых файлов одновременно начинает подтормаживать и файловое хранилище для всех остальных, кто просто открывает страницы или синхронизирует папки.

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

Честно: где self-hosted не хуже облака, а где ждать компромиссов

Это, наверное, самый важный раздел статьи, потому что реклама self-hosted решений обычно замалчивает вторую половину.

Где действительно не хуже:

• Базовое совместное редактирование текста и простых таблиц несколькими людьми — работает предсказуемо, ощущается как Google Docs, разница малозаметна за пределами больших нагрузок.
• Хранение и версии документов — Nextcloud/Seafile справляются не хуже облачного диска, а иногда даже прозрачнее, потому что вы сами видите и настраиваете правила хранения версий, а не зависите от политики вендора.
• Приватность и контроль — документы физически не покидают ваш сервер, что критично для юридических и финансовых данных, где это принципиальный вопрос, а не вопрос удобства.
• Стоимость при росте команды — вы платите за железо, а не за количество лицензий на человека, поэтому при команде от 20-30 человек экономика почти всегда в пользу своего сервера.

Где стоит ожидать компромиссов:

• Мобильные приложения. Официальные клиенты Nextcloud и Seafile для синхронизации файлов зрелые, но полноценного редактирования документов с удобством нативного мобильного Google Docs/Office в них нет — на телефоне вы, скорее всего, будете открывать документ через мобильный браузер.
• Полнотекстовый поиск по содержимому документов. В облаке он работает из коробки и мгновенно. В self-hosted стеке для поиска внутри содержимого файлов (а не только по названию) нужно отдельно поднимать и поддерживать полнотекстовый индекс (например, приложение Full Text Search для Nextcloud поверх Elasticsearch) — это ещё один сервис, ещё одна точка отказа.
• AI-функции внутри документов. Автодополнение, суммаризация, генерация черновика прямо в редакторе — то, что активно продвигают и Google, и Microsoft последние пару лет — в self-hosted редакторах либо отсутствует, либо доступно только как платное расширение с подключением стороннего API, а не встроенная бесплатная фича.
• Комментарии и совместное рецензирование на уровне полировки. Базовые комментарии есть в обоих движках, но нюансы вроде предложенных правок (track changes) с принятием/отклонением у конкретного автора реализованы менее гладко, чем в Microsoft Word или Google Docs, — это заметно командам, которые активно рецензируют юридические документы.
• Ответственность за аптайм и патчи безопасности переходит на вас. Обновления Nextcloud, Collabora/OnlyOffice и базы данных теперь ваша задача, а не задача вендора облака — пропущенное обновление с закрытой уязвимостью на публично торчащем сервисе это не абстрактный риск, а реальный вектор атаки.

Если для команды критичны AI-функции в духе Copilot или идеальный track changes — переход на self-hosted пакет полностью такой опыт не заменит, и это нужно признать заранее, а не разочаровываться после миграции. Если ключевые задачи — совместно редактировать текст и таблицы, хранить версии и не зависеть от чужой юрисдикции — self-hosted стек справляется полностью.

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