Jak v roce 2026 provozovat vlastní Uptime Kuma: alerty, TLS a trvalá data

Většina návodů k instalaci Uptime Kuma končí u prvního načtení stránky. To je příliš brzy: datový volume může být pouze pro čtení nebo container DNS nemusí umět přeložit monitorované hosty. Užitečný produkční test je náročnější — vytvořte HTTP a TCP monitory, vynuceně vyvolejte jedno kontrolované selhání a přes zvoleného providera přijměte alert i oznámení o obnovení.

Úloha Uptime Kuma je jednoduchá: monitoring existujících služeb s alerty do více než 90 destinací. Jeho provozní hranice zahrnuje víc než samotný webový proces, proto je nutné před příchodem skutečných dat explicitně pojmenovat závislosti, uložený stav i veřejnou route.

Nejprve definujte, co znamená úspěch u Uptime Kuma

Užitečný diagram Uptime Kuma zobrazuje veřejnou route, privátní port 3001, hranici stavu a všechny podpůrné požadavky. Označte, které šipky přenášejí credentials a které představují běžný uživatelský provoz. Externím požadavkem Uptime Kuma je odchozí přístup ke každému monitorovanému endpointu a providerovi alertů. Otestujte odchozí DNS, TLS a chování providera, aniž byste publikovali další příchozí službu.

Diagram ověřte jednou skutečnou akcí: vytvořte HTTP a TCP monitory, vynuceně vyvolejte jedno kontrolované selhání a přes zvoleného providera přijměte alert i oznámení o obnovení. Pravděpodobnou zátěž představuje interval monitoringu, počet opakování, provoz status page a počet odchozích probe provedených ve stejné sekundě; monitorujte tuto cestu, místo abyste všechny HTTP requesty považovali za rovnocenné.

Provozujte Uptime Kuma s ohledem na jeho skutečné úzké hrdlo

První užitečná provozní metrika Uptime Kuma ukazuje, zda dokáže vytvořit HTTP a TCP monitory, vynuceně vyvolat jedno kontrolované selhání a přes zvoleného providera přijmout alert i oznámení o obnovení. Doplňte ji signály saturace pro interval monitoringu, počet opakování, provoz status page a počet odchozích probe provedených ve stejné sekundě. Probe samotného procesu by neměl volat nákladné závislosti ani restartovat container kvůli krátkodobé nedostupnosti upstreamu.

S upgrady zacházejte jako se změnami dat, protože migrace SQLite a změny providerů notifikací mohou z rychlého stažení image udělat upgrade stavové aplikace. Pinujte verze, nacvičte postup na obnoveném stavu a ponechte předchozí image k dispozici, dokud zůstává platný rollback. Když je datový volume pouze pro čtení nebo container DNS nedokáže přeložit monitorované hosty, uchovejte logy z doby před restartem; obvykle obsahují zprávu s příčinou.

Zaznamenejte známou funkční instalaci Uptime Kuma

Pro Uptime Kuma definujte před spuštěním známou funkční transakci: vytvořte HTTP a TCP monitory, vynuceně vyvolejte jedno kontrolované selhání a přes zvoleného providera přijměte alert i oznámení o obnovení. Její předpoklady, očekávanou odpověď a kroky úklidu uložte do version control bez hodnot secrets. Image použitou k vytvoření této reference pinujte.

Transakci použijte k ověření náhradní instance a nezávislého restore. Obnovená služba je akceptovatelná pouze tehdy, když se znovu objeví historie monitorů, credentials pro notifikace a maintenance windows a testovací alert se stále doručí. Současně sledujte interval monitoringu, počet opakování, provoz status page a počet odchozích probe provedených ve stejné sekundě a nejpomalejší nebo nejvíce omezenou část převeďte na service-level alert.

Gate potřebuje také negativní scénář: dočasně zakažte testovací cestu využívanou pro odchozí přístup ke každému monitorovanému endpointu a providerovi alertů. Ověřte, že Uptime Kuma vytvoří použitelnou chybovou zprávu a přitom zachová data, obnovte platný stav a zopakujte známou funkční transakci. Uchování obou výsledků zabrání tomu, aby se jediným produkčním důkazem stal povrchní health endpoint.

Nastavení containeru, která stojí za kontrolu

Používejte container jako nahraditelný runtime, nikoli jako místo, kde se nachází zdroj pravdy.

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

Povolte a ověřte odchozí nebo client-side cestu potřebnou pro odchozí přístup ke každému monitorovanému endpointu a providerovi alertů. Před vystavením služby zkontrolujte uživatele containeru, zapisovatelné cesty a bindovaný listener. Proveďte celou akci — vytvořte HTTP a TCP monitory, vynuceně vyvolejte jedno kontrolované selhání a přes zvoleného providera přijměte alert i oznámení o obnovení — a uložte přesnou referenci image, která výsledek vytvořila.

Obnovte Uptime Kuma na prázdném hostu

Před optimalizací containeru chraňte stav Uptime Kuma. Požadovanou sadou jsou SQLite databáze a nahrané assety v /app/data. Připojte /app/data před bootstrapem, zapište neškodná ukázková data a nahraďte container, abyste prokázali, že je tato cesta skutečně persistentní. Pokud musí být konzistentních více úložišť, zdokumentujte pořadí, v němž se pozastavují zápisy a pořizují zálohy.

Kopie uchovávejte mimo deployment server a materiál obsahující credentials nebo privátní obsah šifrujte. Obnova je úspěšná, když se znovu objeví historie monitorů, credentials pro notifikace a maintenance windows a testovací alert se stále doručí. Rozdíl mezi persistentním mountem a nezávislou kopií popisuje persistentní úložiště a snapshoty.

Dejte Uptime Kuma jednu kanonickou adresu

Publikujte jednu stabilní HTTPS origin přes reverse proxy. Zvolený hostname směrujte na port containeru 3001, předávejte původní host a HTTPS scheme a vyhněte se publikování druhé přímé origin.

Otestujte Uptime Kuma z čistého externího clientu. Oddělte selhání ingressu od známé aplikační hranice — datový volume je pouze pro čtení nebo container DNS nedokáže přeložit monitorované hosty. Chyba certifikátu, DNS nebo 502 patří do routingu; request, který dorazí do Uptime Kuma a selže až později, patří do stavu aplikace, kapacity nebo jejích podpůrných požadavků. Průvodce TLS pro vlastní doménu pokrývá první skupinu.

Bezpečnostní rozhodnutí specifická pro Uptime Kuma

Bezpečnostní riziko specifické pro aplikaci spočívá v provedení setupu prvního uživatele na veřejně dostupné instanci. Provozní řešení je dokončit setup prvního uživatele neveřejně a následně samostatně chránit dashboardy a správu status page. Bootstrap dokončete přes omezenou route a dočasný přístup k setupu ihned poté odeberte.

UPTIME_KUMA_PORT ovlivňuje chování, nikoli důvěrnost; ověřte jeho typ a hodnotu a skutečné credentials Uptime Kuma ukládejte odděleně. Procesu Uptime Kuma poskytněte pouze zdokumentované mounty a routes k závislostem; vyhněte se přístupu k rootu hostitele a Docker socketu. Logujte neúspěšná přihlášení a konfigurační chyby, ale redigujte tokeny, connection stringy a obsah uživatelů.

Deployment v Dockup stále potřebuje akceptační test Uptime Kuma

Routing, certifikáty, nahrazování služeb a připojené úložiště jsou rozumné cíle pro automatizaci. Dockup je pro Uptime Kuma řeší a může zajistit související managed databázi nebo se připojit ke službám na vlastním serveru zákazníka.

Neměl by však vymýšlet trust policy Uptime Kuma. Po deploymentu publikujte jednu stabilní HTTPS origin přes reverse proxy, vynucujte tuto hranici — dokončete setup prvního uživatele neveřejně a následně samostatně chraňte dashboardy a správu status page — a ověřte výsledek tohoto scénáře: vytvořte HTTP a TCP monitory, vynuceně vyvolejte jedno kontrolované selhání a přes zvoleného providera přijměte alert i oznámení o obnovení. Výsledkem je infrastruktura na jedno kliknutí s aplikačně specifickým akceptačním testem.

Často kladené otázky

Co Uptime Kuma potřebuje pro produkční deployment?

Veďte container Uptime Kuma na portu 3001 přes jednu HTTPS origin. Externím požadavkem pro doručování je odchozí přístup ke každému monitorovanému endpointu a providerovi alertů. Uptime Kuma nepovažujte za připravené, dokud nedokážete vytvořit HTTP a TCP monitory, vynuceně vyvolat jedno kontrolované selhání a přes zvoleného providera přijmout alert i oznámení o obnovení.

Která data Uptime Kuma patří do zálohy?

Zachovejte /app/data a zahrňte SQLite databázi i nahrané assety v /app/data do stejného recovery manifestu. Čistá obnova Uptime Kuma je úspěšná pouze tehdy, když se znovu objeví historie monitorů, credentials pro notifikace a maintenance windows a testovací alert se stále doručí.

Vyžaduje Uptime Kuma za reverse proxy HTTPS?

Pro veřejnou origin Uptime Kuma používejte HTTPS a port 3001 ponechte na interní route. Nastavení Uptime Kuma aplikujte správně: publikujte jednu stabilní HTTPS origin přes reverse proxy. Uptime Kuma používá HTTPS k ochraně credentials nebo obsahu uživatelů během přenosu a k zachování konzistentního chování clientu závislého na origin.

Jak testovat upgrade Uptime Kuma?

Obnovte aktuální stav Uptime Kuma do izolovaného deploymentu, aplikujte kandidátní verzi a zopakujte akceptační transakci. Věnujte tomu zvláštní pozornost, protože migrace SQLite a změny providerů notifikací mohou z rychlého stažení image udělat upgrade stavové aplikace. Předchozí image Uptime Kuma ponechte k dispozici, dokud nebudete rozumět hranici migrace dat a rollbacku.