Jak hostować Uptime Kuma samodzielnie w 2026 roku: alerty, TLS i trwałe dane

Większość instrukcji instalacji Uptime Kuma kończy się na pierwszym załadowaniu strony. To zbyt wcześnie: wolumen danych może być tylko do odczytu albo DNS kontenera może nie rozwiązywać nazw monitorowanych hostów. Przydatny test produkcyjny jest bardziej wymagający — utwórz monitory HTTP i TCP, wymuś jedną kontrolowaną awarię oraz odbierz alert i powiadomienie o przywróceniu działania za pośrednictwem wybranego providera.

Rola Uptime Kuma jest prosta: monitoring istniejących usług z alertami wysyłanymi do ponad 90 miejsc docelowych. Jej granice operacyjne obejmują więcej niż sam proces webowy, dlatego przed pojawieniem się rzeczywistych danych trzeba jawnie określić zależność, przechowywany stan i publiczną trasę.

Najpierw zdefiniuj kryteria sukcesu dla Uptime Kuma

Przydatny diagram Uptime Kuma pokazuje publiczną trasę, prywatny port 3001, granicę stanu oraz każde wymaganie pomocnicze. Zaznacz, które strzałki przenoszą dane uwierzytelniające, a które zwykły ruch użytkowników. Zewnętrznym wymaganiem Uptime Kuma jest dostęp wychodzący do każdego monitorowanego endpointu i providera alertów. Przetestuj wychodzący DNS, TLS i działanie providera bez publikowania kolejnej usługi przychodzącej.

Potwierdź diagram jednym rzeczywistym działaniem: utwórz monitory HTTP i TCP, wymuś jedną kontrolowaną awarię oraz odbierz alert i powiadomienie o przywróceniu działania za pośrednictwem wybranego providera. Największe obciążenie prawdopodobnie wynika z interwału monitorowania, liczby ponowień, ruchu strony statusu i liczby sond wychodzących wykonywanych w tej samej sekundzie; monitoruj tę ścieżkę, zamiast traktować wszystkie żądania HTTP jednakowo.

Obsługuj Uptime Kuma, uwzględniając jego rzeczywiste wąskie gardło

Pierwszym przydatnym wskaźnikiem operacyjnym dla Uptime Kuma jest to, czy można za jego pomocą utworzyć monitory HTTP i TCP, wymusić jedną kontrolowaną awarię oraz odebrać alert i powiadomienie o przywróceniu działania za pośrednictwem wybranego providera. Połącz go z sygnałami nasycenia dotyczącymi interwału monitorowania, liczby ponowień, ruchu strony statusu i liczby sond wychodzących wykonywanych w tej samej sekundzie. Sonda sprawdzająca wyłącznie proces nie powinna wywoływać kosztownych zależności ani restartować kontenera tylko dlatego, że upstream jest chwilowo niedostępny.

Traktuj aktualizacje jako zmiany danych, ponieważ migracje SQLite i zmiany providerów powiadomień mogą zamienić szybkie pobranie obrazu w aktualizację aplikacji stanowej. Przypinaj wersje, ćwicz procedurę na odtworzonym stanie i zachowaj poprzedni obraz, dopóki rollback pozostaje możliwy. Gdy wolumen danych jest tylko do odczytu albo DNS kontenera nie może rozwiązać nazw monitorowanych hostów, zachowaj logi z okresu przed restartem; zwykle zawierają komunikat wskazujący przyczynę.

Zapisz sprawdzoną konfigurację Uptime Kuma

W przypadku Uptime Kuma zdefiniuj sprawdzoną transakcję przed uruchomieniem: utwórz monitory HTTP i TCP, wymuś jedną kontrolowaną awarię oraz odbierz alert i powiadomienie o przywróceniu działania za pośrednictwem wybranego providera. Umieść jej wymagania wstępne, oczekiwaną odpowiedź i kroki czyszczenia w systemie kontroli wersji, bez wartości sekretów. Przypnij obraz użyty do ustanowienia tego punktu odniesienia.

Użyj tej transakcji do zweryfikowania zamiennika i niezależnego odtworzenia. Odtworzona usługa jest akceptowalna tylko wtedy, gdy ponownie pojawią się historia monitorów, dane uwierzytelniające providerów powiadomień i okna konserwacyjne, a testowy alert nadal będzie dostarczany. Jednocześnie obserwuj interwał monitorowania, liczbę ponowień, ruch strony statusu i liczbę sond wychodzących wykonywanych w tej samej sekundzie, a następnie przekształć najwolniejszą lub najbardziej ograniczoną część w alert na poziomie usługi.

Bramka kontrolna musi obejmować również przypadek negatywny: tymczasowo zablokuj ścieżkę testową używaną przez dostęp wychodzący do każdego monitorowanego endpointu i providera alertów. Potwierdź, że Uptime Kuma generuje możliwy do wykorzystania błąd, zachowując dane, przywróć poprawny stan i ponownie wykonaj sprawdzoną transakcję. Zachowanie obu wyników zapobiega sytuacji, w której powierzchowny endpoint health staje się jedynym dowodem działania na produkcji.

Ustawienia kontenera, które warto sprawdzić

Traktuj kontener jako wymienne środowisko uruchomieniowe, a nie jako miejsce przechowywania źródłowych danych.

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

Zezwól na wymaganą ścieżkę wychodzącą lub po stronie klienta i zweryfikuj ją dla dostępu wychodzącego do każdego monitorowanego endpointu i providera alertów. Przed udostępnieniem usługi sprawdź użytkownika kontenera, ścieżki z prawem zapisu i nasłuchujący listener. Wykonaj pełne działanie — utwórz monitory HTTP i TCP, wymuś jedną kontrolowaną awarię oraz odbierz alert i powiadomienie o przywróceniu działania za pośrednictwem wybranego providera — i zapisz dokładne odwołanie do obrazu, który dał ten rezultat.

Odtwórz Uptime Kuma na pustym hoście

Zabezpiecz stan Uptime Kuma, zanim zaczniesz optymalizować jego kontener. Wymagany zestaw obejmuje bazę SQLite i przesłane zasoby w /app/data. Zamontuj /app/data przed bootstrapem, zapisz nieszkodliwe przykładowe dane i zastąp kontener, aby potwierdzić, że ta ścieżka rzeczywiście jest trwała. Jeśli wiele magazynów musi zachować spójność, opisz kolejność wstrzymywania zapisów i wykonywania backupów.

Przechowuj kopie poza serwerem wdrożeniowym i szyfruj materiały zawierające dane uwierzytelniające lub prywatną treść. Odzyskiwanie kończy się powodzeniem, gdy ponownie pojawią się historia monitorów, dane uwierzytelniające providerów powiadomień i okna konserwacyjne, a testowy alert nadal będzie dostarczany. Różnicę między trwałym mountem a niezależną kopią opisano w artykule o persistent storage i snapshotach.

Nadaj Uptime Kuma jeden kanoniczny adres

Udostępnij jeden stabilny origin HTTPS przez reverse proxy. Skieruj wybraną nazwę hosta na port kontenera 3001, przekazuj oryginalny host i schemat HTTPS oraz unikaj publikowania drugiego, bezpośredniego originu.

Przetestuj Uptime Kuma z czystego, zewnętrznego klienta. Oddziel awarię ingressu od znanej granicy aplikacji — wolumen danych jest tylko do odczytu albo DNS kontenera nie może rozwiązać nazw monitorowanych hostów. Błąd certyfikatu, DNS lub 502 należy do routingu; żądanie, które dociera do Uptime Kuma i kończy się błędem później, dotyczy stanu aplikacji, wydajności lub jej wymagania pomocniczego. Przewodnik po TLS dla własnej domeny obejmuje pierwszą grupę.

Decyzje dotyczące bezpieczeństwa właściwe dla Uptime Kuma

Ryzykiem bezpieczeństwa specyficznym dla aplikacji jest przeprowadzanie konfiguracji pierwszego użytkownika na publicznie dostępnej instancji. Rozwiązaniem operacyjnym jest zakończenie konfiguracji pierwszego użytkownika prywatnie, a następnie oddzielna ochrona dashboardów i administracji stroną statusu. Wykonaj bootstrap przez ograniczoną trasę, a zaraz potem natychmiast usuń tymczasowy dostęp konfiguracyjny.

UPTIME_KUMA_PORT steruje działaniem, a nie poufnością; zweryfikuj jego typ i wartość, a rzeczywiste dane uwierzytelniające Uptime Kuma przechowuj oddzielnie. Przyznaj procesowi Uptime Kuma wyłącznie udokumentowane mounty i trasy do zależności; unikaj dostępu do roota hosta i socketu Dockera. Rejestruj nieudane uwierzytelnianie i błędy konfiguracji, ale usuwaj z logów tokeny, connection stringi i treści użytkowników.

Wdrożenie w Dockup nadal wymaga testu akceptacyjnego Uptime Kuma

Routing, certyfikaty, wymiana usług i dołączony storage to rozsądne cele automatyzacji. Dockup obsługuje je dla Uptime Kuma i może utworzyć powiązaną zarządzaną bazę danych albo połączyć się z usługami na własnym serwerze klienta.

Nie powinien jednak samodzielnie wymyślać polityki zaufania Uptime Kuma. Po wdrożeniu udostępnij jeden stabilny origin HTTPS przez reverse proxy, wymuś tę granicę — zakończ konfigurację pierwszego użytkownika prywatnie, a następnie oddzielnie chroń dashboardy i administrację stroną statusu — oraz zweryfikuj wynik następującego scenariusza: utwórz monitory HTTP i TCP, wymuś jedną kontrolowaną awarię oraz odbierz alert i powiadomienie o przywróceniu działania za pośrednictwem wybranego providera. Rezultatem jest infrastruktura wdrażana jednym kliknięciem, obejmująca test akceptacyjny specyficzny dla aplikacji.

Najczęściej zadawane pytania

Czego Uptime Kuma potrzebuje do wdrożenia produkcyjnego?

Skieruj kontener Uptime Kuma działający na porcie 3001 przez jeden origin HTTPS. Zewnętrznym wymaganiem dostarczania jest dostęp wychodzący do każdego monitorowanego endpointu i providera alertów. Nie uznawaj Uptime Kuma za gotowe, dopóki nie utworzysz monitorów HTTP i TCP, nie wymusisz jednej kontrolowanej awarii oraz nie odbierzesz alertu i powiadomienia o przywróceniu działania za pośrednictwem wybranego providera.

Które dane Uptime Kuma powinny znaleźć się w backupie?

Utrwal /app/data i uwzględnij bazę SQLite oraz przesłane zasoby w /app/data w tym samym manifeście odtwarzania. Czyste odtworzenie Uptime Kuma kończy się powodzeniem tylko wtedy, gdy ponownie pojawią się historia monitorów, dane uwierzytelniające providerów powiadomień i okna konserwacyjne, a testowy alert nadal będzie dostarczany.

Czy Uptime Kuma wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego originu Uptime Kuma, a port 3001 pozostaw na trasie wewnętrznej. Zastosuj poprawnie ustawienie Uptime Kuma: udostępnij jeden stabilny origin HTTPS przez reverse proxy. W przypadku Uptime Kuma HTTPS chroni dane uwierzytelniające lub treści użytkowników podczas transmisji i zapewnia spójne działanie klienta zależne od originu.

Jak testować aktualizację Uptime Kuma?

Odtwórz bieżący stan Uptime Kuma w odizolowanym wdrożeniu, zastosuj wersję kandydującą i ponownie wykonaj jego transakcję akceptacyjną. Zwróć szczególną uwagę na ten proces, ponieważ migracje SQLite i zmiany providerów powiadomień mogą zamienić szybkie pobranie obrazu w aktualizację aplikacji stanowej. Zachowaj poprzedni obraz Uptime Kuma, dopóki granice migracji danych i rollbacku nie będą zrozumiałe.