Umami vs Plausible: своя аналитика вместо Google Analytics на VPS

Тема Umami vs Plausible всплывает в любом обсуждении, где кто-то устал ставить Google Analytics на очередной сайт. Причина обычно не «хочу графики покрасивее» - причина в баннере cookie, который приходится городить ради одной строчки gtag.js, и в ощущении, что данные о ваших же посетителях лежат на серверах компании, которая зарабатывает именно на данных. Umami и Plausible - два самых популярных ответа на это: оба open-source, оба ставятся на свой сервер, оба показывают графики без единой куки для отслеживания. А вот дальше начинаются различия, и они не косметические - разный стек, разный аппетит к оперативной памяти, разная лицензия и разная логика вокруг того, что можно собирать. Разберём это по порядку и развернём один из двух вариантов прямо на VPS.

Коротко. Umami - это Node.js-приложение с базой PostgreSQL, лёгкое и простое в эксплуатации, лицензия MIT. Plausible Community Edition - Elixir/Phoenix плюс ClickHouse (для событий) и PostgreSQL (для остального), заметно тяжелее по ресурсам и лицензирован под AGPLv3. Для маленького VPS на 1-2 ГБ Umami - более практичный выбор: меньше сервисов, меньше того, что может отвалиться ночью. Plausible берут ради готовых воронок, revenue-трекинга и публичных дашбордов из коробки - если под ClickHouse не жалко отдельных 2+ ГБ памяти. Ниже - установка Umami через docker compose, nginx с HTTPS поверх, и отдельно - честный разбор того, почему self-hosted аналитика не гарантирует обход блокировщиков рекламы, вопреки распространённому мифу.

Зачем вообще уходить с Google Analytics

Первая причина - юридическая, и она бьёт по конверсии напрямую. Google Analytics использует cookie для отслеживания уникальных посетителей между визитами, а по GDPR и аналогичным законам это требует явного согласия перед установкой такой cookie. Отсюда баннер на весь экран, который видит каждый посетитель из Евросоюза - и который часть посетителей закрывает не глядя, отклоняя всё подряд, что портит статистику ещё до того, как она собралась. Umami и Plausible в стандартной конфигурации не используют cookie для идентификации: посетителя не «запоминают» между визитами через постоянный идентификатор, а уникальность считают статистически, по комбинации IP и User-Agent за сутки с солью, которая меняется ежедневно. Юридическая консультация не входит в объём этой статьи - но факт в том, что именно это чаще всего позволяет обойтись без баннера согласия вообще, и это главная практическая причина, ради которой люди вообще смотрят в сторону self-hosted аналитики. Вторая причина проще - собственность на данные. Сервер стоит у вас, база данных - тоже у вас, и никто третий не видит трафик вашего сайта, чтобы обучать на нём рекламные модели.

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

Umami vs Plausible: что у них внутри

Umami написан на Node.js - серверной среде выполнения JavaScript - и хранит данные в PostgreSQL (начиная с третьей версии - только в ней, поддержку MySQL из проекта убрали). Всё приложение - это по сути один процесс плюс база данных, лицензия - MIT, самая мягкая из массово используемых open-source лицензий: делайте с кодом почти что угодно, включая встраивание в коммерческий продукт, без обязательства публиковать свои изменения.

Plausible Community Edition устроен сложнее. Ядро написано на Elixir - языке для Erlang VM, спроектированной для параллельной обработки множества независимых соединений, - поверх фреймворка Phoenix. Данные о самих событиях (просмотры страниц, клики, конверсии) хранятся в ClickHouse - колоночной базе данных, заточенной под быструю агрегацию огромных объёмов аналитических записей, - а служебные данные (аккаунты, настройки сайтов) в отдельной PostgreSQL. Итого три сервиса вместо двух, и лицензия строже: AGPLv3, копилефт-лицензия, которая обязывает публиковать исходный код и ваших изменений, если вы предоставляете изменённую версию продукта другим людям через сеть - даже без физической передачи бинарника. Для личного использования на своём сервере это ничего не меняет. Для агентства, которое хочет предложить клиентам аналитику "как услугу" под своим брендом на модифицированном Plausible - меняет, и стоит хотя бы прочитать текст лицензии, прежде чем строить на этом бизнес.

Umami vs Plausible: таблица различий

Сколько ресурсов это реально просит у VPS

Здесь стоит разделить два вопроса: что говорит официальная документация и что видно на практике. Plausible честно называет цифру в своём README - для ClickHouse и Plausible вместе рекомендовано от 2 ГБ RAM, и это именно минимум под простой, не под нагрузку. ClickHouse - самый тяжёлый компонент связки: колоночным базам вообще свойственно резервировать память под буферы и индексы заранее, а не только под фактические данные. Добавьте геобазу городского уровня (MaxMind GeoLite2-City вместо страновой) - и по независимым оценкам это ещё около гигабайта сверху.

Umami в этом смысле проще - и официальная документация просто не называет цифру, потому что называть особо нечего: один процесс Node.js плюс обычный Postgres, оба хорошо себя чувствуют на ресурсах, которые не назовёшь щедрыми. Точные мегабайты приводить не будем - слишком легко соврать числом, которое никто не проверял вживую на VPS WeaselCloud (это прямо стоит в чек-листе «Проверить» к статье). Но практический вывод понятен уже сейчас: если у вас VPS на 1-2 ГБ и на нём уже крутится сайт, разница между «добавить ещё Umami» и «добавить ещё Plausible с ClickHouse» - это разница между «скорее всего не заметите» и «стоит сначала посчитать, сколько там реально остаётся свободного, командой free -h» (как это делать - в статье про сколько CPU и RAM нужно серверу).

Именно поэтому дальше разворачиваем Umami. Не потому что Plausible "хуже" - у него честные преимущества в глубине аналитики, - а потому что для типичного VPS весом в пару долларов в месяц лишний тяжёлый сервис ClickHouse часто не окупается тем, что он даёт.

Разворачиваем Umami через docker compose

Ставим Docker из официального репозитория самого проекта, а не из репозитория Ubuntu - версия там свежее, и docker compose идёт отдельным плагином, а не устаревшей командой через дефис.

sudo apt-get update

sudo apt-get install -y ca-certificates curl

sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

• $(. /etc/os-release && echo "$VERSION_CODENAME") - подставляет кодовое имя вашей версии Ubuntu автоматически, строку менять не нужно.
• docker-compose-plugin - это современный docker compose (два слова). Старая команда docker-compose через дефис - отдельный устаревший инструмент, он тут не нужен.

Проверка: docker compose version должна вывести строку вида Docker Compose version v2.x.x. Если вместо этого docker: 'compose' is not a docker command - плагин не встал, повторите последнюю команду установки.

Дальше - две случайные строки, которые понадобятся в compose-файле. Первая защищает сессии внутри приложения, вторая шифрует данные для двухфакторной аутентификации, даже если вы её не включаете сразу - переменная у Umami обязательная.

openssl rand -base64 32

openssl rand -hex 32

Каждая команда выведет одну случайную строку - скопируйте обе, они понадобятся в файле ниже как значения APP_SECRET и TWO_FACTOR_ENCRYPTION_KEY соответственно.

Создаём каталог и сам compose-файл:

sudo mkdir -p /opt/umami

cd /opt/umami

sudo nano docker-compose.yml

Содержимое файла - минимальная официальная схема из двух сервисов:

services:

umami:

image: ghcr.io/umami-software/umami:postgresql-latest

container_name: umami

restart: always

ports:

- "127.0.0.1:3000:3000"

environment:

DATABASE_URL: postgresql://umami:замените-пароль@db:5432/umami

APP_SECRET: вставьте-первую-строку-из-openssl

TWO_FACTOR_ENCRYPTION_KEY: вставьте-вторую-строку-из-openssl

depends_on:

db:

condition: service_healthy

healthcheck:

test: ["CMD-SHELL", "curl -f http://localhost:3000/api/heartbeat || exit 1"]

interval: 5s

timeout: 5s

retries: 5

db:

image: postgres:15-alpine

container_name: umami-db

restart: always

environment:

POSTGRES_DB: umami

POSTGRES_USER: umami

POSTGRES_PASSWORD: замените-пароль

volumes:

- umami-db-data:/var/lib/postgresql/data

healthcheck:

test: ["CMD-SHELL", "pg_isready -U umami -d umami"]

interval: 5s

timeout: 5s

retries: 5

volumes:

umami-db-data:

• 127.0.0.1:3000:3000 - порт публикуется только на loopback-адрес самого сервера, снаружи его не существует вообще. Это намеренно: наружу будет смотреть nginx, а не сам контейнер, - ниже разберём, почему это важно.
• замените-пароль в двух местах - в DATABASE_URL и в POSTGRES_PASSWORD - должен быть одной и той же строкой, придуманной вами. Это внутренний пароль между двумя контейнерами, наружу он никогда не выходит.
• APP_SECRET и TWO_FACTOR_ENCRYPTION_KEY - подставьте те две строки, что вывел openssl выше. Без них Umami либо откажется стартовать, либо сгенерирует свои значения сам и не покажет вам их - тогда при переносе на новый сервер потеряете доступ к зашифрованным данным.
• umami-db-data - именованный том Docker, здесь живут все реальные данные Postgres. Пересоздание контейнеров командой docker compose down (без флага -v) том не тронет.

Поднимаем оба сервиса и смотрим статус:

cd /opt/umami

sudo docker compose up -d

sudo docker compose ps

В колонке STATUS для обоих сервисов должно появиться running (а не restarting по кругу). Первый запуск занимает секунд десять - Umami должен создать таблицы в пустой базе, прежде чем ответить на первый запрос.

Проверить, что приложение реально ответило, можно без браузера:

curl -s http://127.0.0.1:3000/api/heartbeat

Если сервис жив, эндпоинт вернёт короткий JSON-ответ с кодом 200 - если вместо этого curl завис или вернул ошибку соединения, смотрите логи: sudo docker compose logs -n 50 umami.

Первый вход и трекинг-скрипт

Порт 3000 открыт только на localhost сервера, а домена и HTTPS у нас пока нет - значит, до первого входа добираемся через SSH-туннель, не открывая ничего наружу раньше времени.

ssh -L 3000:127.0.0.1:3000 root@ВАШ_IP

Пока эта сессия открыта, адрес http://127.0.0.1:3000 в браузере на вашем компьютере на самом деле ведёт на порт сервера. Логин по умолчанию - admin, пароль - umami. Это задокументированные дефолтные учётные данные, а не секрет, поэтому первое, что нужно сделать после входа - сменить пароль в настройках профиля, прежде чем открывать сервис наружу через nginx.

Дальше в интерфейсе добавляете сайт (домен, по которому он у вас известен) - и Umami сгенерирует тег для вставки на страницы, что-то вроде:

<script defer src="https://umami.example.com/script.js" data-website-id="ваш-id-сайта"></script>

Эту строку вставляете перед закрывающим </head> на каждой странице сайта, который хотите отслеживать - она подтянется автоматически на любом фреймворке, где можно вставить произвольный HTML в head.

nginx и HTTPS перед Umami

Открывать порт 3000 наружу напрямую - плохая идея сразу по двум причинам: во-первых, без TLS логин и пароль администратора идут по сети открытым текстом, во-вторых, ufw в принципе не фильтрует порты, которые Docker публикует сам - правило вида 127.0.0.1:3000:3000 в compose-файле выше уже решило эту проблему на корню, порт снаружи просто не существует. Базовые правила фаервола для остального сервера - в статье про ufw на VPS.

Серверный блок nginx - обычный обратный прокси, без особых заголовков вроде Upgrade/Connection, которые нужны инструментам с живыми WebSocket-обновлениями интерфейса (Umami в этом смысле проще):

server {

listen 80;

server_name umami.example.com;

location / {

proxy_pass http://127.0.0.1:3000;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}

}

Проверяем синтаксис и перечитываем конфиг, а не перезапускаем сервис целиком - reload не рвёт уже открытые соединения:

sudo nginx -t

sudo systemctl reload nginx

Сертификат - отдельным шагом после того, как HTTP уже отвечает на домене, обычно через certbot:

sudo apt install -y certbot python3-certbot-nginx

sudo certbot --nginx -d umami.example.com

Если certbot отработал успешно, он сам допишет в серверный блок редирект на HTTPS и подключит сертификат. Если сайт после этого не открывается, а с самим сервером всё в порядке - разбор кодов 404/502/504/413 есть в отдельной статье про ошибки nginx.

Блокировщики рекламы: самообман про self-hosted

Вот здесь стоит остановиться и честно поговорить про миф. Расхожая фраза "self-hosted аналитика не режется адблокерами, потому что она не Google" - была правдой лет пять назад. Сейчас - не совсем.

Списки фильтров вроде EasyPrivacy (на нём построена часть правил в uBlock Origin и похожих блокировщиках) давно матчат не по конкретному домену Google, а по паттернам в адресе. И оба - и Umami, и Plausible - уже попали в такие списки правил, причём именно как паттерн по имени хоста. Если ваш поддомен называется umami.example.com, analytics.example.com или буквально содержит слово вроде track - шанс, что часть посетителей с включённым адблокером вообще не попадёт в статистику, реальный. Не стопроцентный, но реальный.

Что реально помогает, а что нет. Самостоятельный хостинг сам по себе не спасает - критично именно имя хоста и имя файла скрипта. Назовите поддомен для аналитики нейтрально: не umami., не stats., не analytics., а что-то вроде произвольного технического имени, никак не намекающего на назначение. У Umami для этого же есть отдельная переменная окружения, которая переименовывает сам файл скрипта с script.js на что угодно ещё - в документации проекта это описано в разделе про обход блокировщиков.

Это не хак и не серая зона - вы не скрываете от посетителя факт сбора статистики, а просто не совпадаете со списком паттернов, написанным для рекламных трекеров, к которым self-hosted-инструменты для приватной аналитики технически не относятся. Но обещать читателю "поставите Umami - и адблокеры вас больше не тронут" было бы неправдой, а врать в статье про приватность как-то особенно неловко.

Что выбрать: Umami или Plausible

Если сайт один или их несколько и все небольшие, а VPS на 1-2 ГБ RAM - берите Umami. Меньше сервисов означает меньше того, что может упасть посреди ночи, а MIT-лицензия развязывает руки, если аналитику когда-нибудь захочется встроить во что-то своё.

Если нужны готовые воронки конверсии, трекинг выручки по заказам и публичные дашборды, отполированные из коробки, а лишний гигабайт-два памяти под ClickHouse не проблема - смотрите Plausible. Он честно даёт больше готовой аналитики "из коробки", просто за счёт более тяжёлой инфраструктуры вокруг.

Наш выбор для типичного VPS WeaselCloud - Umami, и не потому что Plausible хуже. Для 90% сайтов на трафике, который вообще имеет смысл смотреть на своём сервере, разница в глубине аналитики не окупает третий сервис в compose-файле, который ест память круглые сутки просто потому, что он есть.

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

Чем Umami отличается от Plausible?

Разный стек и разный вес. Umami - Node.js плюс PostgreSQL, два сервиса, лицензия MIT. Plausible Community Edition - Elixir/Phoenix, ClickHouse и PostgreSQL вместе, три сервиса, лицензия AGPLv3, и заметно тяжелее по памяти из-за ClickHouse.

Можно ли поставить свою аналитику вместо Google Analytics?

Да, и юридически это часто даже проще: Umami и Plausible по умолчанию не используют cookie для отслеживания посетителей, а значит во многих случаях не требуют баннера согласия по GDPR, который обязателен при использовании Google Analytics. Это не заменяет консультацию юриста для конкретного сайта, но снимает главную практическую причину, из-за которой люди вообще ищут альтернативу.

Сколько ресурсов VPS нужно для self-hosted аналитики?

Зависит от выбора. Plausible официально рекомендует минимум 2 ГБ RAM для связки с ClickHouse - и это минимум под простой, не под нагрузку. Umami заметно легче: официальных цифр проект не публикует, но по устройству это один процесс Node.js плюс обычный Postgres, и для маленького сайта такая связка комфортно живёт рядом с самим сайтом на том же недорогом VPS.

Обходит ли self-hosted аналитика блокировщики рекламы?

Не гарантированно. Списки фильтров вроде EasyPrivacy матчат и Umami, и Plausible по паттернам в имени хоста - если поддомен называется вроде umami. или analytics., часть посетителей с адблокером всё равно выпадет из статистики. Нейтральное имя поддомена и (для Umami) переименование файла скрипта снижают этот риск, но не убирают его полностью и навсегда, потому что списки правил обновляются.

Какая лицензия у Umami и у Plausible?

Umami - MIT, самая мягкая из массовых open-source лицензий: можно почти всё, включая встраивание в свой коммерческий продукт без обязательства раскрывать код. Plausible Community Edition - AGPLv3, копилефт-лицензия: если вы модифицируете продукт и предоставляете доступ к изменённой версии другим людям через сеть, обязаны опубликовать исходный код своих изменений.

Нужен ли баннер cookie для Umami или Plausible?

В стандартной конфигурации оба инструмента не ставят cookie для идентификации посетителей и считают уникальность статистически, без постоянного идентификатора - это часто позволяет обойтись без баннера согласия по GDPR. Точный ответ зависит от юрисдикции и от того, что именно вы настроили дополнительно, поэтому для конкретного сайта стоит свериться с юристом или актуальными рекомендациями по GDPR, а не полагаться только на маркетинговые заявления инструментов.

Коротко

• Umami - Node.js + PostgreSQL, два сервиса, лицензия MIT, легче в эксплуатации на маленьком VPS.
• Plausible Community Edition - Elixir/Phoenix + ClickHouse + PostgreSQL, три сервиса, лицензия AGPLv3, официально рекомендует от 2 ГБ RAM только под ClickHouse в простое.
• Оба инструмента по умолчанию не используют cookie для идентификации посетителей, что часто снимает необходимость в баннере согласия по GDPR.
• Для VPS на 1-2 ГБ практичнее Umami: меньше сервисов, меньше точек отказа. Plausible берут ради готовых воронок, revenue-трекинга и более развитой аналитики из коробки.
• Umami ставится через docker compose из двух сервисов, порт публикуется только на loopback, снаружи - nginx с HTTPS через certbot.
• Self-hosted аналитика не гарантирует обход блокировщиков рекламы - списки фильтров матчат по паттернам имени хоста вроде umami. или analytics., нейтральное имя поддомена снижает риск, но не убирает его полностью.
• Лицензия имеет практическое значение не только для юристов: AGPLv3 у Plausible требует раскрывать код изменений при предоставлении сервиса другим через сеть, MIT у Umami такого требования не ставит.

Что дальше

Прежде чем разворачивать что-то на VPS, разумно сначала прикинуть, какой тариф вообще нужен - в статье сколько CPU и RAM нужно серверу разобрано, как считать это по типу нагрузки и проверять на уже работающем сервере. Общий порядок выбора сервера - в пилар-статье как выбрать VPS. Базовые правила фаервола перед тем, как открывать порты 80 и 443 - в статье про ufw на VPS.