Робочий чат на своєму сервері: Mattermost або Rocket.Chat

Уся робота живе в чаті. Домовленості з клієнтами, паролі, які хтось колись кинув «на хвилинку», скриншоти з адмінки, рішення, яке ухвалили пів року тому. І все це лежить на чужих серверах: у безкоштовному Slack стара історія ховається за пейволом, у Teams — за ліцензіями, а в Telegram-групах взагалі ніхто не знає, хто ще там сидить.

Найболючіше — коли людина йде з команди. Її треба вручну викинути з десятка груп, а копія листування лишається в неї на телефоні. Якщо акаунт був особистий — ви його не контролюєте зовсім.

Власний чат прибирає цю проблему. Сервер ваш, база ваша, вхід через ваш каталог користувачів. Вимкнули акаунт в одному місці — людина втратила доступ.

Що ми робимо

Типова схема, яку ми ставимо на виділений сервер OVH чи Hetzner або в наявний Proxmox:

• Чат — Mattermost (частіше) або Rocket.Chat в окремій віртуалці чи LXC-контейнері.
• База — PostgreSQL для Mattermost, MongoDB з набором реплік для Rocket.Chat.
• Файли — на локальному диску або в S3-сумісному сховищі (MinIO, Object Storage у Hetzner чи OVH). Для команди, що активно кидає скриншоти й PDF, S3 зручніший: диск віртуалки не росте, а бекап файлів живе окремо.
• Вхід — через SSO: Keycloak, Authentik або ваш LDAP/Active Directory.
• Вхід ззовні — Nginx або Traefik з TLS-сертифікатом від Let’s Encrypt, fail2ban і обмеження частоти запитів на сторінку логіна.
• Інтеграції — канали для алертів з Prometheus/Alertmanager, повідомлень з GitLab CI, деплоїв.
• Бекапи і моніторинг — щоденний дамп бази і копія файлів на окреме сховище, перевірка доступності й сертифіката.

Mattermost чи Rocket.Chat — чесно

Mattermost працює на PostgreSQL і складається з одного бінарника. Обслуговувати його простіше: оновлення — це заміна версії і міграції бази, які він робить сам. Він добре дружить з GitLab: є готова інтеграція, слеш-команди, сповіщення про merge request і пайплайни. Для технічних команд це зазвичай найкращий вибір.

Дані він тримає в звичайних таблицях, тож за потреби відповідь можна дістати прямо з бази SQL-запитом. Один нюанс, про який варто знати: видалене повідомлення в базі лише позначається як видалене, а не зникає. Для аудиту це плюс. Для того, хто думав, що «стер і забув», — сюрприз.

Rocket.Chat дає більше «з коробки»: омніканал для звернень клієнтів, відеодзвінки, більше налаштувань інтерфейсу. Але він важчий. Йому потрібна MongoDB з набором реплік навіть на одному сервері, а оновлювати MongoDB між мажорними версіями доводиться покроково, через кожну проміжну.

Обидва мають безкоштовні редакції, але їхні умови вендори за останні роки міняли не раз: що входить, скільки користувачів, які функції лишились у платних планах. Тому ми не обіцяємо наперед — перед стартом звіряємо актуальні умови з вашою кількістю людей і потрібними функціями. Наприклад, у Mattermost загальний вхід через OpenID Connect, SAML і LDAP історично входив у платні редакції, а безкоштовна вміла вхід через GitLab. Від цього залежить, як саме ми підключимо SSO.

Коли власний чат НЕ підходить: якщо у вас п’ять людей, нікого з них не треба відключати й нікому не потрібна історія за три роки. Тоді витрати на сервер і супровід не окупляться.

Сповіщення на телефон, SSO і звільнення

Push-сповіщення — найменш очевидна частина. Офіційні мобільні застосунки отримують пуші через сервіси Apple і Google, а ті приймають їх лише від вендора застосунку. Тож ваш сервер шле сповіщення через push-проксі вендора, а вже той — в Apple чи Google. Тобто тут ви залежите від чужого сервісу і його умов. Щоб текст повідомлень не йшов назовні, вмикаємо режим, коли в пуші летить лише ідентифікатор, а сам текст телефон забирає з вашого сервера. Повністю свій push-проксі можливий, але тоді треба збирати власні мобільні застосунки — для малої команди це зазвичай зайве.

Звідси ж ще один компроміс: чат не сховаєш за VPN чи за загальною сторінкою логіна перед сайтом. Мобільні й десктопні клієнти ходять в API напряму. Тому захищаємо сам застосунок: SSO з другим фактором, fail2ban, обмеження частоти запитів.

SSO налаштовуємо так, щоб люди входили тим самим акаунтом, що й у пошту чи GitLab. Перед перемиканням зв’язуємо наявні акаунти за email, щоб у людей не з’явились дублікати. Окремо перевіряємо адресу сайту в конфігурації: якщо там лишилась внутрішня адреса, вхід через SSO і посилання в пушах просто не працюватимуть.

Коли людина звільняється, її вимикають у каталозі — і вона вже не увійде. Але вже відкриті сесії живуть до кінця свого строку, тому ставимо розумну тривалість сесій і пишемо коротку інструкцію, що робити в день звільнення.

Інтеграції. Mattermost приймає вебхуки у форматі Slack, тож Alertmanager шле алерти без жодних додаткових модулів:

receivers:
  - name: chat-alerts
    slack_configs:
      - api_url_file: /etc/alertmanager/chat_webhook
        channel: alerts
        send_resolved: true
        title: '{{ .CommonLabels.alertname }}: {{ .Status }}'

GitLab CI так само пише в канал про зламаний пайплайн чи успішний деплой.

Бекапи й оновлення. Дамп бази і копія файлів — окремо, на інше сховище, з перевіркою відновлення. Оновлюємо за планом: спершу знімок віртуалки, потім нова версія, потім перевірка входу, пушів і вебхуків.

Що ви отримуєте

• Робочий чат на вашому сервері, з вашим доменом і TLS.
• Вхід через SSO і зрозумілий порядок дій при звільненні.
• Мобільні й десктопні застосунки з налаштованими сповіщеннями.
• Канали з алертами моніторингу і подіями CI.
• Щоденні бекапи бази й файлів з перевіреним відновленням.
• Моніторинг доступності, місця на диску і строку дії сертифіката.
• Документацію: де що лежить, як оновлювати, як відновитись з бекапу.
• Повні адмінські доступи — все лишається у вас, навіть якщо ми більше не працюємо разом.

Якщо робота у вас розкидана по Telegram-групах або ви вперлися в ліміти Slack — напишіть нам. Розкажіть, скільки у вас людей і чим ви вже користуєтесь, — запропонуємо, що ставити і як переїхати.