Mattermost или Rocket.Chat: что выгоднее и когда

MAATRIX

Оба продукта решают одну задачу — увести команду со Slack или Discord на свой сервер, но выбор между ними редко очевиден с первого взгляда на лендинги: там одинаковые слова «каналы», «интеграции», «self-hosted». Разница всплывает позже — на этапе развёртывания, когда выясняется, что один требует реплика-сет MongoDB, а второй тянет за собой отдельный поисковый движок под нагрузкой. Разберём архитектуру, ресурсы и типичные сценарии, чтобы решение принималось не по маркетингу, а по тому, что реально придётся обслуживать.

Mattermost и Rocket.Chat: разница на уровне архитектуры

Mattermost написан на Go и разворачивается связкой из двух компонентов: сам сервер приложения и PostgreSQL (или MySQL) как хранилище. Поиск по умолчанию идёт через саму базу, WebSocket-соединения держит бинарник на Go — процесс с предсказуемым и относительно экономным потреблением памяти на одно соединение.

Rocket.Chat построен на Node.js (Meteor) и MongoDB — но не просто MongoDB, а обязательно с репликасетом, даже если у вас один сервер и один узел базы. Причина в change streams: реалтайм-обновления (новые сообщения, статусы прочтения, присутствие) в Rocket.Chat построены на этом механизме MongoDB, а он работает только поверх replica set. Попытка поднять mongod командой «как есть» без инициализации репликасета закончится ошибкой в логах и мессенджером без реалтайма.

Коротко: Mattermost проще держать в узком составе сервисов и удобнее для инженерных команд с интеграциями в GitHub/GitLab/Jira, Rocket.Chat выигрывает там, где нужен омниканал и общение с внешними клиентами — Telegram и WhatsApp прямо в интерфейсе агента, а не отдельным ботом сбоку.

Развёртывание: что стоит за «docker compose up» в каждом случае

У Mattermost путь короче и предсказуемее — минимальный рабочий docker-compose.yml:

services:
  mattermost:
    image: mattermost/mattermost-team-edition:10.5
    depends_on:
      - postgres
    environment:
      - MM_SQLSETTINGS_DATASOURCE=postgres://mmuser:mmpass@postgres:5432/mattermost?sslmode=disable
    volumes:
      - ./data:/mattermost/data
      - ./config:/mattermost/config
    ports:
      - "8065:8065"
    restart: unless-stopped

  postgres:
    image: postgres:16
    environment:
      - POSTGRES_USER=mmuser
      - POSTGRES_PASSWORD=mmpass
      - POSTGRES_DB=mattermost
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    restart: unless-stopped

Полный разбор переменных и первого запуска — в статье как установить и настроить Mattermost на VPS.

У Rocket.Chat добавляется обязательный шаг — инициализация репликасета MongoDB. Без него сервис либо не стартует, либо работает в деградированном режиме без обновлений в реальном времени:

docker exec -it rocketchat-mongo mongosh --eval \
  'rs.initiate({_id: "rs0", members: [{_id: 0, host: "mongo:27017"}]})'

Это не разовая настройка «поставил и забыл» — при переносе на другой сервер или восстановлении из бэкапа репликасет нужно инициализировать заново, и если про этот шаг забыть, мессенджер поднимется, но перестанет обновлять статусы и сообщения без ручного обновления страницы. Пошаговая установка без Docker — в статье Rocket.Chat на Ubuntu 24.04.

Ресурсы: сколько RAM и CPU закладывать

Для небольшой команды (15-30 человек, обычная переписка без активных звонков) оба варианта укладываются в 4 GB RAM на связку «приложение + база», но профиль потребления разный:

• Mattermost — Go-бинарник держит память стабильно и предсказуемо на одно WebSocket-соединение, PostgreSQL с дефолтным shared_buffers = 128MB из коробки не самый эффективный, но тюнится напрямую и без сюрпризов. Ориентир для команды до 50 человек — 2-4 GB суммарно на оба контейнера.
• Rocket.Chat — Node.js процесс без явного ограничения NODE_OPTIONS может раздувать V8 heap до 1,5-2 GB сам по себе, а MongoDB с движком WiredTiger резервирует под свой кеш до половины доступной RAM хоста минус 1 GB — это резервирование, а не жёсткое потребление, но на слабом сервере (2 GB и меньше) оно оставляет мало места на всё остальное.

# формула WiredTiger cache для MongoDB
cache_size = max((RAM - 1GB) / 2, 256MB)

Для более точных цифр по каждому продукту — отдельные разборы: сколько RAM нужно для Mattermost и сколько RAM нужно для Rocket.Chat. Общий вывод из обоих: закладывайте нижнюю границу диапазона под свой размер команды и ставьте docker stats под регулярную проверку с первого дня, а не полагайтесь на официальные минимумы в документации — оба продукта в реальности требуют заметно больше, чем указано на лендинге.

Звонки и омниканальность — где какой сильнее

Здесь продукты расходятся сильнее всего, и это часто решающий фактор.

Mattermost Calls — встроенный видеозвонок работает через SFU-медиасервер (mediasoup), который живёт прямо в контейнере Mattermost, отдельный сервис поднимать не нужно. Плюс — меньше движущихся частей на сервере. Минус — при звонках группами по 5-10 человек это ощутимая дополнительная нагрузка на CPU и RAM того же контейнера, где крутится сам чат, и лимиты mem_limit в compose-файле стоит закладывать с запасом заранее.

Rocket.Chat для прямых звонков 1:1 использует WebRTC без посредников, а для групповых видеоконференций штатно интегрируется с Jitsi Meet — либо публичным сервером, либо своим self-hosted инстансом отдельным контейнером. Это добавляет ещё один сервис в инфраструктуру, но зато нагрузка звонков физически изолирована от процесса чата и не конкурирует с ним за память при пиках.

По интеграциям Rocket.Chat заметно шире именно в сторону внешних клиентов: Telegram, WhatsApp Business API, SMS-шлюзы и Livechat-виджет для сайта собраны в одном модуле Omnichannel — агент поддержки видит все каналы в одном интерфейсе. У Mattermost такого модуля нет, зато глубже проработаны интеграции для разработки — GitHub, GitLab, Jira, Zoom, а Playbooks закрывает сценарии инцидент-менеджмента прямо внутри чата.

Бэкап и восстановление — разная цена ошибки

PostgreSQL под Mattermost бэкапится классическим pg_dump или pg_basebackup, восстановление — понятная и хорошо документированная процедура без специфичных для мессенджера шагов:

docker exec postgres pg_dump -U mmuser mattermost | gzip > mattermost_$(date +%F).sql.gz

Автоматизация по cron и восстановление из архива — процедура настолько же прямолинейная, как и сам бэкап.

С Rocket.Chat сложнее ровно на один шаг — репликасет. mongodump снимает данные штатно, но при восстановлении на новый сервер репликасет нужно инициализировать заново до того, как Rocket.Chat вообще запустится, иначе получите ту же ошибку про oplog, что и при первой установке:

docker exec rocketchat-mongo mongodump --archive=/backup/rc_$(date +%F).gz --gzip

Если ваша команда меняет серверы редко и умеет один раз аккуратно задокументировать процедуру — разница некритична. Если серверы пересобираются часто (тестовые стенды, миграции между локациями) — лишний обязательный шаг на каждое восстановление стоит закладывать в чек-лист заранее, а не вспоминать о нём в момент простоя.

Лицензия и стоимость — что бесплатно, а что нет

Оба проекта дают бесплатную self-hosted редакцию с полноценным чатом, каналами и базовыми интеграциями — платить за сам факт установки на свой сервер не нужно ни там, ни там. Различия начинаются на более тонких возможностях: расширенные роли и разрешения, SSO/SAML для входа через корпоративный каталог, compliance-экспорт переписки, кластеризация под высокую доступность — эти функции у обоих продуктов закрыты платными редакциями, и точный список меняется от версии к версии. Если для вашей команды принципиальны SSO или compliance-требования, уточняйте актуальные условия лицензии на момент внедрения прямо на сайте вендора, а не полагайтесь на статьи годичной давности — политика лицензирования у обоих проектов пересматривалась не раз.

С точки зрения затрат на сервер оба варианта одинаково не требуют ничего экзотического — обычный VPS с Docker потянет любую из связок для команды до пары сотен человек, разница в стоимости инфраструктуры между Mattermost и Rocket.Chat на этом масштабе несущественна.

Когда выбирать какой: пять сценариев

• Инженерная команда, много интеграций с GitHub/GitLab/CI — Mattermost: глубже интеграции с dev-инструментами, Playbooks под инциденты, меньше сервисов на поддержке.
• Поддержка клиентов через Telegram/WhatsApp в одном окне — Rocket.Chat: модуль Omnichannel закрывает это из коробки, у Mattermost такого нет вообще.
• Слабый сервер (2-4 GB RAM), простой чат без звонков — чуть проще с Mattermost: меньше движущихся частей (нет обязательного репликасета), Go-процесс стабильнее по памяти под нагрузкой.
• Нужны частые групповые видеозвонки без отдельного сервера под них — Mattermost Calls: SFU встроен, не нужно поднимать и обслуживать Jitsi отдельно.
• Гибкая кастомизация под конкретный процесс поддержки, много плагинов и ботов от сообщества — Rocket.Chat: более гибкая система ботов и Livechat-виджетов под встраивание в сайт.

Если ни один сценарий не описывает вашу ситуацию точно — начните с меньшего риска: поднимите обе связки на тестовом VPS через Docker Compose параллельно на разных портах, дайте команде из 5-10 человек попользоваться неделю и смотрите, какие вопросы реально возникают на практике, а не в теории.

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