Як розгорнути Uptime Kuma на власному сервері у 2026 році: сповіщення, TLS і постійні дані

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

Призначення Uptime Kuma просте: моніторинг наявних сервісів із надсиланням сповіщень у понад 90 напрямків. Його операційна межа охоплює більше, ніж вебпроцес, тому до надходження реальних даних потрібно явно визначити залежності, збережений стан і публічний маршрут.

Спочатку визначте критерії успішної роботи Uptime Kuma

Корисна схема Uptime Kuma показує публічний маршрут, приватний порт 3001, межу стану та всі супутні вимоги. Позначте, які стрілки передають облікові дані, а які використовуються для звичайного користувацького трафіку. Зовнішня вимога для Uptime Kuma — вихідний доступ до кожної кінцевої точки та провайдера сповіщень, які ви моніторите. Перевірте вихідні DNS, TLS і поведінку провайдера, не публікуючи ще один вхідний сервіс.

Підтвердьте схему реальною дією: створіть HTTP- і TCP-монітори, навмисно спричиніть контрольований збій і отримайте сповіщення про нього та про відновлення через вибраного провайдера. Найімовірніше навантаження створюють інтервал моніторингу, кількість повторних спроб, трафік сторінки статусу та кількість вихідних перевірок, виконаних в одну й ту саму секунду; моніторте цей шлях, а не ставтеся до всіх HTTP-запитів однаково.

Експлуатуйте Uptime Kuma з урахуванням його реального вузького місця

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

Сприймайте оновлення як зміни даних, оскільки міграції SQLite та зміни провайдера сповіщень можуть перетворити швидке завантаження image на оновлення stateful-застосунку. Фіксуйте версії, відпрацьовуйте оновлення на відновленому стані та зберігайте попередній image, доки rollback залишається можливим. Якщо том даних доступний лише для читання або DNS контейнера не може знайти хости, які потрібно моніторити, збережіть логи до перезапуску; зазвичай у них міститься повідомлення про причину.

Зафіксуйте еталонне працездатне розгортання Uptime Kuma

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

Використовуйте цю транзакцію для перевірки заміни та незалежного відновлення. Відновлений сервіс можна вважати прийнятним лише тоді, коли повернулися історія моніторів, облікові дані сповіщень і вікна технічного обслуговування, а тестове сповіщення все ще доставляється. Одночасно спостерігайте за інтервалом моніторингу, кількістю повторних спроб, трафіком сторінки статусу та кількістю вихідних перевірок, виконаних в одну й ту саму секунду, і перетворіть найповільнішу або найбільш обмежену частину на service-level alert.

Перевірка також має містити негативний сценарій: тимчасово забороніть тестовий шлях, який використовується для вихідного доступу до кожної кінцевої точки та провайдера сповіщень. Переконайтеся, що Uptime Kuma створює зрозумілу помилку, зберігаючи дані, відновіть коректний стан і повторіть еталонну успішну транзакцію. Збереження обох результатів не дасть поверхневій health endpoint стати єдиним production-доказом.

Налаштування контейнера, які варто перевірити

Використовуйте контейнер як замінний runtime, а не як місце зберігання істини.

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

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

Відновіть Uptime Kuma на чистому хості

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

Зберігайте копії поза сервером розгортання та шифруйте матеріали, що містять облікові дані або приватний контент. Відновлення успішне, коли повернулися історія моніторів, облікові дані сповіщень і вікна технічного обслуговування, а тестове сповіщення все ще доставляється. Відмінність між постійним монтуванням і незалежною копією описано в постійному сховищі та snapshots.

Визначте для Uptime Kuma одну канонічну адресу

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

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

Рішення з безпеки, специфічні для Uptime Kuma

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

UPTIME_KUMA_PORT керує поведінкою, а не конфіденційністю; перевіряйте його тип і значення, а справжні облікові дані Uptime Kuma зберігайте окремо. Надайте процесу Uptime Kuma лише задокументовані mounts і маршрути до залежностей; уникайте доступу до root хоста та Docker socket. Записуйте невдалі спроби автентифікації й помилки конфігурації, але маскуйте tokens, connection strings і користувацький контент.

Розгортання Dockup усе одно потребує acceptance test для Uptime Kuma

Маршрутизація, сертифікати, заміна сервісів і підключене сховище — цілком доречні цілі для автоматизації. Dockup опрацьовує їх для Uptime Kuma і може підготувати пов’язану керовану базу даних або підключитися до сервісів на власному сервері клієнта.

Чого не слід вигадувати — це policy довіри Uptime Kuma. Після розгортання опублікуйте один стабільний HTTPS origin через reverse proxy, дотримуйтеся цієї межі — заверште налаштування першого користувача приватно, а потім окремо захистіть dashboards і адміністрування status page — та перевірте результат цього сценарію: створіть HTTP- і TCP-монітори, навмисно спричиніть контрольований збій і отримайте сповіщення про нього та про відновлення через вибраного провайдера. Результат — інфраструктура в один клік із acceptance test, специфічним для застосунку.

Поширені запитання

Що потрібно Uptime Kuma для production-розгортання?

Маршрутизуйте контейнер Uptime Kuma через порт 3001 до одного HTTPS origin. Зовнішня вимога для доставки — вихідний доступ до кожної кінцевої точки та провайдера сповіщень, які ви моніторите. Не вважайте 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, доки не буде зрозумілою межа міграції даних і rollback.