Как установить и настроить PostHog на VPS

MAATRIX

Продуктовая аналитика на облачных SaaS упирается в две вещи: цену за событие, которая растёт быстрее, чем бюджет, и данные пользователей, утекающие на сторонние серверы за рубежом. PostHog решает обе проблемы разом — это open-source платформа с воронками, записью сессий, feature flags и A/B-тестами, которую можно поднять на собственном VPS и полностью контролировать. Ниже — рабочий путь от чистого сервера до первого события в дашборде.

Что такое PostHog и когда его стоит держать у себя

PostHog — это не просто счётчик посещений, а полноценная product-analytics платформа: воронки конверсии, когортный анализ, session replay (запись действий пользователя в браузере), feature flags для постепенного раскрытия функций и встроенные A/B-эксперименты. В облачной версии (PostHog Cloud) всё это работает из коробки, но тарификация идёт по количеству событий, и при активном продукте счёт быстро становится ощутимым.

Self-hosted вариант снимает вопрос оплаты по событиям — вы платите только за сервер — и держит данные пользователей на площадке, которую выбираете сами. Для российского бизнеса это дополнительно снимает вопросы с 152-ФЗ: данные не покидают контролируемую инфраструктуру.

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

Требования к серверу и подготовка

PostHog в self-hosted варианте разворачивается через официальный docker-compose стек, который поднимает сразу несколько сервисов: веб-приложение, worker, plugin-server, ClickHouse, PostgreSQL, Redis, очередь событий и Caddy для автоматического SSL. Из коробки это не лёгкий инструмент.

Ориентировочные требования для комфортной работы небольшого проекта:

Это именно ориентир — точные цифры зависят от объёма трафика на вашем сайте или в приложении, длины хранения событий и включена ли запись сессий (она заметно прожорливее на диск). Начинайте с 8 ГБ RAM и расширяйтесь, если увидите, что ClickHouse или Kafka регулярно упираются в память — docker stats покажет это честно.

Подготовка сервера стандартная: обновить систему, создать пользователя без root, установить Docker и Docker Compose plugin, настроить фаервол. Если ещё не делали этого на новом VPS — у нас есть отдельный разбор настройки UFW на сервере, там же порядок правил для веб-сервисов.

sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
newgrp docker
docker --version
docker compose version

Домен обязателен для нормальной работы — PostHog поднимает SSL автоматически через Caddy, но для этого A-запись домена должна указывать на IP сервера ещё до запуска установки.

Установка PostHog через официальный скрипт

Самый надёжный способ поднять self-hosted PostHog — использовать официальный установочный скрипт из репозитория проекта, а не собирать docker-compose.yml вручную: слишком много сервисов, зависящих друг от друга по сети и переменным окружения, и разработчики сами поддерживают этот скрипт в актуальном состоянии под новые версии.

git clone https://github.com/PostHog/posthog.git posthog
cd posthog
sudo ./bin/deploy-hobby

Скрипт задаст несколько вопросов: домен, на котором будет доступен PostHog, email для Let's Encrypt (используется Caddy для выпуска сертификата) и — при первом запуске — сгенерирует стартовые пароли для внутренних сервисов. После этого он сам:

• поднимет docker-compose стек со всеми зависимостями (ClickHouse, PostgreSQL, Redis, очередь событий, plugin-server, web);
• настроит Caddy как обратный прокси с автоматическим HTTPS на 80/443 порту;
• применит миграции базы данных и запустит приложение.

Первый запуск занимает от 5 до 15 минут в зависимости от скорости диска и сети — образы контейнеров тяжёлые, ClickHouse и Kafka скачиваются дольше остальных. Прогресс видно в выводе скрипта, зависаний быть не должно.

Если вы уже используете nginx как единую точку входа для нескольких сервисов на сервере и не хотите отдавать 80/443 порт Caddy — вынесите Caddy на внутренний порт и проксируйте на него через nginx. Логика настройки reverse proxy для таких случаев подробно разобрана в статье про nginx как reverse proxy на VPS — те же принципы применимы и здесь, только upstream будет указывать на порт Caddy внутри docker-сети.

Домен, SSL и первый вход

После успешного завершения скрипта откройте https://ваш-домен в браузере. Caddy к этому моменту уже должен был выпустить сертификат Let's Encrypt автоматически — если сайт открывается без ошибок SSL, всё прошло штатно.

Проверить, что сертификат действительно валиден и не самоподписанный:

curl -vI https://ваш-домен 2>&1 | grep -i "SSL certificate"

Если сертификат не выпустился — почти всегда причина в том, что DNS A-запись ещё не успела распространиться, либо порт 80 занят другим процессом на сервере (проверьте sudo ss -tulpn | grep :80) и Caddy не смог пройти HTTP-01 challenge.

При первом открытии PostHog предложит создать организацию и первый проект, затем — учётную запись администратора (email и пароль). На этом же экране система выдаст project API key — его нужно будет вставить в SDK на сайте или в приложении, чтобы события начали поступать.

Если планируете приглашать команду по email (сброс пароля, инвайты), настройте SMTP в Settings → Email внутри интерфейса — без него письма просто не уйдут, а ссылки-приглашения нужно будет передавать вручную.

Feature flags, воронки и запись сессий — быстрый старт

Установка PostHog — это только инфраструктура, польза начинается с настройки трекинга. Минимальный SDK для веб-страницы:

<script>
  !function(t,e){var o,n,p,r;e.__SV||(window.posthog=e,e._i=[],e.init=function(i,s,a){
    function g(t,e){var o=e.split(".");2==o.length&&(t=t[o[0]],e=o[1]),t[e]=function(){
      t.push([e].concat(Array.prototype.slice.call(arguments,0)))}}
    (p=t.createElement("script")).type="text/javascript",p.crossOrigin="anonymous",
    p.async=!0,p.src=s.api_host+"/static/array.js",(r=t.getElementsByTagName("script")[0])
    .parentNode.insertBefore(p,r);var u=e;for(void 0!==a?u=e[a]=[]:a="posthog",
    u.people=u.people||[],u.toString=function(t){var e="posthog";return"posthog"!==a&&(e+="."+a),t||(e+=" (stub)"),e},
    u.people.toString=function(){return u.toString(1)+".people (stub)"},
    o="init capture register register_once alias people.set people.set_once".split(" "),n=0;n<o.length;n++)g(u,o[n]);
    e._i.push([i,s,a])},e.__SV=1)}(document,window.posthog||[]);
  posthog.init('ВАШ_PROJECT_API_KEY', { api_host: 'https://ваш-домен' })
</script>

Для бэкенда есть официальные библиотеки под Python, Node.js, PHP, Go, Ruby — логика та же: posthog.capture(distinct_id, 'event_name', properties).

Что настроить сразу после подключения:

• Воронки (Funnels) — задайте последовательность шагов (например, «зашёл на сайт → добавил в корзину → оформил заказ») и увидите, на каком шаге теряются пользователи.
• Feature flags — создаются в разделе Feature Flags, позволяют включать функцию для процента пользователей или конкретного сегмента без деплоя нового кода.
• Session replay — включается в Settings → Project → Session Recording. Учтите: это самая ресурсоёмкая функция, она пишет DOM-снапшоты и заметно увеличивает нагрузку на диск и ClickHouse — на слабом сервере лучше включать точечно, а не для 100% трафика.
• Когорты — группы пользователей по поведению или свойствам, пригодятся для таргетированных feature flags и рассылок.

Обновление, бэкапы и ограничения self-hosted

PostHog развивается быстро, и self-hosted версия требует регулярных обновлений — как минимум ради патчей безопасности. Стандартный порядок:

cd posthog
git pull
docker compose -f docker-compose.yml pull
docker compose -f docker-compose.yml up -d

Перед серьёзным обновлением (major-версия) обязательно смотрите changelog в репозитории — иногда меняется схема ClickHouse или формат конфигов, и накатывать вслепую на продакшен не стоит.

Бэкап self-hosted PostHog — это не один файл, а несколько компонентов:

• PostgreSQL — хранит метаданные (проекты, пользователей, feature flags, настройки). Бэкапится стандартно через pg_dump из контейнера.
• ClickHouse — хранит сами события, самая объёмная часть. Требует отдельного подхода к бэкапу (снапшоты volume или встроенные механизмы ClickHouse).
• Object storage (S3-совместимое хранилище или встроенный MinIO) — здесь лежат записи сессий и экспортированные файлы.

docker exec -t posthog-db-1 pg_dumpall -c -U posthog > posthog_pg_backup_$(date +%F).sql

Полноценный бэкап ClickHouse-данных лучше делать через снапшот docker volume целиком, пока сервисы остановлены, либо через штатные механизмы бэкапа ClickHouse — руками копировать файлы БД без остановки записи ненадёжно.

Здесь же стоит честно проговорить границы self-hosted PostHog: это не «поставил и забыл». Стек из пяти-семи сервисов требует мониторинга ресурсов, регулярных обновлений и понимания, что делать, если ClickHouse не поднимается после перезагрузки диска. Если у вас нет времени на эту рутину — можно начать с малого сервера для пилота, а параллельно присматриваться к более лёгким альтернативам вроде Matomo, если из полного набора PostHog вам нужна в основном веб-аналитика без воронок и feature flags. Для управления самим docker-стеком в продакшене пригодится и общий разбор Docker Compose для продакшена на VPS — там про health checks, restart policy и логирование, актуальные и для PostHog.

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