Как разместить Uptime Kuma на собственном сервере в 2026 году: оповещения, TLS и постоянное хранение данных

Большинство инструкций по установке Uptime Kuma заканчиваются на первом открытии страницы. Это слишком рано: том с данными может оказаться доступным только для чтения, а DNS контейнера — не разрешать имена отслеживаемых хостов. Полноценная проверка в production требует большего: создайте HTTP- и TCP-мониторы, намеренно вызовите контролируемый сбой и получите уведомления о сбое и восстановлении через выбранного провайдера.

Роль Uptime Kuma проста: мониторинг существующих сервисов с отправкой оповещений более чем в 90 направлений. Его эксплуатационная граница включает не только веб-процесс, поэтому до появления реальных данных необходимо явно определить зависимость, сохраняемое состояние и публичный маршрут.

Сначала определите критерии успешной работы Uptime Kuma

Полезная схема Uptime Kuma показывает публичный маршрут, приватный порт 3001, границу состояния и все необходимые компоненты. Отметьте, какие стрелки передают учётные данные, а какие обозначают обычный пользовательский трафик. Внешнее требование для Uptime Kuma — исходящий доступ к каждому отслеживаемому endpoint и провайдеру оповещений. Проверьте исходящие DNS, TLS и поведение провайдера, не публикуя ещё один входящий сервис.

Подтвердите схему реальным действием: создайте HTTP- и TCP-мониторы, намеренно вызовите контролируемый сбой и получите уведомления о сбое и восстановлении через выбранного провайдера. Вероятнее всего, нагрузка будет зависеть от интервала мониторинга, количества повторных попыток, трафика status page и числа исходящих проверок, выполняемых в одну и ту же секунду; отслеживайте именно этот путь, а не относитесь ко всем HTTP-запросам одинаково.

Эксплуатируйте Uptime Kuma с учётом его реального узкого места

Первый полезный эксплуатационный показатель для Uptime Kuma — возможность создавать HTTP- и TCP-мониторы, намеренно вызывать контролируемый сбой и получать уведомления о сбое и восстановлении через выбранного провайдера. Дополните его сигналами насыщения: интервалом мониторинга, количеством повторных попыток, трафиком status page и числом исходящих проверок, выполняемых в одну и ту же секунду. Проверка только процесса не должна обращаться к ресурсоёмким зависимостям или перезапускать контейнер из-за кратковременной недоступности upstream.

Считайте обновления изменениями данных, поскольку миграции SQLite и изменения в провайдерах уведомлений могут превратить быструю загрузку image в обновление stateful-приложения. Фиксируйте версии, отрабатывайте процедуру на восстановленном состоянии и сохраняйте предыдущий image, пока откат остаётся возможным. Если том с данными доступен только для чтения или DNS контейнера не может разрешить имена отслеживаемых хостов, сохраните логи до перезапуска: обычно именно в них содержится сообщение, объясняющее причину.

Зафиксируйте эталонное развёртывание Uptime Kuma

Для Uptime Kuma определите эталонную транзакцию до запуска: создайте HTTP- и TCP-мониторы, намеренно вызовите контролируемый сбой и получите уведомления о сбое и восстановлении через выбранного провайдера. Зафиксируйте её предусловия, ожидаемый результат и шаги очистки в системе контроля версий, не добавляя секреты. Зафиксируйте image, использованный для создания этого эталона.

Используйте транзакцию для проверки замены и независимого восстановления. Восстановленный сервис можно считать работоспособным только после того, как история мониторов, учётные данные для уведомлений и окна обслуживания снова появятся, а тестовое оповещение будет доставлено. Одновременно отслеживайте интервал мониторинга, количество повторных попыток, трафик status page и число исходящих проверок, выполняемых в одну и ту же секунду, а самый медленный или наиболее ограниченный участок превратите в оповещение уровня сервиса.

В проверку также должен входить отрицательный сценарий: временно запретите тестовый маршрут, используемый для исходящего доступа к каждому отслеживаемому endpoint и провайдеру оповещений. Убедитесь, что Uptime Kuma выдаёт понятную для действий ошибку, сохраняя данные, восстановите корректное состояние и повторите эталонную транзакцию. Сохранение обоих результатов не позволит поверхностной health endpoint стать единственным подтверждением работоспособности в production.

Параметры контейнера, которые стоит проверить

Используйте контейнер как заменяемую среду выполнения, а не как место хранения истины.

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 127.0.0.1:3001:3001 \
  -v uptime-kuma-data:/app/data \
  -e UPTIME_KUMA_PORT=3001 \
  louislam/uptime-kuma:1

Разрешите и проверьте исходящий или клиентский маршрут, необходимый для исходящего доступа к каждому отслеживаемому endpoint и провайдеру оповещений. Перед публикацией проверьте пользователя контейнера, доступные для записи пути и привязанный listener. Выполните полный сценарий — создайте HTTP- и TCP-мониторы, намеренно вызовите контролируемый сбой и получите уведомления о сбое и восстановлении через выбранного провайдера — и сохраните точную ссылку на image, с которым был получен результат.

Восстановите Uptime Kuma на пустом хосте

Защитите состояние Uptime Kuma до оптимизации контейнера. В обязательный набор входят база данных SQLite и загруженные assets в /app/data. Подключите /app/data до bootstrap, запишите безвредные тестовые данные и замените контейнер, чтобы убедиться, что этот путь действительно сохраняется. Если несколько хранилищ должны оставаться согласованными, задокументируйте порядок приостановки записи и создания резервных копий.

Храните копии за пределами сервера развёртывания и шифруйте материалы, содержащие учётные данные или приватный контент. Восстановление считается успешным, когда история мониторов, учётные данные для уведомлений и окна обслуживания снова появляются, а тестовое оповещение доставляется. Разница между постоянным mount и независимой копией описана в руководстве по постоянному хранению и snapshots.

Назначьте для Uptime Kuma один канонический адрес

Опубликуйте один стабильный HTTPS origin через reverse proxy. Направьте выбранное hostname на порт контейнера 3001, передавайте исходные host и HTTPS scheme и не публикуйте второй прямой origin.

Проверьте Uptime Kuma с чистого внешнего клиента. Отделяйте сбой ingress от известной границы приложения — том с данными доступен только для чтения или DNS контейнера не может разрешить имена отслеживаемых хостов. Ошибки сертификата, DNS или 502 относятся к маршрутизации; запрос, который достигает Uptime Kuma и завершается ошибкой позже, относится к состоянию приложения, его capacity или поддерживающей зависимости. В руководстве по TLS для custom domain рассматривается первая группа.

Решения по безопасности, специфичные для Uptime Kuma

Специфический для приложения риск безопасности — выполнение настройки первого пользователя на публично доступном instance. Практическое решение — завершить настройку первого пользователя в приватном режиме, а затем отдельно защитить dashboards и администрирование status page. Выполните bootstrap через ограниченный маршрут и сразу после этого удалите временный доступ к настройке.

UPTIME_KUMA_PORT управляет поведением, а не конфиденциальностью; проверьте его тип и значение, а настоящие учётные данные Uptime Kuma храните отдельно. Предоставьте процессу Uptime Kuma только задокументированные mount и маршруты к зависимостям; избегайте доступа к root хоста и Docker socket. Ведите журнал неудачной аутентификации и ошибок конфигурации, но удаляйте из него tokens, connection strings и пользовательский контент.

Для развёртывания в Dockup всё равно нужен acceptance test для Uptime Kuma

Маршрутизация, сертификаты, замена сервисов и подключённое хранилище — разумные цели для автоматизации. Dockup выполняет эти задачи для Uptime Kuma и может подготовить связанную managed database или подключиться к сервисам на собственном сервере заказчика.

Но политика доверия Uptime Kuma не должна выдумываться автоматически. После развёртывания опубликуйте один стабильный HTTPS origin через reverse proxy, установите эту границу — завершите настройку первого пользователя в приватном режиме, а затем отдельно защитите dashboards и администрирование status page — и проверьте результат следующего сценария: создайте HTTP- и TCP-мониторы, намеренно вызовите контролируемый сбой и получите уведомления о сбое и восстановлении через выбранного провайдера. В результате вы получаете инфраструктуру в один клик с acceptance test, специфичным для приложения.

Часто задаваемые вопросы

Что нужно Uptime Kuma для развёртывания в production?

Направьте контейнер Uptime Kuma через порт 3001 к одному HTTPS origin. Внешнее требование для доставки — исходящий доступ к каждому отслеживаемому endpoint и провайдеру оповещений. Не объявляйте Uptime Kuma готовым, пока не сможете создать HTTP- и TCP-мониторы, намеренно вызвать контролируемый сбой и получить уведомления о сбое и восстановлении через выбранного провайдера.

Какие данные Uptime Kuma нужно включать в резервную копию?

Сохраняйте /app/data и включайте базу данных SQLite и загруженные assets в /app/data в один и тот же recovery manifest. Чистое восстановление Uptime Kuma считается успешным только после того, как история мониторов, учётные данные для уведомлений и окна обслуживания снова появятся, а тестовое оповещение будет доставлено.

Требуется ли Uptime Kuma HTTPS за reverse proxy?

Используйте HTTPS для публичного origin Uptime Kuma, а порт 3001 оставьте во внутреннем маршруте. Корректно настройте Uptime Kuma: опубликуйте один стабильный HTTPS origin через reverse proxy. Для Uptime Kuma HTTPS защищает учётные данные или пользовательский контент при передаче и обеспечивает согласованное поведение клиента, зависящее от origin.

Как тестировать обновление Uptime Kuma?

Восстановите текущее состояние Uptime Kuma в изолированном развёртывании, примените candidate version и повторите acceptance transaction. Уделите этому особое внимание, поскольку миграции SQLite и изменения в провайдерах уведомлений могут превратить быструю загрузку image в обновление stateful-приложения. Сохраняйте предыдущий image Uptime Kuma, пока не будут понятны границы миграции данных и отката.