NextCloud на PHP или OpenCloud на Go: что вы получите на практике

В 2016 году NextCloud оторвался от ownCloud, чтобы идти дальше под лицензией AGPL. Спустя десять лет это уже не просто файлообменник, а целая платформа с сотнями приложений, десятками тысяч установок и репутацией корпоративного решения. Параллельно родился OpenCloud — форк ownCloud Infinite Scale, переписанный с нуля на Go и заточенный исключительно на скорость. Две ветки, один предок, противоположные архитектуры. Один монолит на PHP с Redis и MySQL, другой — набор микросервисов на Go, где каждый компонент живёт своей жизнью. И единственное, что их объединяет, — оба считают ownCloud своим предком.

Разница становится очевидной с первых минут. NextCloud можно развернуть на одном сервере: Apache или Nginx, PHP-FPM, Redis, MySQL — и уже через час получить работающую систему с группами, календарём, контактами и встроенной галереей. OpenCloud в базовой комплектации выглядит иначе: Go-бэкэнд, фронтенд на TypeScript, поддержка WebDAV, gRPC и Microsoft Graph API, а в коробке — только файлы и поиск. Функции вроде редактирования документов через Collabora, календари через Radicale или синхронизацию контактов требуют отдельных контейнеров, прокси и долгой настройки. В одном случае скорость зависит от разогнанного PHP и кэша, в другом — от оркестрации контейнеров и пропускной способности сети.

Для команды из пятнадцати человек разница может казаться незначительной. Но как только нагрузка переваливает за сотню пользователей, а файлы достигают гигабайтов, начинаются различия, которые не исправить одной строчкой в конфигурационном файле.

Реальный опыт: две системы, один результат

Два года назад в некоммерческой организации с пятьюстами сотрудниками встали перед выбором. Вариант A: NextCloud на виртуальной машине 16 ядер/64 ГБ с Apache, Redis и MySQL. После недели настройки — OPcache, Redis для блокировок, оптимизация PHP-FPM с pm.max_children=120 — система худо-бедно потянула нагрузку. Но синхронизация больших файлов (>1 ГБ) тормозила так, что пользователи с ноутбуками 2018 года не могли завершить загрузку. Администратор в чате написал: «Collabora рендерит презентации по полторы минуты. Приходится объяснять, что не у всех рабочие станции из 2026 года».

Вариант B: OpenCloud в Docker Swarm с тремя контейнерами — основной сервер, WOPI-прокси для Collabora и сам Collabora в контейнере. Чтобы всё заработало, понадобился Nginx Proxy Manager, сертификаты Let’s Crypt и настройка gRPC. Синхронизация файлов стала почти мгновенной, интерфейс — минималистичным. Зато пропали группы, которые так удобно использовать для разделения доступа по отделам. Команда смирилась с отсутствием привычных функций. Через два месяца они начали бояться обновлений — слишком много движущихся частей, слишком много мест, где что-то может сломаться.

Разницу здесь не спишешь на «лучше» или «хуже». NextCloud перекладывает нагрузку на кэш и СУБД. OpenCloud — на оркестрацию. И если в вашей команде нет специалиста по Go и Docker, «быстрая» система OpenCloud станет источником постоянных проблем.

Минимализм против экосистемы

OpenCloud позиционирует себя как «приватную» альтернативу: по умолчанию администратор не имеет доступа к содержимому папок пользователей. NextCloud, напротив, открыт для интеграций — от офисных пакетов до чатов и CRM. В результате OpenCloud предлагает минимализм, NextCloud — экосистему.

Но минимализм требует жертв. В OpenCloud 6.0 «Избранное», калькулятор в поиске и расширение Pastebin — это уже всё. В NextCloud доступны расширенные права доступа, шаблоны, опросы, потоковое видео, подключение к Active Directory и десятки других модулей из каталога приложений. Для университета или госучреждения это критично. Для стартапа, где главное — быстрый файлообмен без лишних функций, — избыточно.

При этом Go-бэкэнд OpenCloud изначально заточен под большие объёмы и высокую нагрузку. Поддержка Graph API и gRPC позволяет интегрироваться с корпоративными системами, а микросервисная архитектура — горизонтально масштабировать. Но за скорость приходится платить сложностью развёртывания: Collabora, Radicale для календарей и контактов, ключи OpenID Connect — каждая опция требует отдельной настройки и обновления.

NextCloud использует проверенные временем решения: PHP-FPM, Redis, MySQL/PostgreSQL. Да, он медленнее в сыром виде. Но после настройки кэша и оптимизации запросов система стабилизируется, а новые функции добавляются через магазин приложений без пересборки ядра.

Что ломается в бою

Скорость — не абстракция.

В NextCloud узкое место — PHP и его GIL. Даже с Redis и OPcache веб-интерфейс может подтормаживать при сотнях одновременных сессий. В OpenCloud узкое место — сеть и контейнеризация: если Docker Swarm начинает переподнимать упавшие контейнеры, пользователи получают разрывы соединений при загрузке файлов.

Реальные истории подтверждают это. На форуме OpenCloud пользователь пишет, что после обновления до версии 6.0 начались «скачки памяти в wopi-контейнере при одновременном редактировании трёх документов». В ветке NextCloud администратор жалуется: «После миграции на PostgreSQL и включения Redis производительность восстановилась, но Collabora всё равно тормозит при рендеринге сложных таблиц».

В обоих случаях проблема не в языке или фреймворке, а в архитектуре. NextCloud накапливает технический долг. OpenCloud — операционный. И если первый можно уменьшить настройками, то вторые проблемы требуют эксперта, которого не всегда удаётся найти.

Так всё-таки что выбрать?

Если вам нужна система, которую можно поставить и забыть на три года, выбирайте NextCloud. Да, он медленнее в базовой конфигурации. Зато проверен на десятках тысяч установок, у него есть сообщество, документация, а для критичных функций — готовые решения.

Если ваша задача — скорость и контроль, при этом вы готовы терпеть сложности с оркестрацией и отсутствие привычных функций, OpenCloud может оказаться лучше. Но помните: его «приватность по умолчанию» достигается за счёт отсутствия расширенных инструментов администрирования, а «масштабируемость» оборачивается необходимостью разбираться в gRPC и Docker.

В итоге выбор сводится к одной простой дилемме: готовы ли вы платить за скорость сложностью, или предпочитаете платформу с понятными граблями и проверенной надёжностью. Третьего не дано.