Self-hosted vs облачный мессенджер: что выбрать

Каждая третья компания, выбирающая корпоративный мессенджер, задаёт вопрос: «Self-hosted или облако?» По данным нашего опроса клиентов за 2025 год, 38% начинают с облака и через 12–18 месяцев задумываются о переезде на self-hosted. И наоборот: 15% self-hosted клиентов переходят в облако, когда устают от администрирования.

Оба варианта имеют объективные преимущества. Ни один не является «правильным» для всех. Выбор зависит от конкретных факторов: размер команды, регуляторные требования, бюджет, наличие IT-отдела, отрасль. Разберём каждый фактор отдельно.

Self-hosted и облако: определения без маркетинга

Self-hosted (on-premise)

Мессенджер установлен на серверах, которые контролирует ваша компания. Это могут быть:

• Физические серверы в вашем дата-центре или серверной комнате
• Виртуальные машины в арендованном дата-центре (Selectel, Hetzner, OVH)
• Контейнеры в вашем Kubernetes-кластере
• VPS у облачного провайдера (Yandex Cloud, VK Cloud), но под вашим управлением

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

Облако (SaaS)

Мессенджер работает на серверах вендора. Вы регистрируетесь, создаёте workspace, добавляете пользователей — и работаете. Инфраструктуру (серверы, базы данных, бэкапы, обновления) обеспечивает вендор.

Ключевое: вы не управляете инфраструктурой. Данные хранятся на серверах вендора (или его хостинг-провайдера). Вы доверяете вендору безопасность, доступность и бэкапы.

Граница размыта

В 2026 году граница между self-hosted и облаком не чёрно-белая:

• Self-hosted в облаке: вы устанавливаете мессенджер на VPS в Yandex Cloud. Технически — облако. Практически — self-hosted (вы контролируете сервер).
• Managed self-hosted: вендор разворачивает мессенджер на вашей инфраструктуре и берёт на себя администрирование. Данные — у вас. Обслуживание — у вендора.
• Private cloud: мессенджер в изолированном кластере вендора, выделенном для вас. Не shared hosting, но и не ваш сервер.

Контроль данных: где живут ваши переписки

Self-hosted: полный контроль

Данные хранятся на вашем сервере. Вы определяете:

• Географию: сервер в Москве, Франкфурте или на Камчатке — ваш выбор.
• Шифрование: какой алгоритм, где хранятся ключи, кто имеет доступ.
• Бэкапы: как часто, куда сохраняются, кто может восстановить. Хотите бэкапы каждый час на изолированный сервер в другом дата-центре — пожалуйста.
• Retention: хранить сообщения 1 год или 10 лет. Удалять автоматически через 90 дней. Или не удалять никогда.
• Доступ: ни один человек за пределами вашей компании не имеет доступа к данным. Ни вендор, ни хостинг-провайдер (если диск зашифрован), ни спецслужбы (без физического доступа к серверу и ключам шифрования).

Это важно для: финансового сектора (банковская тайна), медицины (врачебная тайна), оборонки (гостайна), юридических фирм (адвокатская тайна), любой компании, работающей с чувствительными данными.

Облако: делегированный контроль

Данные хранятся на серверах вендора. Вы доверяете ему:

• Географию: вендор определяет, где размещены серверы. Хорошие вендоры указывают регион (например, «данные хранятся в ЦОД Москва»). Плохие — не указывают.
• Шифрование: обычно AES-256 at rest + TLS in transit. Но ключи — у вендора. Он может расшифровать ваши данные (и обязан по запросу правоохранительных органов).
• Бэкапы: вендор делает бэкапы (обычно ежедневно). Но вы не контролируете процесс. Если вендор потеряет бэкап — вы об этом можете не узнать.
• Retention: обычно определяется вендором. Некоторые позволяют настраивать (Enterprise-тарифы), некоторые — нет.
• Доступ: сотрудники вендора технически могут получить доступ к вашим данным (для поддержки, диагностики). Хорошие вендоры ограничивают это политиками и аудитом. Но техническая возможность — есть.

Реальный пример

В 2024 году Notion (облачный сервис) признал, что инженеры поддержки имели доступ к рабочим пространствам клиентов для диагностики проблем. Это не утечка, не взлом — это штатный процесс. Для многих компаний это неприемлемо.

В self-hosted: инженеры вендора не имеют доступа к вашему серверу физически. Они могут помочь с настройкой (если вы дадите доступ), но по умолчанию — ваши данные видите только вы.

Безопасность: объективное сравнение

Распространённое заблуждение: «self-hosted безопаснее». Не обязательно. Self-hosted может быть как крепостью, так и решетом — зависит от того, кто его настраивает и обслуживает.

Когда self-hosted безопаснее

• У вас есть квалифицированный IT-отдел (или хотя бы один опытный DevOps/сисадмин), который регулярно обновляет ОС, следит за патчами, настраивает firewall, мониторит логи.
• Сервер в изолированной сети: мессенджер доступен только через VPN или из корпоративной сети. Атака из интернета — невозможна (нет входной точки).
• Зашифрованные диски + HSM: даже при физическом доступе к серверу данные нечитаемы без ключей.
• Минимальная поверхность атаки: на сервере — только мессенджер. Не 50 сервисов с разными уязвимостями.

Когда облако безопаснее

• У вас нет IT-отдела или он занят другими задачами. Self-hosted без обслуживания — это незакрытые уязвимости, устаревшее ПО, отсутствие мониторинга. Облачный вендор обновляет инфраструктуру за вас.
• Вендор инвестирует в безопасность больше, чем вы можете себе позволить. Крупные SaaS-компании имеют security-команды из 10–50 человек, bug bounty программы, SOC 2 сертификацию, пентесты каждый квартал. Малый бизнес не может себе этого позволить.
• DDoS-защита: облачные вендоры обычно используют CDN и DDoS-mitigation (Cloudflare, AWS Shield). Self-hosted сервер с прямым IP — лёгкая цель для DDoS.

Общие угрозы

Ряд угроз одинаков для обоих вариантов:

• Фишинг: сотрудник переходит по вредоносной ссылке и вводит пароль — неважно, где работает мессенджер.
• Инсайдер: недобросовестный сотрудник с легитимным доступом — угроза и для self-hosted, и для облака.
• Уязвимости в софте: баг в коде мессенджера одинаково опасен в обоих вариантах.

b8q использует TLS 1.3 для всех соединений, шифрование at rest, аудит-логи и 2FA — независимо от варианта развёртывания. Безопасность приложения одинакова; различается безопасность инфраструктуры.

Compliance: ФЗ-152, ISO 27001, ГОСТ

ФЗ-152 «О персональных данных»

Требование: персональные данные граждан РФ должны храниться на территории России (ст. 18, ч. 5). Корпоративный мессенджер обрабатывает ПДн: ФИО сотрудников, номера телефонов, email, фотографии, IP-адреса.

Self-hosted: сервер в российском ЦОД — полное соответствие. Вы контролируете, где данные, и можете это доказать.

Облако: если вендор гарантирует хранение в РФ (и вы можете это проверить) — соответствует. Если нет (Slack — серверы в США, Telegram — серверы в нескольких странах) — нарушение.

Штрафы по ФЗ-152 с 2026 года: до 500 000 руб. за первое нарушение, до 1 500 000 руб. за повторное. Для self-hosted — риск нарушения минимален, потому что вы контролируете географию.

ISO 27001

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

Self-hosted: проще пройти аудит, потому что вы контролируете всё — от физической безопасности сервера до логов доступа. Аудитор проверяет вашу инфраструктуру.

Облако: аудитору нужен SOC 2 отчёт вендора (подтверждение, что вендор соответствует стандартам безопасности). Если у вендора нет SOC 2 — аудитор может отклонить. Крупные вендоры (AWS, Yandex Cloud) имеют SOC 2. Мелкие SaaS — часто нет.

ГОСТ Р 57580 (для финансовых организаций)

Банки, МФО, страховые компании обязаны соответствовать ГОСТ Р 57580. Требования к защите информации в финансовых организациях — строже, чем ФЗ-152.

Self-hosted: практически единственный вариант. ГОСТ требует: контроль физического доступа к серверам, шифрование, аудит, разделение сред (dev/staging/prod), межсетевое экранирование. Всё это реализуемо на собственной инфраструктуре.

Облако: возможно, если облачный провайдер сертифицирован по ГОСТ Р 57580 (Yandex Cloud имеет такую сертификацию). Но мессенджер-вендор должен подтвердить соответствие — что бывает редко.

Государственные контракты (44-ФЗ, 223-ФЗ)

Для работы с госорганами мессенджер должен быть в реестре отечественного ПО (Минцифры) и, желательно, иметь сертификат ФСТЭК. Self-hosted в этом контексте — стандарт, потому что госорганы не размещают данные в чужих облаках.

TCO: реальная стоимость владения

TCO (Total Cost of Ownership) — полная стоимость за 3 года, включая скрытые расходы. Самая частая ошибка: сравнивать только стоимость подписки, игнорируя инфраструктуру, администрирование и простои.

Облако: TCO для 100 пользователей

(*) Минимальное администрирование: настройка SSO, управление пользователями — часть работы IT-отдела, не выделенная задача.

Self-hosted: TCO для 100 пользователей

(*) Стоимость лицензии self-hosted варьируется: от бесплатного (open-source Mattermost Community) до нескольких миллионов рублей (enterprise-решения типа Dialog).

Анализ

На первый взгляд, self-hosted дешевле: 1.4–2.9 млн руб. против 3.6 млн руб. за 3 года. Но посмотрите на строку «Администратор» — 1–2 млн рублей. Это скрытые расходы, которые часто не учитывают.

Если в компании уже есть DevOps/сисадмин, который обслуживает другую инфраструктуру, добавление мессенджера — 10–20% его времени. Маржинальная стоимость низкая. Если выделенного администратора нет — его нужно нанять или обучить.

Точка безубыточности: для команд до 50 человек облако обычно дешевле (подписка маленькая, а стоимость администрирования фиксирована). Для 200+ человек self-hosted часто дешевле (стоимость сервера растёт медленнее, чем стоимость подписки).

Администрирование: что потребуется от IT-отдела

Облако: минимум

Задачи IT-отдела для облачного мессенджера:

• Первоначальная настройка: SSO, структура каналов, роли — 4–8 часов
• Управление пользователями: онбординг / оффбординг — 15 мин на сотрудника (или 0 мин, если SSO + SCIM)
• Поддержка: ответы на вопросы сотрудников — 1–2 часа в неделю
• Обновления: 0 (вендор обновляет автоматически)
• Бэкапы: 0 (вендор бэкапит)
• Мониторинг: 0 (вендор мониторит, SLA в договоре)

Итого: 2–4 часа в неделю для стабильно работающего мессенджера.

Self-hosted: существенно

Задачи для self-hosted:

• Первоначальная установка: развёртывание сервера, настройка ОС, установка мессенджера, SSL, DNS — 8–24 часа
• Обновления: тестирование новой версии на staging, деплой на production — 2–4 часа на обновление (ежемесячно или по мере выхода)
• Бэкапы: настройка автоматических бэкапов, периодическая проверка восстановления — 2 часа при настройке, 1 час в месяц на проверку
• Мониторинг: настройка алертов (CPU, RAM, диск, доступность), реакция на инциденты — 4 часа на настройку, 1–2 часа в неделю
• Обновления ОС: патчи безопасности, kernel updates — 2–4 часа в месяц
• Масштабирование: добавление ресурсов при росте команды — по ситуации
• Инцидент-менеджмент: сервер упал в 3 ночи — кто-то должен поднять

Итого: 8–16 часов в неделю при стабильной работе. При инцидентах — больше.

Необходимые компетенции для self-hosted

• Linux-администрирование: Ubuntu/Debian/CentOS, systemd, firewall, SSH
• Docker и docker-compose (большинство мессенджеров поставляются в контейнерах)
• PostgreSQL: базовое администрирование, бэкапы, настройка производительности
• Nginx/Caddy: reverse proxy, SSL-терминация
• Мониторинг: Grafana, Prometheus, или аналоги
• Сети: DNS, firewall, VPN
• Безопасность: обновления, hardening, аудит

Если в вашей команде нет человека с этими навыками — self-hosted будет источником проблем, а не решением. В этом случае: облако или managed self-hosted (вендор администрирует за вас).

Производительность и доступность

Облако

Облачные вендоры обычно гарантируют SLA 99.9% (8.7 часов простоя в год) или 99.95% (4.4 часа). На практике — крупные облачные платформы работают стабильнее, чем один self-hosted сервер, потому что:

• Мультизональность: данные реплицируются в несколько ЦОД. Если один ЦОД падает — другой подхватывает.
• Auto-scaling: при пиковой нагрузке (утренний час, когда все заходят) облако автоматически добавляет ресурсы.
• 24/7 мониторинг: дежурная команда инженеров реагирует на проблемы в любое время.

Минус облака: задержка (latency). Сервер вендора — в Москве. Ваш офис — в Новосибирске. Каждое сообщение проходит через Москву. Для текстовых сообщений — незаметно (20–40 мс). Для видеозвонков — может быть ощутимо.

Self-hosted

Один сервер без кластеризации — единая точка отказа. Если сервер упал, диск сдох, сеть недоступна — мессенджер недоступен. SLA одного сервера — 99.5–99.9% (4–44 часа простоя в год), зависит от железа и администрирования.

Для повышения доступности:

• Hot standby: второй сервер в режиме ожидания. При падении основного — переключение за 1–5 минут. Стоимость: ×2 на инфраструктуру.
• Кластер: несколько серверов с балансировщиком. Стоимость: ×3–4 на инфраструктуру + усложнение администрирования.
• Docker Swarm / Kubernetes: оркестрация контейнеров с автоматическим перезапуском. Для self-hosted мессенджера — обычно избыточно, но повышает надёжность.

Преимущество self-hosted: минимальная задержка. Сервер в вашей сети — latency < 1 мс. Для видеозвонков (WebRTC) это идеально: сигнальный сервер рядом, TURN-сервер рядом, качество максимальное.

Сравнение

Масштабирование

Облако: линейное

Команда выросла с 50 до 500 человек? Переходите на следующий тариф. Вендор масштабирует инфраструктуру автоматически. Ваши действия: добавить пользователей, обновить платёжные данные. Время: 5 минут.

Self-hosted: ступенчатое

Рост с 50 до 500 — это не просто «больше пользователей». Это:

• Больше CPU и RAM: с 4 vCPU до 16–32 vCPU
• Больше хранилища: с 100 ГБ до 1–2 ТБ
• Больше пропускная способность: с 100 Мбит/с до 1 Гбит/с
• Возможно: вертикальное масштабирование (мощнее сервер) → горизонтальное (больше серверов)
• Возможно: отдельный сервер для базы данных, отдельный — для медиа (файлы, аватарки), отдельный — для WebRTC (TURN/SFU)

Минимальные серверные требования для b8q Self-Hosted по размеру команды:

Self-hosted: развёртывание за 30 минут

Self-hosted звучит сложно, но с Docker Compose развёртывание мессенджера — задача на 30 минут для администратора с базовыми навыками Linux и Docker.

Минимальные требования

• Ubuntu 22.04+ или Debian 12+ (рекомендуемые ОС)
• Docker 24+ и Docker Compose v2
• Доменное имя с DNS A-записью, указывающей на сервер
• SSL-сертификат (Let's Encrypt — бесплатный, обновляется автоматически)

Пошагово

1. Подготовка сервера (5 минут):

# Обновление системы
apt update && apt upgrade -y

# Установка Docker
curl -fsSL https://get.docker.com | sh

# Установка Docker Compose
apt install docker-compose-plugin

2. Конфигурация (10 минут):

Скачать docker-compose.yml и .env от вендора мессенджера. Отредактировать .env: указать домен, пароль базы данных, SMTP для отправки email. Типичный docker-compose.yml включает: приложение, PostgreSQL, Redis (для кэша), Nginx (reverse proxy).

3. Запуск (5 минут):

docker compose up -d

Проверка: открыть https://messenger.company.com — должна появиться страница регистрации.

4. Настройка SSL (5 минут):

Certbot (Let's Encrypt) для автоматического получения и обновления SSL-сертификата. Или — кастомный сертификат от корпоративного CA.

5. Базовая настройка (5 минут):

Создать администратора, настроить workspace, создать первые каналы. Подключить LDAP/SSO (дополнительные 1–2 часа, если нужен SSO — подробнее в руководстве по LDAP и SSO).

Что не забыть после установки

• Бэкапы: настроить cron-задачу для ежедневного бэкапа PostgreSQL (pg_dump) и файлов
• Мониторинг: хотя бы uptime-проверка (healthcheck endpoint) через UptimeRobot (бесплатно) или Grafana
• Firewall: закрыть все порты, кроме 80, 443 (HTTP/HTTPS) и 22 (SSH, ограничить по IP)
• Автообновление ОС: unattended-upgrades для автоматических security-патчей
• Логирование: настроить ротацию логов (logrotate), чтобы диск не переполнился

Обновления и поддержка

Облако

Обновления — автоматические. Вы открываете мессенджер — и у вас уже последняя версия. Без простоев (rolling deployment), без ручных действий, без рисков неудачного обновления.

Поддержка: через тикет-систему, чат или email. Время ответа зависит от тарифа: базовый — 24 часа, бизнес — 4 часа, enterprise — 1 час. Критические проблемы (сервис недоступен) — вендор решает сам.

Self-hosted

Обновления — вручную (или через CI/CD, если вы его настроили). Процесс:

1. Получить уведомление о новой версии
2. Прочитать changelog и breaking changes
3. Обновить на staging-сервере (если есть)
4. Проверить, что всё работает
5. Запланировать maintenance window (обычно ночь или выходные)
6. Сделать бэкап
7. Обновить на production
8. Проверить работоспособность
9. Если что-то пошло не так — откатить из бэкапа

Время: 1–4 часа на обновление. Частота: ежемесячно (обычные обновления) + внепланово (критические патчи безопасности).

Поддержка: зависит от лицензии. Open-source мессенджеры (Mattermost Community, Rocket.Chat) — поддержка сообщества (форумы, GitHub Issues). Коммерческие (b8q Enterprise, Dialog) — выделенный инженер, SLA на ответ.

Мониторинг self-hosted мессенджера

Self-hosted без мониторинга — это бомба замедленного действия. Диск заполнился на 100% ночью — мессенджер перестал работать. БД не отвечает — сообщения не доставляются. SSL-сертификат истёк — пользователи видят «небезопасное соединение».

Что мониторить

• Доступность: HTTP health check (GET /health → 200 OK) каждые 60 секунд. Если нет ответа — алерт. Инструменты: UptimeRobot (бесплатно), Grafana Uptime, Blackbox Exporter.
• CPU и RAM: если CPU > 80% или RAM > 90% в течение 5 минут — алерт. Инструменты: node_exporter + Prometheus + Grafana.
• Диск: если свободного места < 20% — предупреждение. < 10% — критический алерт. Диск заполняется незаметно (логи, файлы пользователей, БД).
• SSL-сертификат: алерт за 14 дней до истечения. Let's Encrypt обновляет автоматически, но иногда обновление ломается (DNS-проблемы, файрвол). Инструмент: ssl_exporter или скрипт проверки.
• PostgreSQL: количество активных соединений, размер БД, реplication lag (если есть реплика), время ответа на запрос. Инструмент: postgres_exporter.
• Бэкапы: последний успешный бэкап был > 24 часов назад — алерт. Бэкап есть, но не проверен — тоже проблема (но её сложнее автоматизировать).

Куда отправлять алерты

Ирония: алерты о проблемах мессенджера нужно отправлять не в мессенджер (он может быть недоступен). Используйте: email, SMS (через SMS-шлюз), Telegram личного телефона администратора (да, для алертов Telegram — нормально), PagerDuty/OpsGenie.

Минимальный стек мониторинга

Для малых установок (1 сервер, до 200 пользователей):

• UptimeRobot (бесплатно, 50 мониторов) — HTTP health check + SSL check + алерты на email/SMS
• cron-скрипт для проверки диска и бэкапов → отправка email при проблемах

Для средних и крупных (2+ серверов, 200+ пользователей):

• Prometheus + Grafana — полноценный мониторинг с дашбордами и алертами
• Alertmanager — маршрутизация алертов (критические — в PagerDuty, предупреждения — в email)
• Loki — агрегация логов (вместо grep по файлам на сервере)

Путь миграции: облако → self-hosted и обратно

Облако → Self-hosted

Типичный сценарий: компания начала с облака (быстро, без инфраструктуры), выросла, получила compliance-требования, решила переехать на self-hosted.

Ключевой вопрос: поддерживает ли вендор экспорт данных?

Если да (как b8q): данные экспортируются в стандартном формате, импортируются в self-hosted инстанс. Сообщения, файлы, каналы, пользователи — всё на месте. Время миграции: 1–3 дня (зависит от объёма).

Если нет: вы заперты (vendor lock-in). Переезд означает потерю истории. Это одна из причин, почему при выборе облачного мессенджера важно проверить: есть ли экспорт данных в открытом формате.

Self-hosted → Облако

Обратный сценарий: компания устала администрировать сервер, решила переехать в облако.

Процесс аналогичный: экспорт из self-hosted, импорт в облако вендора. Для пользователей — переход незаметен (если DNS настроен правильно: поменяли A-запись — и мессенджер работает с нового сервера).

Рекомендация: начните с облака

Если вы не уверены — начните с облака. Это быстрее, проще, дешевле на старте. Через 6–12 месяцев, когда вы поймёте свои реальные потребности (compliance, объём данных, нагрузка), примете обоснованное решение: оставаться в облаке или мигрировать на self-hosted.

b8q поддерживает оба варианта и миграцию между ними — без потери данных.

Стратегия бэкапов: подробно

Что бэкапить для мессенджера

• База данных (PostgreSQL): сообщения, каналы, пользователи, настройки. Это ядро — без БД мессенджер пустой. Инструмент: pg_dump (логический бэкап) или pg_basebackup (физический). Для БД до 10 ГБ — pg_dump. Для 50+ ГБ — pg_basebackup (быстрее).
• Пользовательские файлы: аватарки, вложения в сообщениях, документы. Хранятся на диске (директория uploads/) или в S3-совместимом хранилище. Инструмент: rsync, rclone, или S3 bucket versioning.
• Конфигурация: .env файл, docker-compose.yml, SSL-сертификаты, ключи шифрования. Хранить в git-репозитории (приватном!) или в vault. Без конфигурации восстановить мессенджер из бэкапа БД — сложно.
• Секреты: ключи шифрования, API-токены, пароли сервисных аккаунтов. Хранить отдельно от остальных бэкапов, в зашифрованном виде (HashiCorp Vault, SOPS, age).

Частота бэкапов

3-2-1 правило

Классическое правило бэкапов:

• 3 копии данных (оригинал + 2 бэкапа)
• 2 разных типа хранилища (локальный диск + облачное хранилище)
• 1 копия в удалённом месте (другой ЦОД, другой город)

Для мессенджера: оригинал на сервере + ежедневный бэкап на отдельный диск/сервер в том же ЦОД + ежедневная зашифрованная копия в Yandex Object Storage (или другое S3-совместимое хранилище). Стоимость S3 для 100 ГБ бэкапов: ~300 руб./мес.

Тестирование восстановления

Бэкап, который не тестировали — не существует. Раз в квартал:

1. Поднимите тестовый сервер (или используйте staging)
2. Восстановите БД из последнего бэкапа
3. Восстановите файлы
4. Примените конфигурацию
5. Проверьте: мессенджер запускается? Сообщения на месте? Файлы открываются?
6. Замерьте время восстановления (RTO)
7. Запишите результат и проблемы (если были)

Типичное время полного восстановления мессенджера из бэкапа (для БД 5 ГБ + 50 ГБ файлов): 30–60 минут.

Матрица решения: 12 вопросов

Ответьте на каждый вопрос. Подсчитайте баллы.

8+ баллов за self-hosted: self-hosted — ваш выбор. У вас есть инфраструктура, компетенции и требования, которые облако не покрывает.

8+ баллов за облако: облако — ваш выбор. Быстрее, проще, дешевле на вашем масштабе.

6–7 баллов в любую сторону: рассмотрите гибридный вариант или начните с облака с планом миграции на self-hosted.

Цифровой суверенитет и импортозамещение

С 2022 года тема цифрового суверенитета из теоретической стала практической. Уход Slack из России, ограничения Microsoft, санкционные риски — всё это заставило компании пересмотреть зависимость от зарубежных SaaS.

Что говорит закон

Реестр отечественного ПО. Государственные и муниципальные организации обязаны использовать софт из реестра Минцифры (Постановление Правительства №1236). Для коммерческих компаний — рекомендовано, не обязательно. Но наличие в реестре — сигнал зрелости продукта.

Критическая информационная инфраструктура (КИИ). Субъекты КИИ (банки, энергетика, транспорт, здравоохранение) обязаны использовать отечественное ПО для значимых объектов КИИ. Мессенджер — часть коммуникационной инфраструктуры, и может быть классифицирован как значимый объект.

Self-hosted и суверенитет

Self-hosted мессенджер на серверах в российском ЦОД — максимальный уровень цифрового суверенитета. Данные не покидают территорию РФ. Зависимость от зарубежных провайдеров — нулевая. Даже если все зарубежные сервисы станут недоступны — мессенджер продолжит работать.

Для облачного мессенджера: убедитесь, что вендор хранит данные в российских ЦОД. Запросите подтверждение: сертификат соответствия, адрес ЦОД, акт размещения. Устные заверения «данные в России» — недостаточны для аудита.

Гибридный вариант

Необязательно выбирать строго одно. Гибридные схемы:

Облако + self-hosted TURN-сервер

Мессенджер в облаке, но TURN-сервер для WebRTC-звонков — в вашей сети. Медиа-поток (видео, аудио) идёт через ваш сервер, не покидая корпоративную сеть. Текстовые сообщения — через облако. Это компромисс: простота администрирования облака + приватность звонков.

Self-hosted + облачные бэкапы

Мессенджер на вашем сервере, бэкапы — в зашифрованном виде в облачном хранилище (S3, Yandex Object Storage). Данные зашифрованы AES-256, ключ — только у вас. Облачный провайдер не может расшифровать. Преимущество: защита от потери физического сервера (пожар, кража).

Multi-region self-hosted

Несколько self-hosted инстансов в разных регионах с синхронизацией. Офис в Москве — сервер в Москве. Офис во Владивостоке — сервер во Владивостоке. Синхронизация между серверами. Минимальная latency для каждого офиса. Реализация сложная, но для крупных компаний — оправданная.

Выбор между self-hosted и облаком — это не вопрос «что лучше». Это вопрос «что подходит вашей компании прямо сейчас». И ответ может измениться через год-два — и это нормально. Главное — выбрать мессенджер, который поддерживает оба варианта и позволяет мигрировать между ними без потери данных.

b8q работает и как облачный сервис, и как self-hosted решение. Одна платформа, два варианта развёртывания, миграция в обе стороны. Начните с того, что удобно сейчас — измените позже, если потребуется.

Два кейса: self-hosted и облако

Кейс 1: банк, 500 сотрудников — self-hosted

Профиль: региональный банк, 500 сотрудников, 12 отделений. Требования: ГОСТ Р 57580, данные только на территории РФ, интеграция с Active Directory, аудит-логи за 5 лет.

Почему self-hosted: регулятор (ЦБ РФ) требует хранение данных на инфраструктуре банка. Облачные мессенджеры отпали на этапе compliance-проверки. Кроме того, банк уже имел собственный ЦОД с резервированием и круглосуточной поддержкой.

Реализация:

• Два сервера (primary + hot standby) в разных ЦОД банка
• PostgreSQL с потоковой репликацией
• Интеграция с AD через LDAP + SAML 2.0 (AD FS)
• Аудит-логи в отдельное хранилище с WORM-защитой (запись без возможности изменения)
• Бэкапы: каждые 6 часов, хранение 5 лет, зашифрованные

Результат: uptime 99.97% за первый год (26 минут простоя — плановое обслуживание). Аудит ГОСТ Р 57580 пройден без замечаний по мессенджеру. Стоимость: ~120 000 руб./мес (серверы + администрирование) + лицензия.

Кейс 2: стартап, 35 человек — облако

Профиль: EdTech-стартап, 35 человек, полностью удалённый. Нет IT-отдела (один DevOps-инженер, занятый инфраструктурой продукта). Нет compliance-требований. Бюджет ограничен.

Почему облако: нет людей для администрирования self-hosted. Нет серверов. Нет необходимости в compliance. Главные критерии: быстро запустить, дёшево, удобно.

Реализация:

• Регистрация в b8q Cloud — 10 минут
• Создание 8 каналов — 15 минут
• Приглашение 35 сотрудников — 20 минут
• Настройка вебхуков из GitLab и Grafana — 30 минут

Итого: запуск за 1 час. Без серверов, без администрирования, без лицензий. Через 8 месяцев команда выросла до 80 человек — масштабирование свелось к переходу на следующий тарифный план.

Планы: при достижении 200 человек рассмотреть self-hosted — к тому моменту будет полноценный IT-отдел.

Vendor Lock-in: как не застрять

Vendor lock-in — зависимость от конкретного поставщика, при которой переход на альтернативу непропорционально дорог или сложен. В контексте мессенджера lock-in означает: вы не можете забрать свои данные и уйти.

Признаки lock-in

• Нет экспорта данных: мессенджер не позволяет выгрузить историю переписки, файлы, структуру каналов в открытом формате.
• Проприетарные форматы: данные хранятся в формате, который может прочитать только этот мессенджер.
• Нет API: нельзя программно извлечь данные.
• Нет self-hosted опции: если вендор закроется или поднимет цены в 5 раз — у вас нет альтернативы, кроме как потерять данные.

Как защититься

1. Проверьте экспорт перед покупкой. Зарегистрируйтесь на триале, создайте тестовые данные, попробуйте экспортировать. Если нет кнопки «Экспорт» — задайте вопрос поддержке. Если ответ «мы не поддерживаем экспорт» — ищите другой мессенджер.
2. Выбирайте открытые форматы. JSON, CSV, Markdown — читаются любым инструментом. Проприетарные бинарные форматы — нет.
3. Используйте мессенджер с self-hosted опцией. Даже если сейчас вы в облаке — наличие self-hosted версии означает, что вы можете забрать данные и развернуть на своём сервере в любой момент.
4. Регулярные бэкапы на свою сторону. Если мессенджер облачный — периодически экспортируйте данные и храните копию у себя. Не доверяйте только бэкапам вендора.

b8q: экспорт данных в JSON доступен на всех тарифах. Self-hosted и облако используют одинаковый формат данных — миграция в любую сторону без потерь.

Disaster Recovery: что если всё упадёт

Облако

Disaster recovery — ответственность вендора. Хороший вендор имеет:

• Мульти-зональное размещение (данные реплицируются в 2–3 ЦОД)
• Автоматическое переключение при падении одного ЦОД (failover за 1–5 минут)
• RPO (Recovery Point Objective): потеря данных не более 1 часа
• RTO (Recovery Time Objective): восстановление за 15–60 минут
• Документированный DR-план

Как проверить: запросите DR-документацию у вендора. Если ответ «мы не предоставляем DR-план» — серьёзный красный флаг.

Self-hosted

Disaster recovery — ваша ответственность. Минимальный DR-план:

1. Бэкапы базы данных: автоматические, каждые 6–12 часов, в отдельное хранилище (не на тот же сервер!)
2. Бэкапы файлов: пользовательские файлы (аватарки, документы, вложения) — ежедневно
3. Бэкап конфигурации: файлы конфигурации, SSL-сертификаты, секреты — в зашифрованном виде
4. Тест восстановления: раз в квартал восстановите бэкап на тестовом сервере. Если не тестировали — бэкап не существует.
5. Документация: пошаговая инструкция «Как восстановить мессенджер из бэкапа». Написана так, чтобы любой администратор (не только тот, кто настраивал) мог выполнить.

Продвинутый DR:

• Hot standby сервер с потоковой репликацией PostgreSQL — RTO менее 5 минут
• Бэкапы в удалённый ЦОД (другой город) — защита от катастрофы в одном ЦОД
• Мониторинг бэкапов: алерт, если бэкап не создался вовремя
• Инфраструктура как код (Ansible, Terraform): весь сервер можно пересоздать из скрипта за 30 минут

Managed Self-Hosted: третий вариант

Managed self-hosted — компромисс: данные на вашей инфраструктуре, администрирование — у вендора.

Как это работает

1. Вы предоставляете сервер (VPS, bare metal, или сервер в своём ЦОД)
2. Вендор получает SSH-доступ (ограниченный, через jump host или VPN)
3. Вендор устанавливает, настраивает и обновляет мессенджер
4. Вендор мониторит доступность и производительность
5. При проблемах — вендор решает (или эскалирует, если проблема на уровне инфраструктуры)

Кому подходит

• Компании с compliance-требованиями (данные на своих серверах обязательно), но без квалифицированного IT-отдела
• Средний бизнес (100–500 человек), который хочет self-hosted без найма выделенного администратора
• Компании, переходящие с облака на self-hosted — managed hosting как переходный этап

Стоимость

Обычно: стоимость лицензии self-hosted + 30–50% надбавка за управление. Для b8q: обсуждается индивидуально в рамках тарифа Корпорация. Для сравнения: найм DevOps-инженера — 200 000–500 000 руб./мес (полная ставка), а managed hosting — значительно дешевле, потому что один инженер вендора обслуживает десятки клиентов.

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

Можно ли начать с облака и перейти на self-hosted?

Да, если мессенджер поддерживает миграцию. b8q: экспорт из облака, импорт в self-hosted. Данные (сообщения, файлы, каналы, пользователи) переносятся полностью. Время: 1–3 дня в зависимости от объёма.

Self-hosted на VPS в облаке (Yandex Cloud, Selectel) — это self-hosted или облако?

Формально — self-hosted: вы контролируете сервер. Данные на вашем VPS, а не в shared-инфраструктуре вендора мессенджера. Для compliance — зависит от конкретных требований. Для ФЗ-152: если VPS в российском ЦОД — соответствует. Для ГОСТ Р 57580: может потребоваться собственный ЦОД (не арендованный VPS).

Сколько стоит администрирование self-hosted?

Зависит от подхода. Если выделенный администратор: 10–20% его рабочего времени (30 000–80 000 руб./мес из зарплаты). Если managed self-hosted (вендор администрирует): обычно +30–50% к стоимости лицензии. Если DevOps-команда уже есть и обслуживает другую инфраструктуру: маржинальная стоимость добавления мессенджера — минимальна.

Что безопаснее?

Зависит от ваших компетенций. Self-hosted с квалифицированным администратором — безопаснее (вы контролируете всё). Self-hosted без администратора — опаснее (незакрытые уязвимости, отсутствие мониторинга). Облако от надёжного вендора — средний уровень безопасности, не зависящий от ваших компетенций. Подробнее — в разделе Безопасность.

Дополнительные материалы

• b8q Self-Hosted — подробнее о self-hosted версии
• On-premise мессенджер — развёрнутое сравнение on-premise решений
• Цифровой суверенитет — зачем компаниям контролировать свои данные
• Безопасные коммуникации — шифрование, аудит, DLP
• LDAP и SSO в мессенджере — настройка единого входа (актуально для self-hosted)
• Сравнение мессенджеров 2026 — какие мессенджеры поддерживают self-hosted