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

Через три месяца на self-hosted Keitaro-боксе по-настоящему больно становится не от счёта за VPS в $30. Больно от одиннадцати часов, которые разработчик потратил на перенос базы кликов на диск побольше, когда логи перевалили за 40 ГБ, плюс девяносто минут тихого даунтайма во время пятничного всплеска трафика, который никто не заметил, пока байер не спросил, почему перестали прилетать постбеки. Сам сервер стоит почти ничего. А обслуживание сервера стоит недели чьего-то внимания — а внимание это тот самый ресурс, который команда медиабаинга не может потратить дважды.

Вот реальный вопрос, который прячется за “self-hosted или облачный трекер”. Дело редко в том, какой редирект-движок быстрее — Keitaro, Binom, Voluum и десяток опенсорс-форков одинаково прилично роутят клики и ловят постбеки. Вопрос в том, кто берёт на себя операционный риск, когда что-то ломается посреди масштабирования, и стоят ли эти часы того, чтобы тратить их на оптимизацию кампаний, а не на патчинг серверов.

Что на самом деле значит self-hosted

Когда Keitaro, Binom или похожий трекер крутится на собственном VPS или выделенном сервере, вы получаете полный контроль над стеком — собственные домены, базу данных, логику редиректов и данные о кликах на инфраструктуре, которую выбрали лично вы. Для технически сильной команды, которая уже гоняет серьёзные объёмы через проверенных провайдеров, этот контроль по-настоящему ценен. Никто сверху не трогает ваши логи, вы сами решаете, когда апгрейдить железо, и можете построить логику редиректов, которую ни один вендорский интерфейс никогда не вынесет в настройки.

Но есть нюанс: вы также навсегда берёте на себя всё, что может пойти не так, а не только в день настройки. Трекер под реальной нагрузкой — это не проект “настроил и забыл”, а постоянное DevOps-обязательство: продление SSL, рост базы, которую рано или поздно придётся партиционировать, ротация логов до того, как диск забьётся посреди кампании, защита от DDoS, когда конкурент или заскучавший скрипт решит, что ваш редирект-домен стоит атаки, рантайм-патчи для софта трекера и ОС под ним, и звонок в самый неудобный час, когда домен зафлагали или CPU упирается в потолок именно в тот всплеск, которого вы так ждали.

Реальная стоимость self-hosted — то, что прячется за счётом за сервер

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

• Вычислительные мощности — рассчитаны на пиковый трафик, а не на средний. Недооцените — и кампании захлёбываются именно в тот всплеск, на который вы рассчитывали масштабироваться.
• Redis — большинство трекеров опираются на него для кеширования и очередей; ему нужен отдельный мониторинг, свой лимит памяти и свой план восстановления, когда он падает под нагрузкой.
• ClickHouse или MySQL на масштабе — логи кликов и конверсий растут быстро. Несколько миллионов кликов в месяц — это ещё управляемая таблица; десятки миллионов — это уже проблема партиционирования и retention-политики, которая сама себя не решит.
• Бекапы, которые реально протестированы — бекап, из которого никто ещё не восстанавливался, это вера, а не бекап. Тестирование восстановления стоит времени каждый месяц, а не один раз.
• Патчинг безопасности — софт трекера, ОС, движок базы данных, reverse proxy — у каждого свой график релизов и своя история CVE, за которой нужно следить.
• Дежурство (on-call) — кто-то должен быть на связи, когда поток перестаёт слать постбеки в 2 часа ночи в субботу, посреди масштабирования.
• Риск потери данных — конфигурация с одним регионом и одним сервером имеет одну точку отказа. Повреждение диска, неудачная миграция или сбой у провайдера могут стоить истории атрибуции, которую потом дорого объяснять партнёрскому менеджеру, чей payout больше не сходится с вашими цифрами.

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

Self-hosted, иллюстративный пример (не смета):
  VPS / выделенный сервер ............ $40 - $150
  Хранение бекапов .................... $10 - $30
  Ротация доменов / SSL ............... $5 - $20
  Обслуживание Redis + ClickHouse ..... 6 - 15 ч/мес
  Патчинг и безопасность ............... 3 - 6 ч/мес
  Реагирование на инциденты, в среднем . 2 - 8 ч/мес
  -----------------------------------------------
  Денежные затраты: примерно $55 - $200/мес
  Время команды: примерно 11 - 29 ч/мес, по цене
              реальной стоимости часа разработчика
              для вашего бизнеса, а не той, что
              указана в счёте

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

Когда self-hosted действительно выигрывает, а когда это ложная экономия

Всё это не делает self-hosted плохим выбором — это делает его плохим дефолтом для определённого типа команд. Компромисс обычно становится очевидным в нескольких конкретных ситуациях.

Self-hosted действительно выигрывает, когда:

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

Это ложная экономия, когда:

• Двое-пятеро медиабайеров превращаются в сисадминов по совместительству, потому что больше некому патчить сервер.
• “Экономия” от дешёвого VPS исчезает в первый же раз, когда масштабирование совпадает с аутеджем, который никто вовремя не заметил.
• Бекапы есть, но из них ещё никогда не восстанавливались, поэтому реальное время восстановления после сбоя неизвестно, пока его не проверили под давлением.
• Партиционирование ClickHouse или исправление лимита памяти Redis постоянно откладывается, потому что всегда находится кампания, которая кажется более срочной — пока однажды выбора уже не остаётся.

Что на самом деле значит “облако” (managed) — и кому вы доверяете

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

Честный минус никуда не делся: вы доверяете третьей стороне данные о кликах, конверсиях и финансах, а сами привязаны к их roadmap и ценовой политике. У зрелой платформы с резервированной инфраструктурой в нескольких регионах плохих дней должно быть значительно меньше, чем у одиночного self-managed сервера — но “меньше” не значит “ноль”, так что стоит напрямую спросить любого вендора, как он обрабатывает отказ региона и экспорт данных, прежде чем заходить на серьёзный объём.

Нюанс, который часто теряется в этом споре: managed не значит, что ваши данные автоматически становятся данными вендора. Хорошо построенная managed-платформа всё равно обрабатывает и хранит данные о кликах, конверсиях и финансах на серверной стороне, привязанные к вашему воркспейсу, и их можно экспортировать по запросу — вы арендуете операции, а не отдаёте актив.

Трение при миграции: что на самом деле происходит при переходе

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

• Перенаправление каждого postback URL в каждой партнёрской сети и оффере, по одному, потому что эндпоинт меняется.
• Перерегистрацию трекинговых доменов и DNS, с задержками распространения, которые могут стоить атрибуции в окне перехода.
• Экспорт исторических данных о кликах и конверсиях в формате, который новая система реально сможет проглотить, а не просто CSV, который никто не проверял на пробелы.
• Переобучение команды новым дашбордам и новым местам, где искать отчёты, которые они проверяют каждый день.
• Параллельное окно проверки, когда обе системы логируют трафик одновременно, потому что первый раз, когда вы обнаружите расхождение, не должен случиться посреди живого масштабирования.

Именно эту часть вендоры с обеих сторон любят замалчивать. Жёсткий переход — старую систему выключили, новую включили, надеемся, что все постбеки долетели — это ровно тот способ, которым команды теряют неделю истории атрибуции посреди масштабирования: ту самую боль, которую это решение должно было снять, а не воссоздать.

Self-hosted vs облако: матрица решений

Ни одна из колонок не является универсально правильной. Крупная партнёрская сеть со своими инженерами вполне обоснованно может отдать предпочтение self-hosted уже хотя бы из-за аргумента резидентности данных. А компактная команда из двух-пяти человек, которая ведёт десятки потоков в Facebook и TikTok, обычно не может позволить себе кого-то на дежурстве ради uptime трекера — для них накладные расходы на обслуживание тихо съедают маржу, которую трекер должен был защищать.

Где здесь место DarkCore — managed-облако, ваши данные остаются вашими, плюс синхронизация с Keitaro

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

Под капотом это значит ноль server ops с вашей стороны — не нужно подбирать VPS, нянчить Redis или ClickHouse, не будет звонка в 2 часа ночи, когда зафлагали домен. Но данные о кликах, конверсиях и финансах остаются на серверной стороне, привязанные к вашему воркспейсу, а не заперты в формате, который принадлежит только вендору и который невозможно вытащить. Вы аутсорсите операции, а не отдаёте актив.

Часть, которая реально решает описанную выше проблему трения при миграции: PWA-трекер DarkCore поддерживает одновременную синхронизацию с Keitaro. Если ваша команда уже держит self-hosted инстанс Keitaro — по соображениям комплаенса, из-за уже вложенных в инфраструктуру денег или потому что один человек знает его как свои пять пальцев — вам не нужно вырывать его с корнем, чтобы получить managed CRM, серверный роутинг постбеков по потоку и статусу или реальный P&L на основе депозитов. Оба источника питают один и тот же слой аналитики, так что Keitaro продолжает обрабатывать уже построенный вами роутинг, а DarkCore сверху отвечает за финансы, права команды и маппинг Facebook Conversions API — проверяйте обе системы параллельно столько, сколько нужно, прежде чем решать, переходить ли полностью, если вообще решите переходить.

Это действительно другой путь миграции, чем привычный переход по принципу всё-или-ничего. Более подробное сравнение функция-к-функции смотрите в DarkCore vs Keitaro и DarkCore vs Binom, если сравниваете не только модель хостинга. А если флаги на доменах или надёжность редирект-цепочек тоже часть того, что влияет на решение, слой доменов — с ротацией и health-check на серверной стороне — обычно и есть та деталь, которая перевешивает чашу весов.

Типичные ошибки

• Сравнивать только счёт за хостинг, а не часы на обслуживание. VPS за $40/мес выглядит дешевле подписки, пока часы, потраченные на поддержание его живым, не оценить по реальной стоимости времени разработчика для бизнеса.
• Никогда не тестировать восстановление из бекапа. Непроверенный бекап — это вера, а не план восстановления: первый реальный тест не должен выпадать на настоящий аутедж.
• Относиться к миграции как к одним выходным с жёстким переключением. Перенаправление postback URL и повторная проверка доменов без параллельного окна проверки — это то, как команды теряют атрибуцию посреди масштабирования.
• Считать, что “managed” автоматически значит потерю данных. Не каждая managed-платформа запирает данные в проприетарном формате — проверьте, есть ли экспорт, прежде чем считать self-hosted единственным путём к реальному владению.
• Выбирать self-hosted ради контроля, которым вы никогда не воспользуетесь. Полный доступ к серверу звучит ценно, пока не посчитаете, как часто команда реально трогает логику редиректов, которую не поддерживает ни один вендорский UI — у большинства команд это редкость, тогда как накладные расходы DevOps идут каждый день независимо от этого.

FAQ

Действительно ли self-hosted трекер дешевле облачного?

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

Могу ли я одновременно держать self-hosted Keitaro и managed облачный трекер?

Да — именно под эту модель построена одновременная синхронизация DarkCore с Keitaro. Сохраняете существующий роутинг Keitaro и получаете CRM, финансы и серверный трекинг конверсий DarkCore на тех же данных, без принудительного перехода.

Какой самый большой риск self-hosted трекера?

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

Сколько времени занимает миграция между self-hosted и managed?

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

Честный ответ

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

Если ваша текущая схема забирает больше часов на нянчение сервера, чем на тестирование креативов и масштабирование, напишите нам в Telegram и разберите, как мог бы выглядеть managed-воркспейс для ваших потоков — с сохранением существующего Keitaro рядом или без него.