Экономика self-hosted: что выгодно держать у себя, а что нет

MAATRIX

Рано или поздно у любой команды набирается десяток облачных подписок — аналитика, чат, диски, CI/CD, база знаний — и кто-то задаёт вопрос: а не дешевле ли часть этого поднять на своём сервере? Правильный ответ не «self-hosted всегда выгоднее» и не «облако всегда проще» — это вопрос конкретных критериев, применённых к конкретному сервису и конкретной команде. Разберём эти критерии по порядку, без религии в обе стороны.

Почему нет универсального ответа

Спор «self-hosted против облака» часто ведут так, будто это вопрос идеологии: одни за независимость и контроль, другие за удобство и «пусть болит у кого-то другого». На практике это инженерный расчёт с четырьмя переменными, и для разных сервисов в одной и той же компании ответ может быть разным. Аналитику вы вполне можете держать у себя, а почту — оставить у провайдера, и это не противоречие, а следствие разной экономики этих двух сервисов.

Ошибка, которую видно чаще всего: считают только цену подписки против цены сервера. Сервер за небольшую фиксированную сумму в месяц действительно часто дешевле подписки на популярный SaaS. Но в стоимость self-hosted решения входит не только аренда VPS — туда входит время на установку, время на обновления, время на бэкапы, время на разбор инцидентов в три часа ночи и риск того, что именно в критичный момент сервис окажется недоступен, а чинить его некому. Учитывать нужно совокупную стоимость владения (TCO), а не только счёт за сервер.

Четыре критерия ниже — это не формула с весами, а чек-лист, который вы прогоняете по каждому сервису отдельно. Если по большинству критериев ответ склоняется в сторону self-hosted — переносите. Если нет — оставляйте в облаке, и это будет рациональным решением, а не капитуляцией.

Критерий 1: предсказуемость нагрузки

Первый вопрос — насколько стабильна нагрузка на сервис во времени. Здесь логика простая и симметричная тому, как соотносятся VPS и эластичное облако вообще: фиксированная ёмкость выгодна при стабильной нагрузке, оплата по факту — при сильно переменной.

• Стабильная нагрузка → self-hosted выгоднее. Если сервисом пользуется примерно одинаковое число людей примерно одинаково интенсивно каждый день — вики компании, внутренний чат, аналитика с равномерным потоком визитов — вы платите за сервер фиксированную сумму и используете его ёмкость почти полностью. Здесь простаивающих ресурсов, за которые вы переплачиваете, почти нет.
• Пиковая или сезонная нагрузка → чаще выгоднее облако. Если нагрузка скачет в разы — распродажа раз в квартал, всплеск трафика при вирусном посте, резкий рост парсинга данных под конкретную задачу — держать сервер, рассчитанный на пик, означает, что 90% времени вы платите за простаивающие ресурсы. Эластичный сервис или managed-решение с автоскейлингом здесь честнее по деньгам.
• Нагрузка, которую вы плохо понимаете (стартап, MVP). Пока неизвестно, будет ли у сервиса десять пользователей или десять тысяч, дешевле и безопаснее начинать в облаке или на managed-тарифе — и переносить на свой сервер уже тогда, когда паттерн использования стабилизировался и его можно посчитать.

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

Критерий 2: критичность экспертизы для поддержки

Второй критерий — сколько специфичных знаний о безопасности и эксплуатации требует конкретный сервис, и насколько дорого стоит ошибка. Это не про сложность установки — контейнер поднимается одной командой docker compose up -d практически для любого self-hosted продукта. Это про то, что происходит после установки, месяцами.

Диапазон здесь огромный:

• Почтовый сервер (Postfix/Dovecot). Один из самых дорогих в поддержке сервисов из всех, что можно себе поставить. Нужно настраивать и поддерживать SPF, DKIM, DMARC, следить за репутацией IP, вручную выбираться из спам-листов, если попали — а попадают туда легко и не всегда по своей вине. Ошибка здесь означает, что письма компании годами не долетают до части получателей, и это тихая проблема: узнаёте вы о ней не сразу.
• VPN-сервер (WireGuard, OpenVPN). Требует внимания к обновлениям и к тому, кто и как получает доступ, но поверхность атаки заметно уже, чем у почты, а ошибка конфигурации обычно видна сразу — сервис просто не работает, а не «работает наполовину» месяцами незаметно.
• Заметки, канбан-доска, внутренняя вики. Низкая цена ошибки: если инстанс Trilium, Wiki.js или BookStack на выходных полежит недоступным пару часов, это неприятно, но не катастрофа, и специфической экспертизы для базовой поддержки почти не нужно — обновил образ, снял бэкап, живи дальше.

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

Критерий 3: размер команды

Третий критерий — экономика на пользователя. Здесь арифметика прямая: подписка SaaS почти всегда стоит определённую сумму за место (seat) в месяц, а self-hosted сервер стоит фиксированную сумму независимо от того, сколько человек им пользуются.

Логика в том, что стоимость подписки растёт вместе с командой линейно (или почти линейно — многие тарифы дают скидку за объём, но редко перекрывающую разницу), а стоимость сервера от числа пользователей внутри его ёмкости не зависит вовсе. Инстанс Mattermost или Rocket.Chat, поднятый на одном VPS, обслуживает и 20, и 80 человек примерно за одну и ту же цену аренды — разница только в размере сервера, а не в количестве лицензий.

Обратная сторона: при команде в 2–3 человека время, которое кто-то из них потратит на установку и поддержку self-hosted сервиса, почти всегда стоит дороже, чем разница в деньгах с подпиской. Здесь self-hosted оправдан скорее из соображений контроля над данными или отсутствия vendor lock-in, а не по чистой экономике.

Критерий 4: заменяемость сервиса при проблемах

Четвёртый критерий — что происходит, если сервис откажет, и насколько быстро вы сможете либо его восстановить, либо обойтись без него. Это вопрос не вероятности отказа, а цены отказа для бизнеса.

• Некритичный, легко заменяемый сервис. Личные заметки, внутренний дашборд для мониторинга, RSS-читалка — если инстанс упал на день, это неудобно, но у команды есть время исправить это без потерь для клиентов и без остановки продаж. Здесь можно позволить себе self-hosted без избыточных инвестиций в отказоустойчивость: один VPS, бэкап раз в сутки, и этого достаточно.
• Критичный для бизнеса сервис. Система приёма платежей, CI/CD, от которого зависит выкладка продукта в прод, внутренний чат, через который координируется поддержка клиентов в реальном времени — здесь цена простоя считается не в неудобстве, а в деньгах и репутации за каждый час недоступности. Self-hosted вариант такого сервиса требует резервирования, мониторинга, отработанного плана восстановления — по сути, заранее прописанного disaster recovery плана, а не «если сервер упадёт, разберёмся по ситуации».

Здесь же стоит честно спросить: если self-hosted сервис откажет ночью, кто это заметит и кто будет чинить? Для облачного SaaS у вас есть, пусть и ограниченный, SLA провайдера и его дежурная поддержка. Для self-hosted инстанса на своём VPS вся ответственность лежит на вашей команде — и если в ней нет человека, готового встать ночью и восстановить сервис из бэкапа, критичный сервис лучше пока оставить в облаке, а self-hosted пробовать на менее важных вещах.

Как это выглядит по категориям сервисов

Ниже — типичная логика по пяти категориям, которые чаще всего обсуждают в контексте self-hosted. Это не рекомендация «всегда делайте так», а разбор рассуждения по всем четырём критериям для каждой категории.

Веб-аналитика (Matomo, Plausible, Umami). Нагрузка предсказуема — растёт вместе с трафиком сайта плавно, без резких скачков, если только не готовится масштабная рекламная кампания. Экспертиза для поддержки нужна минимальная: разница между Matomo и Plausible в основном в ресурсах и функциональности, а не в требованиях к безопасности — это не сервис, принимающий чужой трафик извне на постоянной основе, кроме сбора статистики. Команда любого размера выигрывает от переноса, потому что многие SaaS-аналитики берут деньги за объём событий, а self-hosted инстанс считает события бесплатно в пределах ресурсов сервера. Заменяемость высокая — потеря пары часов статистики не остановит бизнес. Итог: одна из самых очевидных категорий для self-hosted почти для любой команды.

Командный чат (Mattermost, Rocket.Chat). Нагрузка предсказуема при стабильном штате. Экспертиза выше средней — нужно следить за обновлениями и за интеграциями (боты, вебхуки, внешние подключения), но постоянного внимания к внешней репутации, как у почты, не требуется. Размер команды — ключевой фактор: экономия на self-hosted ощутимо растёт после 15–20 человек, для команды из трёх человек подписка часто проще. Заменяемость низкая, если чат — основной канал координации: здесь стоит закладывать резервный канал связи (хотя бы групповой чат в мессенджере) на случай простоя. Итог: выгодно для команд среднего и крупного размера при наличии человека, готового поддерживать сервис.

Хранение файлов (Nextcloud, Seafile). Нагрузка предсказуема по объёму данных, но может резко расти при синхронизации больших файлов — стоит закладывать запас по диску и по каналу заранее, а не по факту нехватки места. Экспертиза средняя: нужно настроить квоты, версионирование и бэкапы, Nextcloud и Seafile решают эту задачу немного по-разному, но оба требуют регулярного внимания к резервному копированию — это не «поставил и забыл» сервис. Экономика на команду выгодна почти сразу, потому что облачные тарифы на хранение часто считают за гигабайт, а self-hosted диск в разумных пределах стоит фиксированно. Заменяемость средняя — временная недоступность неприятна, но данные, если бэкапы настроены правильно, не теряются. Итог: выгодно при наличии дисциплины в бэкапах, рискованно без неё.

CI/CD (GitLab CE, Gitea Actions, Jenkins, Drone CI) — здесь нагрузка сильно неровная: пайплайны запускаются пачками при активной разработке и почти простаивают по ночам и в выходные, что формально довод в пользу облачных раннеров с оплатой за минуты сборки. Но на практике self-hosted раннер на одном постоянно арендованном сервере часто обходится дешевле, потому что фиксированная цена сервера ниже, чем оплата минут CI при активной команде разработки — здесь стоит один раз посчитать фактический расход минут за месяц и сравнить с ценой VPS. Экспертиза требуется на настройку раннеров и на изоляцию окружений сборки, но не критичная в смысле безопасности, если раннер не имеет доступа к продовым секретам напрямую. Заменяемость низкая для активной разработки — простой CI останавливает весь процесс релиза, поэтому здесь стоит держать резервный способ задеплоить руками. Итог: почти всегда выгодно для команды, разрабатывающей активно и постоянно, менее очевидно для проектов с редкими релизами.

База знаний / вики (Wiki.js, BookStack, Outline Wiki) — нагрузка минимальна и стабильна: это read-heavy сервис, который почти не создаёт пиков. Экспертиза для поддержки низкая — обновления редкие, риск для безопасности низкий, если доступ ограничен внутренней сетью или VPN. Экономика на команду почти всегда в пользу self-hosted, потому что многие SaaS-базы знаний берут по нарастающей за число редакторов, а не читателей. Заменяемость высокая — база знаний нужна для справки, а не в реальном времени, кратковременный простой не критичен. Итог: одна из самых безопасных категорий для первого эксперимента с self-hosted, если команда ещё не пробовала это делать вообще.

Общий паттерн виден: сервисы с низкой ценой ошибки и предсказуемой read-heavy нагрузкой (аналитика, база знаний) выигрывают от self-hosted почти без оговорок. Сервисы с высокой ценой простоя и высокими требованиями к безопасности (почта, платежи) требуют либо серьёзных инвестиций в self-hosted вариант, либо остаются в managed-сервисе осознанно, а не по умолчанию.

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