Self-hosted PostHog в 2026 году: установка, стоимость и подводные камни

У вас есть веб-приложение. Люди заходят в личный кабинет, кликают по ссылкам, а затем бесследно пропадают. Причины известны только им, и, вероятно, их кошкам. Какие возможности приложения им нужны? Почему они в конечном итоге сдались и ушли? Нужен тотальный редизайн или достаточно передвинуть на видное место кнопку “Сделать заказ”? Чтобы ответить на эти вопросы обычно требуется несколько аналитических инструментов, запись пользовательских сессий и таблица Excel, которая на текущий день держится на честном слове маркетолога.

PostHog обещает превратить весь этот “зоопарк” инструментов в единый дашборд. Для специалиста по маркетингу – это действительно так работает. Но вот для системного администратора или SRE инженера это клубок разнородных компонентов в контейнерах, каждый из которых отдельная головная боль. В этой статье мы установим PostHog и посмотрим как протиснуться через ошибки, которыми система попытается нас сбить с правильного пути.

Немного о стоимости

Особенность PostHog в том, что у него нет какой-либо абонентской платы или оплаты за пользователя. Есть всего два варианта – бесплатный тарифный план и pay-as-you-go. Разница между ними, по большому счёту, невелика – 1 проект и год хранения против 6 проектов и 7 лет хранения. Ну и уровень поддержки также различается – прямые обращения по электронной почте для free tier недоступны.

Теперь к особенностям биллинга – у каждого продукта есть собственный счётчик и единица измерения:

Лимиты указаны на момент написания статьи (сентябрь 2026)

Изюминка в том, что лимиты складываются, что приводит к тому, что небольшие проекты остаются на free tier годами. Маленькое приложение легко может одновременно вести аналитику, собирать ошибки, раскатывать фичи через флаги, крутить опросы и при этом ни разу не выйти за лимиты.

Но как только вы за них выходите – складывание начинает работать против пользователя. Все инструменты с тарификацией по monthly tracked users начнут давать постоянно растущую строку в счёте. “Лесенки цен” для каждого из продуктов, несмотря на то, что дают скидку с ростом объёма, усложняют расчёты, но самое главное – их много и они независимые:

Стоимость указана на момент написания статьи (сентябрь 2026)

Теперь представьте, что для конкретного пользователя вы создаёте профиль. Это сразу изменяет “лесенку цен”, которая для идентифицированных событий будет стоить почти в 4 раза дороже, после 1M событий. Теперь представьте, что у вас включен автозахват всех кликов и этот множитель легко может превратить ожидаемые $50 в несколько сотен. Схожим образом работает групповая аналитика для B2B сценариев и пайплайны выгрузки данных наружу.

Если взять три компании разного размера, включить одинаковые фичи и посмотреть на финальный счёт, то мы увидим примерно такую картину:

Приблизительная стоимость рассчитана на момент написания статьи (сентябрь 2026)

Справедливости ради отметим, что есть возможность выставить жёсткие ограничения, предохраняющие от больших счетов. Однако, это значит, что по достижении лимита данные перестанут попадать в очередь, а PostHog начнёт их отбрасывать до конца расчётного периода. С одной стороны вы не заплатите больше, но и общей картины за пределами лимитов уже не увидите.

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

Стоимость облачных серверов рассчитана на момент написания статьи (сентябрь 2026)

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

Подготовка к установке

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

⚠️  You REALLY need 8GB or more of memory to run this stack ⚠️

В реальности при установке стека на машину с 8GB ОЗУ – вы обязательно станете свидетелем великой битвы за ресурсы между ClickHouse и Kafka. Так что минимумом “на попробовать” будет выбор виртуальной машины с 16GB, а для продакшена рекомендуется 48GB или больше, чтобы исключить конкуренцию. Количество vCPU также имеет значение – стоит начинать с 4 и выше.

Окей – машину задеплоили, пора приступать к установке? На самом деле нет – для работы системы обязательно нужен отдельный домен. Если такового у вас нет – продолжать бессмысленно. Ну а если есть – смело ступайте к своему DNS-провайдеру и прописывайте запись вида:

posthog.example.com.    3600    IN    A    IP_ADDRESS

Всё дело в том, что при установке система автоматически настраивает HTTPS-соединение, для чего обращается к бесплатному сервису Let’s Encrypt за SSL-сертификатом. Чтобы получить последний – нужно доменное имя, которое было заранее настроено и уже присутствует глобально на всех DNS-серверах мира. Без этого установка попросту зависнет, а вы будете гадать – что же пошло не так.

Чтобы быть уверенным в том, что внесённая запись уже распространилась – можно использовать сервис DNS Propagation Checker. Вот пример ссылки – она поможет проверить распространение записей для нашего posthog.example.com:

https://www.whatsmydns.net/#A/posthog.example.com

Пускай вас не смущает обманчивая простота установки одной командой, которая есть в README репозитория проекта. Парадокс в том, что self-hosted вариант официально не поддерживается и выложен как “хобби-вариант” для энтузиастов и любителей open-source. У него нет версионирования, поскольку все изменения доставляются непрерывно из ветки master в Cloud-вариант и latest образ Docker.

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

Добавьте к этому то, что Helm-чарт ушёл в deprecated ещё с 2023 года, что оставляет ровно один правильный путь деплоя – docker-compose.hobby.yml исключительно на одной VM. Забудьте про горизонтальное масштабирование или HA – добиться этого можно только ценой глубокой переработки взаимодействия сервисов.

Ещё один неприятный момент: некоторые фичи, важные для больших команд, попросту не включены в self-hosted вариант. Например, базовое распределение ролей тут есть (Владелец, Админ, Участник) плюс персональные API ключи с ограниченными правами. Но создать кастомную роль, задать ограничения по ресурсами или лимиты на уровне свойств нельзя. Всё это работает только в оригинальном облаке и не включено в бесплатные лимиты использования. То же самое относится к SAML SSO и работе с множеством проектов – у self-hosted доступен только один проект.

Установка

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

root@posthog:~# curl -sSL https://get.docker.com/ | sh

Запускаем деплой:

root@posthog:~# /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/posthog/posthog/HEAD/bin/deploy-hobby)"

Отвечаем на вопрос инсталлятора о том, какую версию установить:

What version of PostHog would you like to install? (We default to 'latest')
You can check out available versions here: https://hub.docker.com/r/posthog/posthog/tags

И буквально через пару минут получаем ошибку, которая не даст продолжить:

⠦ property-defs-rs Pulling
0.7s
Error response from daemon: pull access denied for minio/minio, repository does not exist or may require 'docker login'
Failed to start stack after 3 attempts

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

Самым простым вариантом добавить нужный образ в развёртывание станет написать override для Docker Compose, но прежде всего нам потребуется скачать образ со слоями:

root@posthog:~# cd ~

root@posthog:~# docker pull quay.io/minio/minio:RELEASE.2025-04-22T22-12-26Z

Теперь создаём крошечный YAML-файл где прописываем, что образ объектного хранилища надо брать в другом месте:

root@posthog:~# cat > ~/docker-compose.override.yml <<'EOF'
services:
  objectstorage:
    image: quay.io/minio/minio:RELEASE.2025-04-22T22-12-26Z
EOF

И запускаем сборку, дополнительно указывая override:

root@posthog:~# docker compose -f docker-compose.yml -f docker-compose.override.yml up -d

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

Веб-страница процесса первоначальной настройки

Необходимость обслуживания

Вот мы и пришли к самому интересному. Установка установкой, но настоящая проверка стека начинается, когда что-то идёт не так. Забегая вперёд – так бывает в 100% случаев – рано или поздно. Здесь мы готовы поделиться тем, с чем столкнулись сами.

Чистый деплой на сервер. Несколько дней всё работало как часы, однако в какой-то момент выяснилось, что события и записи сессий никуда не долетают. При этом контейнеры с ClickHouse, Postgres, Redis и прочие – стабильно “зелёные” в docker ps. Стали выяснять причину и она оказалась образцово-показательной.

Стек был несколько дней без присмотра и за это время произошёл короткий сетевой сбой, вызванный самим Docker. Он пересоздавал bridge-интерфейсы контейнеров и один из них (capture) в какой-то момент потерял возможность резолва kafka:9092.

И тут кроется интересное – в стеке контейнеры capture и replay-capture являются теми, кто принимает фактически весь трафик от JS-сниппета и session-replay. Потеря Kafka для них – трагедия мирового масштаба и повод инициировать завершение работы по health-check. Заметьте – корректному завершению (в логах exit code 0).

Вот тут и всплывает засада – для этих сервисов перезапуск предусмотрен только при сбое (restart: on-failure). Docker же сам по себе не станет перезапускать контейнер, вышедший штатно с кодом 0 – для него это не сбой, а вполне корректное завершение работы.

По итогу сервисы пролежали 5 суток в течение которых эндпойнты /e/, /batch/ и /s/ отдавали 502-ю ошибку. События и записи сессии за эти 5 дней не сохранились. Ну а остальному стеку было всё равно – его попросту никто не трогал.

Справедливости ради глянули и на перезапуски других контейнеров в связи с этим сетевым инцидентом. Действительно – web, clickhouse и другие – выполнили рестарт по 1-2 раза (worker аж 7 раз). Там система честно вернула их в строй и дальше они работали штатно.

Засада в том, что по логам самого PostHog такое выяснить не выйдет – упавшие контейнеры ушли из вывода docker ps, а сообщение об ошибке было стёрто вместе с контейнером. Единственным надёжным способом обнаружить такой сбой – смотреть на факт поступления событий в ClickHouse или читать извне код ответа /e/. Таким образом вывод прост – внешний мониторинг PostHog практически обязателен. Ну а ничего сложного в “починке” не было:

root@posthog:~# docker compose restart capture replay-capture capture-logs

Чтобы в будущем избежать такой неприятности имеет смысл переписать правило перезапуска:

root@posthog:~# cat >> ~/docker-compose.override.yml <<'EOF'
  capture:
    restart: always
  replay-capture:
    restart: always
  capture-logs:
    restart: always
EOF

Ну и на будущее нужен хотя бы базовый алерт на доступность /e/ или счётчик событий в ClickHouse. В противном случае проблема может всплыть снова – стек будет выглядеть здоровым, а данные собираться не будут.

Заключение

PostHog – наиболее простой вариант поднять собственную систему аналитики. Несомненные преимущества self-hosted варианта – полный контроль над данными, возможность дорабатывать систему под себя и предсказуемые облачные счета.

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

Разумеется, self-hosting всегда требует больше внимания. Теперь вы в прямом смысле оператор трёх десятков контейнеров с сервисами за которыми некому смотреть кроме вас. Так что внешний мониторинг не опция, а суровая необходимость. Объектное S3-хранилище сразу использует устаревшую версию MinIO, поэтому имеет смысл сразу же переехать на внешнее облачное или хорошо обслуживаемый локальный вариант. Ну и из коробки тут нет ни отказоустойчивости, ни горизонтального масштабирования.

Тем не менее, это не повод всё бросить и оставить эту затею. Вышеперечисленные сложности – неизбежная плата за то, что вы сами контролируете данные и программный стек. Если уделить достаточно внимания “острым углам” в самом начале и ваш трафик начнёт расти – никто вам не помешает позже добавить HA и масштабирование прямо в существующую платформу.