On-premise vs облако HR-системы — что выбрать для российской компании в 2026

Маркетинг on-premise HR-софта пишет сам себя: «ваши чувствительные данные сотрудников остаются на ваших серверах, вы контролируете обновления, никакого vendor lock-in». Маркетинговые страницы повторяют это везде. Большая часть — правда. Большая часть — нерелевантна для большинства команд.

Здесь честно про четыре сценария, когда on-premise развёртывание HR-софта правильно, и большее число сценариев когда нет — с учётом российской специфики.

Что on-prem реально меняет

При развёртывании HR-портала on-prem практические отличия от cloud SaaS:

Прочтите таблицу ещё раз, медленно. Почти каждое отличие двигает работу и риск от вендора к вам. Исключения — «где данные» и «когда апгрейды». Всё остальное теперь ваша проблема.

Четыре случая когда on-prem правильно

Случай 1: Регулируемая отрасль или 152-ФЗ строго.

Если вы в регулируемой отрасли (госкомпания, ОПК, кредитная организация по требованиям ЦБ, медорганизация с особым режимом данных пациентов) или у вас прямые требования по локализации данных по 152-ФЗ для категорий данных, которые требуют specifically российский хостинг — on-prem становится обязательным. SaaS-обхода нет. Выбирайте портал-вендора, который шипит on-premise-дистрибутив, и принимайте операционные накладные расходы.

Замечу: 152-ФЗ не запрещает SaaS как такового. Российский SaaS-хостинг (или зеркалирование данных в РФ) удовлетворяет требованиям локализации для большинства категорий. Прочитайте конкретную норму до того как считать что вам нужен on-prem.

Случай 2: Недоверие к любому SaaS на чувствительных данных.

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

• Риск банкротства / поглощения / утечки данных у вендора.
• Геополитические соображения (нестабильность зарубежных SaaS на фоне санкционного давления).
• Внутренняя политика прецедент («мы self-host'им wiki, должны self-host'ить и это»).

Это легитимная позиция, но будьте честны: вы меняете риск вендора на риск self-managed-инфраструктуры. Вероятность что ВАШ дамп БД будет скомпрометирован в следующие 5 лет — не ноль. У вендора может быть меньше (они на этом специализируются). Просчитайте реальную экспозицию.

Случай 3: Вы на размере, где SaaS-подписка превышает infra+ops cost.

Точка безубыточности для HR-софта — примерно 500–1000 сотрудников. Ниже этого SaaS per-seat обычно дешевле infra-VM + ops-time + license-fee self-hosting. Выше — математика может перевернуться.

Если вы 1500+ сотрудников и SaaS-счёт ₽1.5+ млн/год — self-hosted license-fee + долевой ops-инженер могут оказаться дешевле. Считайте под свои цифры.

Случай 4: Air-gap или near-air-gap среда.

Некоторые рабочие места (часть госов, часть ОПК, часть индустриальных) имеют сети, которые не могут достичь публичного интернета — или только через жёстко контролируемые шлюзы. SaaS не вариант, портал не может пинговать вендора.

Self-hosting на сервере внутри периметра — единственный вариант. Заметьте что даже self-hosted порталам обычно нужна какая-то внешняя связность (verify лицензии, security-апдейты) — проверьте что вендор поддерживает вашу конкретную connectivity-модель.

Случаи когда on-prem НЕправильно (большинство случаев)

Вы думаете что нужен 152-ФЗ-compliance, но у вас policy preference, а не норма.

Если не можете указать конкретный пункт регуляции, запрещающий vendor-hosted данные сотрудников — у вас не норма, у вас предпочтение. Предпочтения валидны, но их надо взвешивать с реальной стоимостью эксплуатации инфраструктуры.

Вы думаете что сэкономите, но не считали.

Self-hosting выглядит дёшево, потому что lic-fee виден. Стоимость инфры (VM, бэкапы, мониторинг), ops-время (инженер, который знает достаточно чтобы держать на ходу), стоимость окна апгрейдов (кто-то должен помнить применять security-патчи, кто-то должен быть on-call когда апгрейд ломает), support-debt (когда что-то ломается, нельзя эскалировать вендору как SaaS-клиент) — всё это реально и обычно невидимо пока не укусит.

Компания на 50 человек, которая self-host'ит «чтобы сэкономить», обычно тратит 4-8 часов engineering-time в месяц, которое могла бы тратить на свой реальный продукт, плюс 1-2 инцидента в год по дню каждый. Сравните с SaaS-счётом, который компания «экономит» — редко выходит в плюс.

Хотите кастомизацию.

Self-hosting не даёт кастомизации. Код вендорский; вы крутите его image. Единственная кастомизация — конфиги, которые вендор открывает. Если хотите форкнуть и модифицировать — нужен исходный код (большинство on-prem-вендоров его не дают), и тогда вы взяли поддержку продукта размером с оригинал.

Если реальная кастомизация важна — путь это «строить своё» или «купить API вендора и интегрировать» — не on-prem.

Нет ops-команды и не планируете нанимать.

Если «кто разбирается с сервером когда ломается» не имеет ответа — on-prem неработоспособен. SaaS абстрагирует это; on-prem требует кого-то на дежурстве. «Dev, который ещё знает Docker» — не ops-команда, особенно в 3 ночи.

Средний путь: хостинг в вашем cloud

Паттерн, который иногда пропускают: многие вендоры разворачивают свой SaaS в вашем cloud-аккаунте (ваш Yandex Cloud, ваш Selectel, ваш VK Cloud). Получаете data-локалити (данные в вашем аккаунте) без операционной нагрузки управления приложением (pipeline вендора апдейтит).

Часто правильный ответ для «нужна data-locality но не хотим ops-overhead». Не каждый вендор предлагает — спрашивайте.

Как DTPulse в это вписывается

Для контекста: DTPulse идёт в трёх конфигурациях.

• SaaS на dtpulse.ru — что должно использовать большинство клиентов. 5-минутный signup, всё managed вендором.
• Self-hosted on-prem — единый Docker-стек, VM клиента, lifecycle-managed лицензионный ключ с ежечасным phone-home heartbeat'ом (verify лицензии, никакие данные не покидают вашу установку). Скидка 15% к любому тарифу. Для случаев 1-4 выше.
• Хостинг в вашем cloud-аккаунте — case-by-case, обратитесь в продажи.

Мы не пушим on-prem тем, у кого ответ на «зачем on-prem» — размытый. Честный pitch для 50-person SaaS-эквивалентной компании — «используйте SaaS, реально дешевле и быстрее». On-prem-путь мы имеем в виду только для четырёх сценариев, где это правильный ответ.

Если оцениваете: прочитайте нашу on-prem доку для операционной формы, потом напишите в sales@dtpulse.ru обсудить ваш сценарий.

Связанное чтение

• Что такое корпоративный портал и когда он реально нужен компании
• SAML SSO для среднего бизнеса — подключаем Yandex ID, Keycloak, Azure AD