Umami на Ubuntu 24.04: пошаговая установка

MAATRIX

Google Analytics всё чаще упирается в блокировщики рекламы, требования GDPR и вопросы «а куда вообще уходят данные о моих посетителях». Umami — открытая система веб-аналитики, которая работает без cookie, не требует баннера согласия в большинстве юрисдикций и хранит всю статистику на вашем собственном сервере. Ставится она буквально в один Docker-контейнер, а по функциональности закрывает 90% того, что обычно нужно от аналитики: просмотры страниц, источники трафика, устройства, географию и пользовательские события.

Что такое Umami и зачем он нужен

Umami написан на Next.js, хранит данные в PostgreSQL (или MySQL) и отдаёт лёгкий JS-сниппет (около 2 КБ) для встраивания на сайт. В отличие от Matomo, у Umami нет тяжёлой PHP-инсталляции с десятками таблиц и модулей — это минималистичный инструмент, заточенный именно на аналитику посещений, без heatmap, сессионных записей и A/B-тестов из коробки.

Ключевые отличия от Google Analytics и других self-hosted решений:

• Не использует cookie для идентификации посетителей — снимает вопрос с баннером согласия в большинстве стран ЕС (уточняйте у юриста для вашего конкретного случая).
• Данные физически лежат на вашем сервере, а не утекают в чужую экосистему рекламных сетей.
• Один Docker-контейнер + PostgreSQL — разворачивается за считанные минуты, не требует отдельного сервера под аналитику.
• Поддерживает несколько сайтов из одной панели, роли пользователей, публичные дашборды по ссылке.

Если вам нужна более глубокая аналитика с воронками и записью сессий — присмотритесь к Matomo, но для 90% блогов, лендингов и SaaS-проектов Umami закрывает задачу проще и легче.

Требования к серверу

Umami — лёгкий сервис, ему не нужны мощные ресурсы. Ориентируйтесь на такие минимумы:

Для сайта с трафиком до нескольких десятков тысяч визитов в месяц хватит младшего VPS на 1-2 vCPU и 2 ГБ RAM — этого места достаточно и под саму Umami, и под PostgreSQL, и под небольшой запас на будущее. Если проектов много и трафик растёт, разумно сразу закладывать 4 ГБ RAM, чтобы PostgreSQL не начал упираться в диск при агрегации отчётов за длинные периоды.

Устанавливаем Docker и docker compose

Если Docker на сервере ещё не стоит, ставим его официальным скриптом:

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
newgrp docker

Проверяем, что всё встало и плагин compose доступен:

docker --version
docker compose version

Если сервер уже настроен под другие контейнерные сервисы, смотрите общий разбор частых граблей в статье про docker compose для продакшена на Ubuntu 24.04 — там же про сети, volume и рестарт-политики, которые пригодятся и здесь.

Готовим docker-compose.yml

Создаём рабочую директорию и файл конфигурации:

sudo mkdir -p /opt/umami
cd /opt/umami
sudo nano docker-compose.yml

Содержимое файла — официальный образ Umami с PostgreSQL в связке:

services:
  umami:
    image: docker.umami.is/umami-software/umami:postgresql-latest
    container_name: umami
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      DATABASE_URL: postgresql://umami:${DB_PASSWORD}@db:5432/umami
      DATABASE_TYPE: postgresql
      APP_SECRET: ${APP_SECRET}
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "curl -sf http://localhost:3000/api/heartbeat || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3

  db:
    image: postgres:16-alpine
    container_name: umami-db
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: ${DB_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:

Обратите внимание: порт 3000 привязан только к 127.0.0.1 — снаружи Umami будет доступен через Nginx с SSL, напрямую в интернет контейнер не смотрит. Это стандартная практика для любого self-hosted сервиса за реверс-прокси.

Рядом создаём .env с секретами:

sudo nano .env

DB_PASSWORD=замените-на-длинный-случайный-пароль
APP_SECRET=замените-на-случайную-строку-32-символа

Сгенерировать оба значения можно одной командой:

openssl rand -hex 32

Запустите её дважды и подставьте результаты в .env — не оставляйте пароли по умолчанию, это первое, что проверяют автоматические сканеры при поиске открытых Umami-инсталляций.

Запускаем контейнеры

cd /opt/umami
docker compose up -d

Первый запуск PostgreSQL применит миграции автоматически — это может занять 10-20 секунд. Проверяем статус:

docker compose ps
docker compose logs -f umami

Дожидаемся в логах строки о том, что сервер слушает на порту 3000, и проверяем локально:

curl -I http://127.0.0.1:3000

Ответ 200 OK означает, что приложение поднялось и готово принимать запросы через реверс-прокси.

Настраиваем Nginx и SSL

Ставим Nginx, если его ещё нет:

sudo apt update
sudo apt install -y nginx

Создаём конфиг сайта:

sudo nano /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;
    }
}

Активируем и перезагружаем Nginx:

sudo ln -s /etc/nginx/sites-available/umami /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Выпускаем сертификат Let's Encrypt через certbot:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d analytics.example.com

Certbot сам допишет блок с SSL и редиректом на HTTPS. Если хотите разобраться в разнице между certbot и acme.sh или планируете автоматизировать выпуск сертификатов для нескольких доменов, загляните в статью certbot или acme.sh — что выбрать для сервера. Общую логику работы реверс-прокси для контейнерных сервисов разбирали в статье про Nginx как реверс-прокси на Ubuntu 24.04.

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

Открываем https://analytics.example.com в браузере. Umami попросит войти под данными по умолчанию:

• Логин: admin
• Пароль: umami

Сразу после первого входа зайдите в Settings → Users и смените пароль администратора — оставлять дефолтные учётные данные на сервере, смотрящем в интернет, нельзя даже на несколько минут.

Дальше добавляем сайт: Settings → Websites → Add website. Указываете домен, Umami генерирует уникальный website-id и готовый JS-сниппет вида:

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

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

Резервное копирование и обновление

Все данные Umami живут в PostgreSQL, поэтому бэкап сводится к дампу базы:

docker exec umami-db pg_dump -U umami umami > umami-backup-$(date +%F).sql

Разумно повесить эту команду в cron и хранить бэкапы вне сервера — на объектном хранилище или на отдельной машине. Если нужна более системная схема бэкапов с ретеншеном и шифрованием, посмотрите на BorgBackup — он неплохо ложится поверх такого дампа как второй слой защиты.

Обновление до новой версии — стандартный для Docker Compose процесс:

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

Перед крупными обновлениями (смена мажорной версии) стоит свериться с changelog проекта на GitHub — иногда меняется схема базы, и тогда миграция может занять больше времени на первом запуске после апдейта.

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