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

MAATRIX

Google Analytics требует баннер согласия на cookie, гоняет данные посетителей через серверы в другой юрисдикции и в целом выглядит избыточно тяжёлым инструментом, если вам нужны просто графики трафика и источники переходов. Matomo решает вопрос данных, но тянет за собой PHP, MySQL и заметно более сложную настройку. Umami — это узкоспециализированная альтернатива: один Docker-контейнер, встроенная PostgreSQL или MySQL, простой дашборд без лишних меню. Ставится на чистый VPS минут за пятнадцать, и дальше практически не требует внимания — разберём весь путь от голого сервера до первого отчёта.

Что такое Umami и когда он лучше Matomo или Google Analytics

Umami — open-source веб-аналитика на Node.js с минималистичным интерфейсом: посещения, источники, страны, устройства, referrers, кастомные события. Никакой записи сессий, тепловых карт или воронок — если нужен такой уровень детализации, разумнее смотреть в сторону Matomo или Plausible. Зато и ресурсов требует немного: приложению хватает 512 МБ — 1 ГБ RAM даже под несколько сайтов средней посещаемости, а база данных не растёт так стремительно, как у более «тяжёлых» систем, потому что Umami не хранит сырые логи запросов, только агрегированные события.

Ключевое отличие от Google Analytics — трекинг-скрипт Umami не использует cookie для идентификации посетителей (используется хешированный идентификатор без персональных данных), поэтому во многих юрисдикциях баннер согласия на cookie для базовой аналитики не требуется. Это не юридическая консультация и не гарантия для вашего конкретного случая — но именно поэтому Umami часто выбирают для лендингов и сайтов, где важно не показывать назойливый попап при первом заходе.

Сравнение по типичным критериям выбора:

Если вам нужна именно продвинутая аналитика с сегментацией и A/B-тестами, посмотрите статью Matomo на VPS — там другой набор компромиссов. Для быстрого старта и лёгкого хостинга Umami обычно выигрывает.

Подготовка VPS и установка Docker

Минимальные требования на конец лета 2026 года: 1 vCPU, 1 ГБ RAM (комфортнее — 2 ГБ, если планируете несколько сайтов и не хотите упираться в своп), 10 ГБ диска с запасом под рост базы. Подойдёт любой Ubuntu 24.04 или Debian 12 VPS.

Обновите систему и поставьте Docker с плагином Compose:

apt update && apt upgrade -y
curl -fsSL https://get.docker.com | sh
apt install -y docker-compose-plugin
systemctl enable --now docker

Проверьте версии:

docker --version
docker compose version

Если раньше не приходилось разворачивать сервисы через Docker Compose в продакшене, стоит заглянуть в настройку Docker Compose для продакшена на VPS — там разобраны базовые практики вроде restart-политик и разделения окружений, которые пригодятся и здесь.

Создайте рабочую директорию и файл с переменными окружения — секрет для подписи сессий понадобится на следующем шаге:

mkdir -p /opt/umami && cd /opt/umami
openssl rand -hex 32

Сохраните вывод команды — это будет значение APP_SECRET.

Docker Compose: Umami + PostgreSQL

Официальный образ Umami по умолчанию рассчитан на PostgreSQL, и это разумный выбор для продакшена — миграции стабильнее, чем на MySQL-варианте образа. Создайте docker-compose.yml:

services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    container_name: umami
    environment:
      DATABASE_URL: postgresql://umami:сложный-пароль-сюда@db:5432/umami
      DATABASE_TYPE: postgresql
      APP_SECRET: вставьте-сюда-вывод-openssl-rand
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "127.0.0.1:3000:3000"
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "wget --no-verbose --tries=1 --spider http://localhost:3000/api/heartbeat || exit 1"]
      interval: 5s
      timeout: 5s
      retries: 5

  db:
    image: postgres:16-alpine
    container_name: umami-db
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: сложный-пароль-сюда
    volumes:
      - umami-db-data:/var/lib/postgresql/data
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U umami"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  umami-db-data:

Обратите внимание на ports: 127.0.0.1:3000:3000 — приложение слушает только localhost, наружу его отдаст Nginx с SSL. Пароль в DATABASE_URL и POSTGRES_PASSWORD должен совпадать, укажите один и тот же сложный пароль в обоих местах. Если хочется вынести секреты из docker-compose.yml в отдельный файл, гляньте управление паролями через Docker Secrets — для одного сервиса это не обязательно, но привычка полезная.

Поднимите стек:

docker compose up -d
docker compose logs -f umami

Дождитесь строки о готовности сервера и Ctrl+C, чтобы выйти из логов. Схема базы данных создаётся автоматически при первом старте — миграции запускать вручную не нужно.

Nginx как reverse proxy и SSL

Ставим Nginx и certbot, если их ещё нет:

apt install -y nginx certbot python3-certbot-nginx

Конфиг (/etc/nginx/sites-available/umami):

server {
    listen 80;
    server_name analytics.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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;
    }
}

Активируйте и получите сертификат:

ln -s /etc/nginx/sites-available/umami /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx
certbot --nginx -d analytics.example.com

Certbot сам пропишет редирект на HTTPS и настроит автопродление. Трекинг-скрипт будет встраиваться на сторонние сайты, и часть браузеров блокирует запросы к аналитике без HTTPS как небезопасные смешанные — сертификат тут не опция. Если предпочитаете автоматический SSL без отдельной возни с certbot, есть разбор Caddy с авто-SSL на VPS — для одного домена это часто даже проще, чем связка Nginx плюс certbot. Общая логика reverse proxy для Docker-сервисов разобрана в статье про Nginx как reverse proxy на VPS, если конфиг выше показался непонятным местами.

Не забудьте открыть порты 80 и 443 в файрволе, если он активен:

ufw allow 80/tcp
ufw allow 443/tcp

Про базовую настройку самого файрвола — UFW на VPS.

Первый вход и подключение сайта

Откройте https://analytics.example.com в браузере. Данные по умолчанию для первого входа — логин admin, пароль umami (актуально для текущих версий образа, но всегда сверяйтесь с официальной документацией проекта — дефолты между релизами иногда меняются). Первым делом смените пароль администратора в Settings → Profile → Change password.

Добавьте сайт: Settings → Websites → Add website, укажите имя и домен. После сохранения Umami сгенерирует код трекера — вставьте его перед закрывающим тегом </head> на отслеживаемом сайте:

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

Скрипт весит несколько килобайт и не блокирует рендеринг страницы благодаря атрибуту defer. Данные начнут поступать в дашборд практически сразу — обновите страницу сайта пару раз и проверьте вкладку Realtime в Umami.

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

umami.track('signup-button-click');

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

Бэкапы, обновления и ресурсы

Единственное, что жалко потерять — база PostgreSQL с накопленной статистикой, само приложение перекатывается заново из образа за секунды. Простой дамп по cron:

0 3 * * * docker exec umami-db pg_dump -U umami umami | gzip > /root/backups/umami-$(date +\%F).sql.gz

Держите бэкапы за пределами того же сервера — хотя бы через rsync на другую машину. Если стек Docker уже включает несколько сервисов и хочется бэкапить том целиком, а не только базу, посмотрите на бэкап Docker volume на VPS — подход с docker run --rm -v пригодится и для тома umami-db-data.

Обновление — это замена образа и перезапуск контейнера:

cd /opt/umami
docker compose pull
docker compose up -d

Схема базы при необходимости мигрируется автоматически на старте нового образа — резервную копию перед обновлением всё равно снимите, это минута времени против риска потерять историю на мажорном апдейте. По ресурсам: для сайта с посещаемостью в несколько тысяч визитов в сутки хватает VPS на 1–2 ГБ RAM с запасом; если параллельно поднимаете PostgreSQL под другие задачи или сравниваете варианты хранения аналитики большого объёма, у нас есть разбор ClickHouse или PostgreSQL для аналитики — для масштаба выше «пары сайтов на одном VPS» это стоит прочитать заранее.

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