Frisbee: российский корпоративный мессенджер на своём сервере — обзор, развёртывание, импортозамещение

Frisbee мессенджер позиционируется как защищённая платформа для корпоративных коммуникаций, способная заменить зарубежные аналоги в условиях жёстких требований к суверенитету данных. Разработчик KLAUD ATLAS предлагает решение, входящее в реестр российского ПО (запись №7378) и соответствующее ФЗ-152, что критично для компаний, стремящихся к импортозамещению без потери функциональности.

Система поддерживает до 300 000 пользователей в одной инсталляции и обрабатывает 100 000 сообщений в секунду, обеспечивая масштабируемость для крупного бизнеса. Доступны две модели поставки: облачная SaaS и развёртывание на собственном сервере (on-premise), что позволяет гибко управлять инфраструктурой и соблюдать политики информационной безопасности организации.

Компаниям, которые до 2022 держали внутреннюю переписку в Telegram и Slack, сейчас всё чаще звонят из юридического отдела: под приказы по импортозамещению нужен мессенджер из реестра, а иностранный SaaS не проходит по 152-ФЗ. Frisbee — это не форк открытого клиента и не косметическая обёртка над XMPP, а собственная платформа с серверной частью, публичным сайтом frisbee.chat и клиентами в RuStore и App Store.

Ключевой факт для того, кто согласовывает бюджет: продукт получил TAdviser IT Prize 2026 и на момент публикации обслуживает около 1 млн корпоративных пользователей. По нашему опыту, когда служба безопасности сравнивает варианты для внутренних коммуникаций, наличие в реестре Минцифры — не декоративный пункт, а обязательное условие: без него бюджет по программе импортозамещения не согласуют, сколько бы ни было аргументов «зато функционал шире».

Проверка, которую применит инженер уже на этапе шорт-листа: если у вас есть требования по 152-ФЗ и приказ на импортозамещение с зафиксированным сроком — Frisbee проходит формальные фильтры (реестр под номером 7378, разработчик — российское юрлицо KLAUD ATLAS). Если требований от регулятора нет и стоит только задача «переписка на своём сервере», этот критерий перестаёт быть решающим — тогда с Frisbee имеет смысл сравнивать open-source-платформы (об этом ниже).

Не делайте так, как один наш заказчик из промышленного сектора: они выбрали зарубежный self-hosted мессенджер по критерию «зато бесплатно», а через полгода переделывали проект под РФ-реестр — их отраслевой аудитор развернул схему, потому что для объектов КИИ требовалось ПО из реестра. В итоге двойная миграция, потерянный квартал и повторное согласование бюджета. Начинайте с фильтра «реестр/152-ФЗ», а не с функциональности — переделывать по формальным основаниям всегда дороже, чем принять их за исходное ограничение.

Главная проблема, которую решает Frisbee мессенджер, — не «ещё один чат», а разрозненный зоопарк инструментов: чаты в одном сервисе, конференции во втором, задачи в Jira, обучающие видео на внешнем хостинге, звонки через отдельную АТС. Каждая интеграция — точка отказа и повод для тикета в поддержку. Платформа собирает эти функции в одной лицензии, и это меняет расчёт стоимости владения.

По функционалу порог входа заметный. ВКС держит более 1000 участников одновременно, одна инсталляция рассчитана более чем на 300 000 пользователей, а серверная часть обрабатывает 100 000 сообщений в секунду. Эти цифры важны не как маркетинг, а как ответ на вопрос «переживёт ли платформа наш годовой всеобщий сбор» — при таких характеристиках вы упрётесь скорее в канал связи, чем в мессенджер. В ВКС встроен гостевой доступ по ссылке без регистрации, что закрывает типовой сценарий с внешними подрядчиками и кандидатами на собеседование.

AI-ассистент ведёт протоколы видеовстреч, присылает отчёты и интегрируется прямо в чаты. По нашему опыту, это первое, что реально снимает нагрузку с секретарей и лидов команд, — раньше конспект встречи писал кто-то из участников, теперь протокол прилетает в общий чат автоматически. Дальше — собственный видеохостинг FrisbeeTube для корпоративной медиатеки (запись обучений, регламентов, релиз-нотов) и таск-менеджер FrisbeeFlow для задач без выгрузки в стороннюю систему.

Отдельная строка — SIP-телефония: можно позвонить сотруднику или добавить участника в конференцию, просто набрав его номер. Это критично для компаний, где часть сотрудников (склад, цех, магазины) физически не сидит в мессенджере и слышит только звонок на мобильный — коммуникация не разваливается на «те, кто в мессенджере» и «те, кто нет».

Критерий, по которому мы советуем оценивать этот стек, простой: посчитайте, сколько отдельных лицензий сейчас покрывают чат + ВКС + видеохостинг + таск-менеджер + запись протоколов. Если получается больше трёх — консолидация в одну платформу почти всегда даёт снижение TCO уже на втором году, даже без учёта экономии на интеграциях между продуктами.

Frisbee поставляется по двум моделям: SaaS в облаке вендора и On-premise на инфраструктуре заказчика. Разница здесь не только про «где стоят серверы» — она задаёт границу ответственности, стоимость владения на длинном горизонте и то, у кого лежат ваши переписки в юридическом смысле.

Облачная модель закрывает быстрый старт: не нужно готовить железо, поднимать кластер, настраивать резервное копирование — вендор делает это на своей стороне. Она подходит, когда компания не относится к КИИ, у службы безопасности нет отдельного требования «всё внутри периметра», а ИТ-команда небольшая и её не хочется догружать эксплуатацией ещё одного тяжёлого сервиса. По нашему опыту, для организаций до нескольких сотен сотрудников без отраслевых регуляторов SaaS почти всегда экономически выгоднее — пока вы не упираетесь в требования по данным.

On-premise — сценарий для тех, кому вопрос «где физически лежат сообщения» задают внешние аудиторы. Данные на вашем сервере исключают доступ третьих лиц, а хранение и передача шифруются отечественными и международными техническими решениями шифрования. Для устройств сотрудников есть удалённый выход из аккаунта и очистка данных по команде сервера — на случай потери телефона или увольнения. Публичного Docker-образа и install-документации у Frisbee нет: on-prem продаётся через сейлз, вендор разворачивает инсталляцию силами своей команды под ваши требования по железу.

Критерий выбора мы формулируем так. Есть хотя бы один из пунктов — идёте в On-premise:

1. Объект КИИ или отрасль с требованиями по локализации данных.
2. Внутренний регламент запрещает хранить корпоративную переписку у сторонних провайдеров.
3. Уже есть собственная инфраструктура (виртуализация, СХД, служба эксплуатации) и понятная стоимость её масштабирования.
4. Масштаб от нескольких тысяч сотрудников — на большом объёме SaaS-подписка обгоняет собственный сервер по TCO.

Не делайте гибрид «SaaS сейчас, on-prem потом» без плана миграции. Мы видели, как заказчик запустился в облаке «на пилот на два месяца», а через год перевозил историю чатов на свою инфраструктуру — переезд идёт через вендора, и его нужно бюджетировать заранее, а не в момент, когда СБ уже прислала предписание.

Когда клиент говорит «нам нужен мессенджер на своём сервере», в реальности стоит сравнить три класса решений: проприетарные РФ-платформы из реестра (Frisbee, VK Teams, Express, Пачка), open-source-стек — Matrix с клиентом Element или Rocket.Chat, и совсем минималистичный XMPP плюс Nextcloud Talk для встроенных ВКС. Ошибка сравнения — считать их равнозначными: они закрывают разные проблемы.

Matrix/Element силён там, где нужна федерация между организациями и полный контроль над кодом. Мы разворачивали его в проектах, где заказчик готов держать 1–2 инженеров под эксплуатацию: обновления, сертификаты, база Synapse/Dendrite, отдельная настройка ВКС через Jitsi или LiveKit, кастомизация клиента. Функциональность богатая, но собранной коробки уровня «чат + ВКС на 1000 + видеохостинг + таск-менеджер + AI-ассистент» из одной лицензии там нет — это конструктор, который вы собираете сами.

Nextcloud Talk — противоположный полюс: если Nextcloud уже стоит под файлы, добавить Talk — почти бесплатное решение. Но ВКС там комфортно масштабируется на десятки участников, не тысячу, и корпоративный мессенджер это скорее «чат для обсуждения файла», чем самостоятельная коммуникационная платформа. XMPP — устаревающая база с фрагментированной экосистемой клиентов, живой вариант только для узкоспециализированных задач.

Frisbee мессенджер в этой матрице занимает нишу «одна лицензия, вендорская поддержка, реестр». В одной инсталляции — 300 000+ пользователей и 100 000 сообщений в секунду, ВКС на 1000+ участников, встроенный видеохостинг FrisbeeTube, таск-менеджер FrisbeeFlow, AI-ассистент и SIP. За это платится лицензионными деньгами и меньшей свободой копаться в исходниках.

Практический критерий: если у вас есть внутренняя команда на 1–2 сеньоров, которым нравится держать open-source, а требований к реестру нет — Matrix даст меньшую стоимость владения на большом горизонте. Если требований к реестру нет, но и лишних инженеров тоже — SaaS Frisbee честнее. Если требования к реестру и 152-ФЗ есть — open-source отпадает по формальному критерию, и выбор идёт внутри проприетарной РФ-корзины уже по функционалу, а не по идеологии.

Приказ «до конца квартала уйти с Telegram/Slack/Teams» — это не про мессенджер, а про то, что после ухода перестанет работать. Обычно ломается один из четырёх сценариев: групповые обсуждения проектных команд, регулярные ВКС с большими залами, звонки на мобильные через SIP, и обучающие записи, которые сейчас лежат на внешнем видеохостинге. Frisbee спроектирован так, чтобы закрыть все четыре одной лицензией.

Замена Telegram/Slack — это чаты, треды, реакции, файлы, чат-боты, поиск и опросы: всё это в одной клиентской оболочке под iOS, Android, десктоп. Замена Skype/Teams — встроенные ВКС на 1000+ участников с гостевым доступом по ссылке без регистрации, демонстрацией экрана, записью и AI-протоколами. Замена внешнего видеохостинга (YouTube/Vimeo для обучений) — FrisbeeTube внутри периметра. SIP-телефония закрывает сценарии, где сотрудники не сидят в мессенджере. По совокупности заменяемых продуктов Frisbee мессенджер честнее сравнивать не с одним конкурентом, а со стеком из 3–4 сервисов.

Ключевые узлы миграции, которые мы разбираем на старте каждого проекта:

1. Массовое заведение учётных записей сотрудников — уточните у вендора, поддерживается ли импорт из вашего корпоративного каталога, иначе ручное заведение на 500+ сотрудников превращается в неделю рутинной работы.
2. Двухфакторная аутентификация и вход по номеру телефона — конфигурируются под политику вашей СБ.
3. Удалённая очистка данных с устройства при увольнении или потере — обязательный пункт регламента информационной безопасности.

Не делайте, как один наш клиент из ретейла: они пытались мигрировать 800 сотрудников с Telegram «за выходные», без предварительной инвентаризации групповых чатов и файлов. В понедельник закупщики не могли найти историю переписки с поставщиками за прошлый квартал — переезд встал, а СЕО собрал разбор полётов. Правильная последовательность: сначала аудит того, где реально живёт критичная переписка (какие чаты, за какой период, какие вложения), потом заведение учётных записей, потом плавный переход с двумя мессенджерами параллельно на 2–4 недели, и только потом отключение исходного.

Критерий готовности к отключению старого мессенджера, который мы применяем сами: 95% рабочей активности переехало, история за необходимый ретеншен сохранена (или задокументировано, что не нужна), СБ подписала регламент по 2FA и удалённой очистке.

Публичного прайс-листа у Frisbee нет — стоимость и SaaS-пакетов, и On-premise рассчитывается индивидуально: слишком много переменных (число пользователей, модель поставки, набор модулей, глубина интеграций и SIP, SLA). Это стандартная практика для B2B-платформ такого масштаба и не должна восприниматься как красный флаг: цена «за пользователя в месяц» из публичной цены обычно всё равно не совпадает с реальным контрактом крупной компании.

Чтобы предметно разговаривать с сейлзом, а не собирать три коммерческих предложения ради одного, мы советуем зафиксировать до первой встречи с вендором такие параметры. Число пользователей на старте и целевое через год — от этого зависит лицензионная модель. Модель поставки — SaaS или On-premise, и по каким формальным основаниям (152-ФЗ, отраслевые требования, внутренняя политика ИБ). Обязательные модули — нужен ли FrisbeeTube, FrisbeeFlow, AI-ассистент, SIP. Число одновременных участников ВКС в типовой встрече и «раз в квартал» — платформа держит 1000+, но пилить ресурсы под пик или под медиану — вопрос тарификации.

Что уточнять у вендора отдельным списком:

1. Требования к железу и ОС для On-premise — какие CPU/RAM/диск под ваш объём пользователей и сообщений (100 000 сообщений в секунду — это про потолок платформы, а не про ваш реальный профиль).
2. Синхронизация с корпоративным каталогом пользователей (LDAP/AD) — поддерживается ли, и если да, какие атрибуты и с какой периодичностью.
3. Политика обновлений для On-premise — кто накатывает патчи, как часто, есть ли окно обслуживания.
4. Резервное копирование и его тестирование.
5. Договор об уровне сервиса и время реакции на инциденты в разных категориях.
6. Поведение при потере устройства сотрудником — как срабатывает удалённая очистка.

По нашему опыту, самая частая ошибка на внедрении — заказчик договаривается только про лицензию и забывает про интеграцию. В смету должны попасть работы по интеграциям (каталог пользователей, SIP-АТС), по миграции истории со старого мессенджера и по обучению сотрудников: без последнего пункта через месяц кто-то всё равно продолжит писать «по-старому» в закрытый Telegram, и приказ по импортозамещению превращается в фикцию.

Простая матрица, по которой мы советуем принимать решение, не растягивая пилот на полгода. Frisbee подходит, если совпадают минимум два из трёх пунктов: (1) есть формальное требование к реестру Минцифры или соответствию 152-ФЗ — обе позиции закрыты записью №7378 и совместимостью с законом; (2) масштаб от 300–500 сотрудников и растёт — платформа рассчитана на 300 000+ пользователей в инсталляции и 1 млн корпоративных пользователей в общей базе, потолка вы не достигнете; (3) хочется одну лицензию вместо стека из чата, ВКС, видеохостинга, таск-менеджера и записи протоколов — платформа собирает эти функции в одном продукте.

Self-hosted open-source (Matrix + Element, реже — XMPP-стек, Nextcloud Talk как дополнение к файловому Nextcloud) остаётся правильным выбором, если формальных требований к реестру нет, у вас есть 1–2 инженера, готовых держать эксплуатацию, и вы понимаете, что коробочный AI-ассистент, встроенный видеохостинг и SIP собирать придётся самостоятельно. По нашему опыту, экономия на лицензии здесь окупается только на большом горизонте (3+ года) и при условии, что команда действительно любит свой стек и не выгорит на обновлениях Synapse и настройке TURN-серверов на второй год.

Небольшим командам до 50 человек без регуляторных требований часто честнее не платить ни за Frisbee, ни за поддержку Matrix, а остаться на публичном инструменте и вернуться к вопросу «свой мессенджер» ближе к 100 сотрудникам — это тот масштаб, где формальные требования начинают влиять на бизнес.

Финальная проверка перед выбором — три вопроса, которые мы задаём заказчику на пресейле. Первое: если завтра регулятор запросит отчёт «где физически хранится корпоративная переписка», у вас есть однозначный ответ? Если нет — нужен On-premise, любой публичный SaaS отпадает. Второе: сколько отдельных лицензий сейчас в контуре коммуникаций? Больше трёх — консолидация в Frisbee почти всегда даёт положительный TCO. Третье: есть ли у вас две инженерные ставки под эксплуатацию open-source? Если нет — не рассматривайте Matrix всерьёз, вы не сможете держать его на уровне production. Ответы на эти три вопроса дают конкретный класс решения быстрее, чем полугодовой пилот.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — ведущий инженер IT For Prof. Специализируется на архитектуре защищенных коммуникационных систем и импортозамещении корпоративного ПО. Имеет опыт миграции инфраструктур среднего и крупного бизнеса на отечественные платформы с сохранением непрерывности бизнес-процессов.