Så självhostar du Uptime Kuma 2026: aviseringar, TLS och beständiga data

De flesta installationsanteckningar för Uptime Kuma slutar efter den första sidladdningen. Det är för tidigt: datavolymen är skrivskyddad eller så kan container-DNS inte slå upp övervakade värdar. Ett användbart produktionstest är mer krävande — skapa HTTP- och TCP-monitorer, framkalla ett kontrollerat fel och ta emot aviseringen och återställningsmeddelandet via den valda providern.

Uptime Kumas roll är enkel: övervakning av befintliga tjänster med aviseringar till fler än 90 destinationer. Den operativa avgränsningen omfattar mer än webbprocessen, så beroendet, det lagrade tillståndet och den publika routen måste namnges uttryckligen innan riktiga data börjar flöda.

Definiera först vad som räknas som lyckat för Uptime Kuma

Ett användbart Uptime Kuma-diagram visar den publika routen, den privata porten 3001, tillståndsgränsen och alla stödjande krav. Markera vilka pilar som transporterar autentiseringsuppgifter och vilka som är vanlig användartrafik. Det externa kravet för Uptime Kuma är utgående åtkomst till varje övervakad endpoint och aviseringsprovider. Testa utgående DNS, TLS och providerbeteende utan att publicera ytterligare en inkommande tjänst.

Bevisa diagrammet med en verklig åtgärd: skapa HTTP- och TCP-monitorer, framkalla ett kontrollerat fel och ta emot aviseringen och återställningsmeddelandet via den valda providern. Den troliga belastningen kommer från monitorintervallet, antalet retries, status-sidetrafiken och antalet utgående probes som görs under samma sekund. Övervaka den vägen i stället för att behandla alla HTTP-förfrågningar som likvärdiga.

Drifta Uptime Kuma utifrån dess verkliga flaskhals

Det första användbara driftmåttet för Uptime Kuma är om tjänsten kan skapa HTTP- och TCP-monitorer, framkalla ett kontrollerat fel och ta emot aviseringen och återställningsmeddelandet via den valda providern. Kombinera det med saturation-signaler för monitorintervall, antal retries, status-sidetrafik och antalet utgående probes som görs under samma sekund. En processbaserad probe bör inte anropa kostsamma beroenden eller starta om containern bara för att en upstream-tjänst tillfälligt är otillgänglig.

Behandla uppgraderingar som dataförändringar, eftersom SQLite-migreringar och ändringar av notification providers kan förvandla en snabb image-pull till en stateful application-uppgradering. Pinna versioner, öva på återställt tillstånd och behåll den tidigare imagen tills en rollback fortfarande är möjlig. När datavolymen är skrivskyddad eller container-DNS inte kan slå upp övervakade värdar ska du spara loggarna från tiden före omstarten. De innehåller vanligtvis det meddelande som visar orsaken.

Dokumentera en känd fungerande Uptime Kuma-deployment

För Uptime Kuma ska du definiera en känd fungerande transaktion före lansering: skapa HTTP- och TCP-monitorer, framkalla ett kontrollerat fel och ta emot aviseringen och återställningsmeddelandet via den valda providern. Lägg dess förutsättningar, förväntade svar och steg för cleanup i versionshanteringen utan secret-värden. Pinna imagen som användes för att skapa referensen.

Använd transaktionen för att validera en ersättare och en oberoende restore. Den återställda tjänsten är godkänd först när monitorhistorik, notification credentials och maintenance windows visas igen och en testavisering fortfarande levereras. Observera samtidigt monitorintervall, antal retries, status-sidetrafik och antalet utgående probes som görs under samma sekund, och gör den långsammaste eller mest begränsade delen till en service-level alert.

Gaten behöver också ett negativt testfall: neka tillfälligt den testväg som används för utgående åtkomst till varje övervakad endpoint och aviseringsprovider. Bekräfta att Uptime Kuma ger ett åtgärdbart fel samtidigt som data bevaras, återställ det giltiga tillståndet och upprepa den kända fungerande transaktionen. Om du behåller båda resultaten förhindrar du att en ytlig health endpoint blir den enda produktionsverifieringen.

Containerinställningar som är värda att granska

Använd containern som en utbytbar runtime, inte som platsen där sanningen finns.

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

Tillåt och verifiera den utgående eller klientsidiga väg som krävs för utgående åtkomst till varje övervakad endpoint och aviseringsprovider. Kontrollera containeranvändaren, skrivbara sökvägar och den bundna lyssnaren innan du exponerar tjänsten. Kör hela åtgärden — skapa HTTP- och TCP-monitorer, framkalla ett kontrollerat fel och ta emot aviseringen och återställningsmeddelandet via den valda providern — och spara den exakta image-referensen som gav resultatet.

Återställ Uptime Kuma på en tom värd

Skydda Uptime Kumas tillstånd innan du optimerar containern. Den nödvändiga uppsättningen består av SQLite-databasen och uppladdade assets i /app/data. Montera /app/data före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. Om flera datalager måste vara konsekventa ska du dokumentera i vilken ordning skrivningar pausas och säkerhetskopior tas.

Förvara kopior utanför deployment-servern och kryptera material som innehåller autentiseringsuppgifter eller privat innehåll. Återställningen är lyckad när monitorhistorik, notification credentials och maintenance windows visas igen och en testavisering fortfarande levereras. Skillnaden mellan en beständig mount och en oberoende kopia beskrivs i beständig lagring och snapshots.

Ge Uptime Kuma en enda kanonisk adress

Publicera en stabil HTTPS-origin via reverse proxyn. Skicka det valda hostnamnet till containerport 3001, vidarebefordra det ursprungliga host-värdet och HTTPS-schemat och undvik att publicera en andra direkt origin.

Testa Uptime Kuma från en extern klient utan tidigare sessionstillstånd. Skilj ingressfel från den kända applikationsgränsen — datavolymen är skrivskyddad eller så kan container-DNS inte slå upp övervakade värdar. Ett certifikat-, DNS- eller 502-fel hör till routingen. En request som når Uptime Kuma och misslyckas senare hör till applikationstillstånd, kapacitet eller dess stödjande krav. Guiden för TLS med en custom domain täcker den första gruppen.

Säkerhetsbeslut som är specifika för Uptime Kuma

Den applikationsspecifika säkerhetsrisken är att köra konfigurationen av den första användaren på en publikt exponerad instans. Det operativa svaret är att slutföra konfigurationen av den första användaren privat och därefter skydda dashboards och administrationen av status-sidor separat. Slutför bootstrap via en begränsad route och ta omedelbart bort tillfällig setup-åtkomst efteråt.

UPTIME_KUMA_PORT styr beteendet, inte konfidentialiteten. Validera dess typ och värde och lagra riktiga Uptime Kuma-autentiseringsuppgifter separat. Ge Uptime Kuma-processen endast dess dokumenterade mounts och routes till beroenden. Undvik åtkomst till hostens root och Docker-socket. Logga misslyckad autentisering och konfigurationsfel, men maskera tokens, connection strings och användarinnehåll.

En Dockup-deployment behöver fortfarande ett acceptanstest för Uptime Kuma

Routing, certifikat, service replacement och ansluten lagring är rimliga mål för automation. Dockup hanterar detta för Uptime Kuma och kan provisionera den relaterade managed-databasen eller ansluta till tjänster på kundens egen server.

Det som inte bör uppfinnas är Uptime Kumas trust policy. Efter deployment ska du publicera en stabil HTTPS-origin via reverse proxyn, upprätthålla denna gräns — slutför konfigurationen av den första användaren privat och skydda därefter dashboards och administrationen av status-sidor separat — och verifiera resultatet av följande scenario: skapa HTTP- och TCP-monitorer, framkalla ett kontrollerat fel och ta emot aviseringen och återställningsmeddelandet via den valda providern. Resultatet är infrastruktur med ett klick och ett applikationsspecifikt acceptanstest.

Vanliga frågor

Vad behöver Uptime Kuma för en produktionsdeployment?

Routa Uptime Kuma-containern på port 3001 via en enda HTTPS-origin. Det externa leveranskravet är utgående åtkomst till varje övervakad endpoint och aviseringsprovider. Betrakta inte Uptime Kuma som redo förrän du kan skapa HTTP- och TCP-monitorer, framkalla ett kontrollerat fel och ta emot aviseringen och återställningsmeddelandet via den valda providern.

Vilka Uptime Kuma-data ska ingå i en säkerhetskopia?

Gör /app/data beständig och inkludera SQLite-databasen och uppladdade assets i /app/data i samma återställningsmanifest. En ren Uptime Kuma-restore är godkänd först när monitorhistorik, notification credentials och maintenance windows visas igen och en testavisering fortfarande levereras.

Kräver Uptime Kuma HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Uptime Kuma-originen och behåll port 3001 på den interna routen. Tillämpa Uptime Kuma-inställningen korrekt: publicera en stabil HTTPS-origin via reverse proxyn. För Uptime Kuma skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och håller klientbeteende som är känsligt för origin konsekvent.

Hur bör en Uptime Kuma-uppgradering testas?

Återställ det aktuella Uptime Kuma-tillståndet till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom SQLite-migreringar och ändringar av notification providers kan förvandla en snabb image-pull till en stateful application-uppgradering. Behåll den tidigare Uptime Kuma-imagen tills gränserna för datamigrering och rollback är förstådda.