Uptime Kuma — небольшая панель для проверок HTTP, TCP, DNS, сертификатов и других сервисов. Она удобна для домашнего сервера и небольшого проекта, но панель управления не стоит публиковать обычным портом на весь интернет.
Соберём схему, в которой Uptime Kuma слушает только localhost, а внешний HTTPS принимает Nginx. Используем актуальную ветку 2 официального образа.
compose.yaml
services:
uptime-kuma:
image: louislam/uptime-kuma:2
restart: unless-stopped
ports:
- "127.0.0.1:3001:3001"
volumes:
- uptime_kuma_data:/app/data
volumes:
uptime_kuma_data:
В файле нет version: "3": современный Docker Compose читает актуальную Compose Specification без этого устаревшего поля.
Именованный volume сохраняет базу, настройки и уведомления при пересоздании контейнера. Проект Uptime Kuma отдельно предупреждает, что каталогу /app/data нужны POSIX file locks. Не размещайте его на NFS без проверки совместимости: проблемы с блокировками SQLite могут привести к ошибкам и повреждению данных.
Порт опубликован как 127.0.0.1:3001, а не просто 3001:3001. Поэтому к панели может подключиться reverse proxy на том же сервере, но сам порт не доступен извне.
Запуск и первый вход
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 uptime-kuma
До настройки reverse proxy откройте панель через SSH-туннель:
ssh -L 3001:127.0.0.1:3001 user@server.example.ru
После подключения перейдите на локальном компьютере по адресу http://127.0.0.1:3001. Создайте администратора с уникальным длинным паролем. Не используйте пароль от SSH, форума или почты.
Nginx с HTTPS и WebSocket
Uptime Kuma использует WebSocket, поэтому обычного proxy_pass недостаточно. Для отдельного домена, например status.example.ru, минимальный location выглядит так:
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name status.example.ru;
ssl_certificate /etc/letsencrypt/live/status.example.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.example.ru/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3001;
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;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
Проверьте конфигурацию до перезагрузки:
sudo nginx -t
sudo systemctl reload nginx
Uptime Kuma не поддерживает обычную установку в подкаталог вида example.ru/uptime/. Выделите домен или поддомен. Для публичного доступа используйте HTTPS; сертификат можно выпускать и продлевать Certbot или другим ACME-клиентом.
Если панель доступна только через доверенный reverse proxy, в Uptime Kuma откройте Settings → Reverse Proxy → HTTP Headers и включите доверие к proxy-заголовкам. Не включайте этот режим, если к порту 3001 можно подключиться напрямую из недоверенной сети: клиент сможет подделать X-Forwarded-*.
Какие проверки добавить первыми
Не создавайте сразу десятки одинаковых мониторов. Начните с маршрута, который действительно подтверждает работу сервиса:
- HTTPS главной страницы с проверкой сертификата;
- отдельный
/health или /healthz, если приложение его предоставляет;
- DNS-запись важного домена;
- TCP-порт почтового или VPN-сервиса, если протокол нельзя проверить глубже;
- срок действия TLS-сертификата;
- heartbeat для резервного копирования или cron-задачи.
Для сайта лучше проверять не только код ответа 200, но и ключевое слово в содержимом. Тогда пустая заглушка reverse proxy не будет считаться здоровым приложением.
Интервал в 20 секунд не делает мониторинг автоматически лучше. Для обычного сайта часто достаточно 60 секунд. Слишком частые проверки создают лишние запросы и шумят при коротких сетевых колебаниях.
Разместите хотя бы одну внешнюю проверку вне того же сервера. Uptime Kuma на домашнем мини-ПК не сообщит о пропавшем интернете или полном отключении питания этого ПК. Внешний бесплатный монитор или второй узел закрывает эту слепую зону.
Уведомления без потока ложных тревог
Подключите один канал и отправьте тестовое сообщение из настроек. Затем задайте число повторов перед тревогой, например 2–3. Это отфильтрует единичный timeout, но не скроет реальный простой надолго.
Проверьте обратный сценарий: остановите тестовый сервис, дождитесь уведомления о падении, запустите его и убедитесь, что пришло сообщение о восстановлении. Настроенный канал без такой проверки — только предположение.
Не вставляйте токены Telegram, SMTP-пароли и webhook URL в compose.yaml, если передаёте их через окружение. В обычной установке Uptime Kuma хранит настройки уведомлений в своём /app/data, поэтому защищайте резервные копии этого volume.
Резервная копия перед обновлением
Остановите сервис, чтобы SQLite и остальные файлы находились в согласованном состоянии:
backup_dir="$PWD/backups/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$backup_dir"
docker compose stop uptime-kuma
kuma_container="$(docker compose ps -aq uptime-kuma)"
docker run --rm \
--volumes-from "$kuma_container:ro" \
--mount "type=bind,src=$backup_dir,dst=/backup" \
alpine:3.22 \
tar -C /app/data -czf /backup/uptime-kuma-data.tar.gz .
docker compose start uptime-kuma
tar -tzf "$backup_dir/uptime-kuma-data.tar.gz" | head
Скопируйте архив за пределы сервера и периодически проверяйте восстановление в отдельный volume.
Обновление контейнера
После резервной копии:
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 uptime-kuma
Команда up -d пересоздаёт контейнер с новым образом, но подключает прежний volume. Не добавляйте down -v: ключ удалит данные проекта.
После обновления откройте панель, проверьте версию, состояние мониторов и отправьте тестовое уведомление. Если обновление меняет формат данных, сначала прочитайте примечания к релизу и не рассчитывайте, что откат одного image автоматически откатит базу.
Официальные источники