Не всё в SaaS: почему компании снова смотрят на self-hosted-сервисы

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

SaaS помог бизнесу быстро запуститься, но рост обнаружил обратную сторону: сложнее контролировать расходы, данные и условия, от которых зависит работа команды. Поэтому компании пересматривают не облачную модель как таковую, а привычку автоматически покупать подписку под каждую новую задачу.

Self-hosted — не обязательно сервер в офисе

Self-hosted означает, что приложение работает в инфраструктуре, которую контролирует компания или выбранный ею подрядчик. Это может быть собственное оборудование, частное облако, выделенный сервер или виртуальный сервер. Отличие от классического SaaS не столько в физическом расположении, сколько в распределении ответственности.

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

Поэтому self-hosted — не «бесплатный SaaS», а другая операционная модель.

Почему интерес к self-hosted возвращается

Расходы становятся сложнее прогнозировать

На старте SaaS часто дешевле: не нужно проектировать инфраструктуру и выделять администратора. Но один сервис считает сотрудников, другой — контакты, третий — запуски сценариев, четвёртый — объём данных. Рост проекта увеличивает сразу несколько счетов, хотя новых направлений бизнес не запускал.

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

Данные становятся частью бизнес-актива

История заявок, аналитика, сценарии автоматизации и внутренняя база знаний содержат сведения о клиентах, рекламе и устройстве процессов. Self-hosted позволяет точнее определить, где размещаются данные, кто имеет административный доступ, сколько хранятся журналы и куда уходят резервные копии.

Но собственный сервер не обеспечивает соответствие закону автоматически. Нужно учитывать цели и основания обработки, состав данных, доступ сотрудников и подрядчиков, меры защиты и локализацию. Роскомнадзор указывает, что при сборе персональных данных граждан России через интернет запись, систематизация, накопление, хранение, уточнение и извлечение должны выполняться с использованием баз данных на территории РФ, кроме предусмотренных законом исключений.

Self-hosted даёт инструменты контроля, но не заменяет юридическую и организационную работу.

Интеграции выходят за рамки тарифов

SaaS удобен, пока бизнес укладывается в готовые сценарии. Сложности начинаются, когда требуется объединить CRM, сайт, телефонию, рекламные кабинеты и внутренние API, хранить расширенную историю или запускать собственную обработку данных.

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

Однако свобода доработки создаёт новую зависимость. Если интеграции не документированы, а вся логика известна одному разработчику, vendor lock-in просто заменяется зависимостью от конкретного сотрудника.

Где self-hosted действительно оправдан

Self-hosted стоит рассматривать для систем, где дополнительный контроль даёт измеримый эффект.

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

Во-вторых, постоянная нагрузка, при которой SaaS заметно дорожает из-за пользователей, операций или хранилища. Сравнивать нужно полную стоимость владения за 12–24 месяца, а не цену подписки со стоимостью сервера.

В-третьих, процессы с глубокой интеграцией. Если приложение связано с сайтом, CRM, складом, BI и внутренними API, возможность менять конфигурацию и работать с данными напрямую может быть важнее удобства подписки.

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

Когда SaaS остаётся лучшим решением

Если функция типовая, не относится к конкурентному преимуществу и используется небольшой командой, собственная инсталляция может только увеличить расходы. SaaS также рациональнее для продуктов, ценность которых связана с постоянно обновляемой внешней базой, сложной глобальной инфраструктурой или большим количеством готовых интеграций.

Подписка предпочтительнее и тогда, когда в компании нет ответственного за эксплуатацию. Установить приложение можно за вечер. Поддерживать его безопасно несколько лет — другая задача.

Практичный подход — разделять сервисы по критичности. Типовые инструменты оставить в SaaS, а аналитику, автоматизацию, хранение документов и внутренние приложения оценивать отдельно.

Главная ошибка — сравнивать подписку только с ценой сервера

В полную стоимость self-hosted входят инфраструктура, лицензии, настройка, обновления, мониторинг, резервирование, время специалистов и восстановление после инцидентов.

Отдельно нужно проверять лицензию. Возможность скачать продукт не всегда означает право бесплатно использовать его в любом коммерческом сценарии. Некоторые проекты разрешают внутреннее использование, но ограничивают перепродажу, встраивание в клиентский продукт или предоставление сервиса третьим лицам.

У системы должен быть владелец: человек или команда, которые следят за обновлениями, журналами, доступами, ресурсами и откатами.

Наличие копий тоже не равно готовности к восстановлению. Резервные данные должны храниться отдельно, а процедура восстановления — регулярно проверяться. CISA рекомендует поддерживать изолированные резервные копии и тестировать их доступность и целостность в сценарии восстановления.

Для этого можно использовать отдельное резервное копирование. В план должны входить не только файлы приложения, но и база данных, конфигурация, секреты, пользовательские загрузки и инструкция по запуску. На странице AdminVPS указано, что копии могут создаваться по расписанию и храниться отдельно от основного сервера.

Как перейти к self-hosted без нового хаоса

Начать стоит с инвентаризации: выписать SaaS-сервисы, владельцев аккаунтов, стоимость, лимиты, типы данных, интеграции и последствия недоступности.

Для пилота лучше выбрать ограниченный сценарий: внутреннюю базу знаний, аналитику отдельного проекта, мониторинг или автоматизацию, которая не останавливает продажи при сбое.

До запуска нужно определить:

— какие данные переносим и где они хранятся;

— кто отвечает за приложение и сервер;

— как тестируются обновления и откаты;

— какие показатели контролирует мониторинг;

— сколько данных допустимо потерять и за какое время сервис должен восстановиться;

— как выгрузить данные и перенести систему.

Если внутри компании нет нужной компетенции, ответственность можно разделить. Команда управляет приложением и бизнес-логикой, а установка, обновления, мониторинг и реакция на инфраструктурные сбои передаются специалистам по администрированию серверов. По официальному описанию AdminVPS, услуга включает первичную настройку, перенос проектов, проверки состояния и обновлений, а также реагирование на инциденты.

После пилота следует сравнить стоимость, время сопровождения, стабильность, скорость изменений, удобство пользователей и сложность восстановления. Если self-hosted выигрывает только на бумаге, а команда постоянно решает технические проблемы, модель выбрана неверно или плохо реализована.

Не отказ от SaaS, а право выбирать

SaaS позволяет быстро запускать инструменты без отдельного инфраструктурного проекта. Self-hosted возвращает контроль там, где зависимость от тарифа, поставщика или закрытой платформы становится заметным бизнес-риском.

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

Экспертный комментарий AdminVPS. Self-hosted стоит рассматривать не как способ перестать платить за подписки, а как инвестицию в управляемость. Если у сервиса нет владельца, резервного плана и процедуры обновления, собственный сервер не даст больше контроля — он только перенесёт риски внутрь компании.