Пошаговая инструкция · Самостоятельная установка
Как установить Uptime Kuma на сервер
Пошаговая инструкция для самостоятельной установки. Настроим Uptime Kuma на отдельном VPS: от каталога данных и защищённой панели до учебного отказа с настоящим уведомлением. Каждое действие отделено и заканчивается проверкой.
Что подготовить #
Uptime Kuma проверяет доступность сервисов и сообщает об отказах. Разместите её на отдельном VPS: если мониторинг выключится вместе с наблюдаемым сайтом, сигнал не уйдёт. Для первых HTTP-проверок начните с 1–2 vCPU, 2 ГБ RAM и локального SSD от 20 ГБ; частые проверки и браузерные сценарии потребуют больше.
Подготовьте Ubuntu 26.04 LTS, Docker Engine с Compose, Nginx и Certbot по общей инструкции. Nginx на хосте занимает 80/443, Kuma слушает локальный 3001. Один экземпляр использует SQLite на локальном диске: data не подключайте одновременно к другой Kuma.
Создайте A-запись своего домена на IP VPS; везде замените monitor.example.com этим доменом и admin@example.com своей почтой. Порт 3001 опубликован только на 127.0.0.1 и недоступен снаружи. До создания администратора ограничьте HTTPS своим внешним IP в firewall провайдера, сохранив TCP 80 для сертификата. Команды выполняйте в SSH-терминале сервера; при ошибке сначала исправьте текущий шаг.
Шаг 1. Откройте административную сессию #
Этот вариант хранит файлы в /opt и выполняется от root. Команда попросит пароль sudo; при вводе он не отображается.
sudo -iПриглашение терминала изменилось на root. Следующие серверные команды выполняйте в этой сессии.
Шаг 2. Создайте каталог данных #
В data будут учётные записи, настройки и история. Файлы сохраняются при замене контейнера.
install -d -m 0750 /opt/uptime-kuma
cd /opt/uptime-kuma
install -d -m 0750 dataВы находитесь в /opt/uptime-kuma. После нового SSH-подключения снова используйте sudo -i и cd /opt/uptime-kuma.
Шаг 3. Сохраните описание запуска #
Откройте nano compose.yaml и сохраните файл ниже. Приложение слушает только 127.0.0.1:3001; его HTTPS обслуживает Nginx на хосте. Постоянный каталог data хранит настройки и историю; не размещайте его на NFS.
/opt/uptime-kuma/compose.yamlname: uptime-kuma
services:
kuma:
image: louislam/uptime-kuma:2.5.5
restart: unless-stopped
ports:
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/dataФайл сохранён; внешний HTTP-порт контейнера не опубликован на всех интерфейсах.
Шаг 4. Проверьте Compose #
Прежде чем скачать образы, проверим YAML.
docker compose config --quietКоманда ничего не вывела. При ошибке исправьте отступы или указанную строку и повторите.
Шаг 5. Скачайте образы #
Docker загрузит закреплённый образ Kuma 2.5.5.
docker compose pullОбраз скачан без ошибки сети или тега.
Шаг 6. Запустите панель #
Запуск в фоне не зависит от открытого SSH-окна.
docker compose up -dКонтейнер kuma создан. Приложение пока доступно на локальном порту, HTTPS настроим следующими шагами.
Шаг 7. Сохраните сайт Nginx #
Установите Nginx и Certbot по подготовке Ubuntu, если ещё не установили. Откройте sudo nano /etc/nginx/sites-available/uptime-kuma и вставьте файл ниже. Замените все домены своими. Nginx передаёт приложению домен, адрес клиента и протокол; Upgrade и Connection сохраняют WebSocket. До получения сертификата условие $scheme блокирует обычные HTTP-запросы кодом 403, чтобы вход не происходил без шифрования. Буферизация отключена, WebSocket сохраняется: панель получает события мониторинга без разрыва соединения.
/etc/nginx/sites-available/uptime-kumamap $http_upgrade $uptime_kuma_connection_upgrade {
default upgrade;
"" close;
}
server {
listen 80;
server_name monitor.example.com;
client_max_body_size 100m;
location / {
if ($scheme = http) { return 403; }
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-Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $uptime_kuma_connection_upgrade;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
proxy_buffering off;
}
}
Сохраните Ctrl+O, Enter, Ctrl+X. В файле пока нет путей к сертификатам: Nginx сможет проверить его до выпуска HTTPS.
Шаг 8. Подключите сайт и проверьте HTTP #
Ссылка подключает сохранённый сайт. nginx -t проверяет все настройки сервера; && разрешает перечитать их только при успешной проверке. curl проверяет ответ для вашего домена. При ошибке остановитесь, исправьте указанную строку и повторите проверку.
sudo ln -sfn /etc/nginx/sites-available/uptime-kuma /etc/nginx/sites-enabled/uptime-kuma
sudo nginx -t && sudo systemctl reload nginx
curl -I http://monitor.example.com/Ожидается successful от nginx -t и HTTP 403 для обычного запроса: до HTTPS это намеренная блокировка. DNS должен указывать на сервер, TCP 80/443 — быть доступен у провайдера. Ничего не вводите в форму входа по HTTP.
Шаг 9. Получите сертификат и включите HTTPS #
Каждое имя из команды должно указывать на этот сервер. Certbot проверит домены, сам добавит сертификат в сайт Nginx и включит перенаправление HTTP → HTTPS. Укажите свою почту при запросе и подтвердите условия Let’s Encrypt. Это отдельное действие после успешной проверки HTTP.
sudo /snap/bin/certbot --nginx -d monitor.example.com --redirectCertbot сообщил об успешной установке. Откройте HTTPS-адрес со своего компьютера: браузер не должен предупреждать о сертификате. Для закрытой панели используйте разрешённый IP. При ошибке исправьте DNS, в том числе AAAA, либо доступ к TCP 80; не повторяйте запросы выпуска подряд.
Шаг 10. Проверьте продление сертификата #
Certbot из snap создаёт службу автоматического продления. Dry-run выполняет пробное продление: настоящие сертификаты не заменяются. Затем проверьте, что таймер планирует следующий запуск. Сохраняйте доступ к TCP 80 для следующих проверок домена.
sudo /snap/bin/certbot renew --dry-run
systemctl list-timers --all 'snap.certbot.renew*'Пробное продление успешно, у таймера есть следующий запуск. Если тест не прошёл, проверьте /var/log/letsencrypt/letsencrypt.log; сначала исправьте причину. После этого можно создавать учётную запись и приглашать пользователей.
Шаг 11. Проверьте адрес в браузере #
Откройте https://monitor.example.com со своего компьютера. Установку администратора проходите только с разрешённого IP.
Есть корректный сертификат и форма создания пользователя. При ошибке проверьте DNS, docker compose logs --tail=100 kuma и /var/log/nginx/error.log.
Шаг 12. Создайте администратора #
Задайте отдельное имя и длинный пароль, войдите в панель. В настройках включите двухфакторную аутентификацию и сохраните коды восстановления.
Открылась панель без мониторов. После создания пользователя временное ограничение HTTPS можно расширить для нужных сотрудников.
Шаг 13. Укажите доверенный прокси #
В Settings → Reverse Proxy включите Trust Proxy: в этой схеме все запросы приходят через ваш Nginx. Настройка помогает учитывать адрес клиента.
Панель сохранила настройку и не теряет соединение. Порт 3001 слушает только 127.0.0.1; заголовки клиента задаёт Nginx.
Шаг 14. Создайте первую проверку сайта #
Добавьте HTTP(s)-монитор для известного тестового сайта. Укажите полный HTTPS-адрес, понятное имя и интервал 60 секунд. Ожидаемый код задайте по смыслу: для обычной открытой страницы это 200. localhost внутри контейнера означает саму Kuma, поэтому другой сервис должен иметь достижимый сетевой адрес.
После одного-двух циклов монитор показывает UP. Если браузер открывает сайт, а Kuma — нет, проверяйте доступ со стороны VPS, DNS и IPv6.
Шаг 15. Подключите канал уведомлений #
В настройках монитора создайте один канал: SMTP, Telegram или другой доступный вариант. Заполните реквизиты своего сервиса, выполните Test и назначьте канал этому монитору.
Тестовое сообщение получил нужный человек. Успешный Test ещё не означает, что монитор отправит аварийный сигнал: проверим это дальше.
Шаг 16. Проверьте настоящий сигнал отказа #
Используйте только учебный монитор. Временно замените его URL заведомо отсутствующим путём тестового сайта, который возвращает 404. Не выключайте рабочий сайт.
Монитор стал DOWN, пришло сообщение с понятным именем сервиса. Если сообщения нет, проверьте назначение канала и повторы монитора.
Шаг 17. Проверьте восстановление #
Верните учебному монитору правильный URL. Дождитесь следующего цикла.
Состояние вернулось в UP и пришло уведомление восстановления. Теперь проверен полный путь: проверка, определение отказа, доставка и восстановление.
Шаг 18. Подготовьте место для копии #
В root-сессии сервера создайте каталог с датой. Следующие шаги выполняйте в той же сессии: BACKUP_DIR хранит путь копии.
cd /opt/uptime-kuma
BACKUP_DIR="/var/backups/uptime-kuma/$(date -u +%Y%m%dT%H%M%SZ)"
install -d -m 0700 "$BACKUP_DIR"Каталог создан. Сохранение будет с короткой остановкой мониторинга: в это время проверки не выполняются.
Шаг 19. Остановите Kuma перед копированием #
SQLite нельзя считать согласованно сохранённой, если скопировать один файл во время записи. Остановим Kuma, оставив Nginx работающим.
docker compose stop kumaКонтейнер kuma остановлен. Панель временно недоступна; переходите к архивированию.
Шаг 20. Сохраните постоянные файлы #
Для версии 2 поддерживаемый способ — копия всего data. Отдельный архив сохраняет Nginx и сертификаты с закрытыми ключами. Оба архива нужны для восстановления этой схемы.
tar -czf "$BACKUP_DIR/uptime-kuma.tar.gz" compose.yaml data
tar -czf "$BACKUP_DIR/nginx-tls.tar.gz" /etc/nginx/sites-available/uptime-kuma /etc/letsencrypt
chmod 600 "$BACKUP_DIR"/*.tar.gztar завершился без ошибок. Архив содержит секреты уведомлений; перенесите защищённую копию вне VPS после возврата сервиса.
Шаг 21. Верните мониторинг #
Запустим Kuma после копии.
docker compose start kumaПанель, история и монитор UP сохранились. Повторите Test канала. При ошибке архива всё равно верните сервис, а копирование повторите после выяснения причины.
Как проверить восстановление #
На отдельной машине распакуйте копию в новый пустой каталог и используйте тот же образ 2.5.5. До запуска ограничьте исходящие соединения: восстановленные мониторы и уведомления могут начать работать сразу. Для проверки откройте панель через SSH-туннель и отключите рабочие уведомления. Проверьте пользователя, историю, список мониторов и одну безопасную проверку. Старый JSON-экспорт версии 1 не заменяет копию data в версии 2.
Если шаг не работает и как обновлять #
В /opt/uptime-kuma проверьте docker compose ps и docker compose logs --tail=100 kuma; для Nginx — sudo tail -n 80 /var/log/nginx/error.log. Если заняты 80/443, найдите существующий прокси и подключите Kuma к нему; второй прокси на тех же портах не запустится. Потеря соединения панели требует проверки WebSocket и внешних прокси. DOWN при исправном сайте может быть связан с DNS, маршрутом или IPv6 именно VPS.
Перед обновлением испытайте копию и новый точный тег. Меняйте образ Kuma, выполните docker compose pull kuma и docker compose up -d kuma; миграциям дайте завершиться. После старта повторите вход, проверку отказа и доставки. Для отката после миграции нужна data прежней версии. Публичную статусную страницу создавайте отдельно и проверяйте, что в ней нет закрытых адресов.
При восстановлении верните файл Nginx и сертификаты, подключите сайт в sites-enabled, затем проверьте sudo nginx -t и перечитайте службу. На тестовом сервере с другим доменом получите отдельный сертификат; не открывайте рабочие данные и уведомления посторонним.