Корпоративный мессенджер, CI/CD-алерты, мост в Telegram и IRC — всё это обслуживает один бот в Matrix. Мы развернули 23 бота на собственном Synapse-сервере и делимся практическим опытом: какой подход выбрать, где подводные камни и какие результаты получили.
Зачем нужны боты в Matrix
Matrix — федеративный протокол, где бот получает полный доступ к API наравне с живым пользователем. В Telegram или Slack боты живут в песочнице с урезанным набором методов. В Matrix такого ограничения нет.
Четыре класса задач, которые закрывают боты:
— Уведомления — алерты из Zabbix, Prometheus, пайплайны CI/CD
— Мосты между мессенджерами — сотрудники общаются каждый в привычном клиенте, сообщения синхронизируются
— Административные операции — массовое создание комнат, управление приглашениями, аудит участников
— Интеграция с внутренними системами — заявки из ServiceDesk, задачи в Jira, обновления CRM прямо из чата
В федеративной сети Matrix на конец 2025 года работает более 115 миллионов учётных записей. Официального каталога ботов не существует — каждая организация собирает инструментарий под себя.
Два подхода к архитектуре
Выбор между Client-Server API и Application Services определяет масштаб всего решения.
Client-Server API — простой путь. Бот регистрирует обычную учётную запись, получает токен и подключается через /sync. Рабочий бот разворачивается за 15 минут. Ограничение — справляется примерно со 100 комнатами и видит только те, куда его пригласили.
Application Services — серверный процесс с YAML-регистрацией на homeserver. Сервер сам отправляет события по HTTP, не дожидаясь запросов. Один AS управляет тысячами виртуальных пользователей и подписывается на события по шаблонам регулярных выражений. Именно так работают все крупные мосты — mautrix-telegram, matrix-appservice-irc, matrix-appservice-slack.
Ключевые различия:
— Сложность запуска: CS API — токен и скрипт; AS — YAML-регистрация на homeserver
— Масштаб: CS API — до 100 комнат; AS — тысячи комнат и ghost-пользователей
— Доставка событий: CS API — polling; AS — push от homeserver
— Виртуальные пользователи: только в AS — каждый мост-участник выглядит как отдельный юзер
Как это работает на практике
CS API мы используем для лёгких уведомителей. Бот получает webhook от GitLab, форматирует сообщение и отправляет в комнату проекта. Достаточно 50 строк кода и одного systemd-сервиса.
Application Services применяем для мостов и административных ботов. Наш мост в Telegram обслуживает 47 комнат через один AS-процесс.
Бот, зарегистрированный на вашем сервере, взаимодействует с комнатами на любом другом сервере в сети. Партнёр приглашает бота — и он работает без дополнительной настройки. Такие сценарии недоступны в закрытых мессенджерах.
Результаты: 23 бота на одном сервере
На нашем Synapse-сервере работают:
— 4 моста (Telegram, IRC, Slack и внутренний)
— 8 уведомителей (CI/CD, мониторинг, алерты)
— 6 административных (управление комнатами и участниками)
— 5 интеграционных (ServiceDesk, Jira, CRM)
Суммарная нагрузка — 12 000 событий в сутки. Потребление памяти всех ботов — 800 МБ.
Кому подойдёт
Боты в Matrix закрывают задачи компаний, которые:
— Используют несколько мессенджеров и хотят объединить коммуникации в одном окне
— Нуждаются в самостоятельном хостинге без зависимости от облачных сервисов
— Автоматизируют DevOps-процессы и получают алерты в едином канале
— Работают с партнёрами и подрядчиками через федерацию
Один сервер, 23 бота, 12 000 событий в сутки — и всё на 800 МБ памяти. В IT For Prof мы используем эту связку ежедневно и продолжаем наращивать интеграции.