Slik selvhoster du Uptime Kuma i 2026: varsler, TLS og persistent data

De fleste installasjonsnotater for Uptime Kuma slutter etter den første sidelastingen. Det er for tidlig: datavolumet er skrivebeskyttet, eller container-DNS klarer ikke å slå opp overvåkede verter. En nyttig produksjonstest er mer krevende — opprett HTTP- og TCP-monitorer, fremtving én kontrollert feil, og motta både varselet og meldingen om at tjenesten er tilbake via den valgte leverandøren.

Uptime Kumas rolle er enkel: overvåking av eksisterende tjenester med varsler til mer enn 90 destinasjoner. Den operative avgrensningen omfatter mer enn webprosessen, så avhengigheten, lagret tilstand og den offentlige ruten må beskrives eksplisitt før reelle data kommer inn.

Definer hva som er vellykket for Uptime Kuma først

Et nyttig Uptime Kuma-diagram viser den offentlige ruten, den private porten 3001, tilstandsgrensen og alle støttende krav. Marker hvilke piler som inneholder credentials, og hvilke som er vanlig brukertrafikk. Det eksterne kravet for Uptime Kuma er utgående tilgang til hvert overvåkede endepunkt og hver varselleverandør. Test utgående DNS, TLS og leverandørens oppførsel uten å publisere enda en innkommende tjeneste.

Bevis diagrammet med én reell handling: opprett HTTP- og TCP-monitorer, fremtving én kontrollert feil, og motta både varselet og meldingen om at tjenesten er tilbake via den valgte leverandøren. Den største belastningen kommer sannsynligvis fra monitorintervallet, antall retries, trafikk til statussiden og antallet utgående probes som sendes i samme sekund. Overvåk denne banen i stedet for å behandle alle HTTP-forespørsler likt.

Drift Uptime Kuma med utgangspunkt i den faktiske flaskehalsen

Det første nyttige driftsmålet for Uptime Kuma er om den kan opprette HTTP- og TCP-monitorer, fremtvinge én kontrollert feil og motta både varselet og meldingen om at tjenesten er tilbake via den valgte leverandøren. Kombiner dette med metningssignaler for monitorintervallet, antall retries, trafikk til statussiden og antallet utgående probes som sendes i samme sekund. En prosessbasert probe bør ikke kalle kostbare avhengigheter eller restarte containeren fordi en upstream-tjeneste midlertidig er utilgjengelig.

Behandle oppgraderinger som dataendringer, fordi SQLite-migreringer og endringer hos varselleverandører kan gjøre en rask image-pull til en stateful applikasjonsoppgradering. Lås versjoner, øv på gjenopprettet tilstand, og behold det forrige imaget tilgjengelig frem til rollback fortsatt er mulig. Når datavolumet er skrivebeskyttet, eller container-DNS ikke klarer å slå opp overvåkede verter, må du ta vare på logger fra før omstarten. De inneholder vanligvis den utløsende feilmeldingen.

Dokumenter en kjent god Uptime Kuma-deployment

For Uptime Kuma bør du definere en kjent god transaksjon før lansering: opprett HTTP- og TCP-monitorer, fremtving én kontrollert feil, og motta både varselet og meldingen om at tjenesten er tilbake via den valgte leverandøren. Legg forutsetninger, forventet respons og oppryddingstrinn i versjonskontroll uten secret-verdier. Lås imaget som ble brukt til å etablere referansen.

Bruk transaksjonen til å validere en erstatning og en uavhengig restore. Den gjenopprettede tjenesten er bare godkjent når monitorhistorikk, credentials for varsler og vedlikeholdsvinduer dukker opp igjen, og et testvarsel fortsatt leveres. Observer samtidig monitorintervallet, antall retries, trafikk til statussiden og antallet utgående probes som sendes i samme sekund, og gjør den tregeste eller mest begrensede delen om til et service-level-varsel.

Sjekkpunktet trenger også et negativt tilfelle: blokker midlertidig testbanen som brukes for utgående tilgang til hvert overvåkede endepunkt og hver varselleverandør. Bekreft at Uptime Kuma produserer en handlingsrettet feil samtidig som dataene bevares, gjenopprett den gyldige tilstanden, og gjenta den kjente gode transaksjonen. Når du beholder begge resultatene, unngår du at et overfladisk health-endepunkt blir det eneste produksjonsbeviset.

Containerinnstillinger det er verdt å gjennomgå

Bruk containeren som et utskiftbart runtime-miljø, ikke som stedet der sannheten ligger.

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

Tillat og verifiser den utgående eller klientsidebaserte banen som kreves for utgående tilgang til hvert overvåkede endepunkt og hver varselleverandør. Kontroller containerbrukeren, skrivbare stier og bundet listener før du eksponerer den. Kjør hele handlingen — opprett HTTP- og TCP-monitorer, fremtving én kontrollert feil, og motta både varselet og meldingen om at tjenesten er tilbake via den valgte leverandøren — og lagre den nøyaktige imagereferansen som produserte resultatet.

Gjenopprett Uptime Kuma på en tom vert

Beskytt tilstanden til Uptime Kuma før du optimaliserer containeren. Det nødvendige settet er SQLite-databasen og opplastede ressurser i /app/data. Monter /app/data før bootstrap, skriv ufarlige eksempeldata, og erstatt containeren for å bevise at banen faktisk er persistent. Hvis flere datalagre må være konsistente, dokumenterer du rekkefølgen for når skriving stanses og sikkerhetskopier tas.

Oppbevar kopier utenfor deployment-serveren, og krypter materiale som inneholder credentials eller privat innhold. Gjenopprettingen er vellykket når monitorhistorikk, credentials for varsler og vedlikeholdsvinduer dukker opp igjen, og et testvarsel fortsatt leveres. Forskjellen mellom en persistent mount og en uavhengig kopi er beskrevet i persistent lagring og snapshots.

Gi Uptime Kuma én kanonisk adresse

Publiser én stabil HTTPS-origin gjennom reverse proxyen. Send det valgte hostname-et til containerport 3001, videresend den opprinnelige host-headeren og HTTPS-skjemaet, og unngå å publisere en ekstra direkte origin.

Test Uptime Kuma fra en ekstern klient uten tidligere tilstand. Skill ingress-feil fra den kjente applikasjonsgrensen — datavolumet er skrivebeskyttet, eller container-DNS klarer ikke å slå opp overvåkede verter. En certificate-, DNS- eller 502-feil hører til rutingen. En forespørsel som når Uptime Kuma og feiler senere, hører til applikasjonstilstand, kapasitet eller et støttende krav. Veiledningen for TLS på egendefinert domene dekker den første gruppen.

Sikkerhetsvalg som gjelder spesifikt for Uptime Kuma

Den applikasjonsspesifikke sikkerhetsrisikoen er å kjøre førstegangsoppsettet på en offentlig eksponert instans. Det operative svaret er å fullføre førstegangsoppsettet privat og deretter beskytte dashboards og administrasjon av statussider separat. Fullfør bootstrap via en begrenset rute, og fjern midlertidig oppsettstilgang umiddelbart etterpå.

UPTIME_KUMA_PORT styrer oppførsel, ikke konfidensialitet. Valider typen og verdien, og lagre ekte Uptime Kuma-credentials separat. Gi Uptime Kuma-prosessen bare de dokumenterte mountene og avhengighetsrutene. Unngå tilgang til host root og Docker socket. Logg mislykket autentisering og konfigurasjonsfeil, men rediger bort tokens, connection strings og brukerinnhold.

En Dockup-deployment trenger fortsatt en akseptansetest for Uptime Kuma

Ruting, certificates, utskifting av tjenester og tilknyttet lagring er fornuftige mål for automatisering. Dockup håndterer dette for Uptime Kuma og kan klargjøre den tilhørende managed-databasen eller koble til tjenester på kundens egen server.

Det Dockup ikke bør finne på, er trust-policyen for Uptime Kuma. Etter deployment publiserer du én stabil HTTPS-origin gjennom reverse proxyen, håndhever denne grensen — fullfør førstegangsoppsettet privat og beskytt deretter dashboards og administrasjon av statussider separat — og verifiserer resultatet av dette scenarioet: opprett HTTP- og TCP-monitorer, fremtving én kontrollert feil, og motta både varselet og meldingen om at tjenesten er tilbake via den valgte leverandøren. Resultatet er infrastruktur med ett klikk og en applikasjonsspesifikk akseptansetest.

Ofte stilte spørsmål

Hva trenger Uptime Kuma for en produksjonsdeployment?

Rout Uptime Kuma-containeren på port 3001 gjennom én HTTPS-origin. Det eksterne leveransekravet er utgående tilgang til hvert overvåkede endepunkt og hver varselleverandør. Ikke erklær Uptime Kuma som klar før du kan opprette HTTP- og TCP-monitorer, fremtvinge én kontrollert feil og motta både varselet og meldingen om at tjenesten er tilbake via den valgte leverandøren.

Hvilke Uptime Kuma-data skal inngå i en sikkerhetskopi?

Gjør /app/data persistent, og inkluder SQLite-databasen og opplastede ressurser i /app/data i det samme gjenopprettingsmanifestet. En ren Uptime Kuma-restore er bare vellykket når monitorhistorikk, credentials for varsler og vedlikeholdsvinduer dukker opp igjen, og et testvarsel fortsatt leveres.

Krever Uptime Kuma HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Uptime Kuma-origin-en, og behold port 3001 på den interne ruten. Bruk Uptime Kuma-innstillingen riktig: publiser én stabil HTTPS-origin gjennom reverse proxyen. For Uptime Kuma beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsistent klientsideoppførsel som avhenger av origin.

Hvordan bør en oppgradering av Uptime Kuma testes?

Gjenopprett den nåværende Uptime Kuma-tilstanden i en isolert deployment, bruk kandidatversjonen, og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at SQLite-migreringer og endringer hos varselleverandører kan gjøre en rask image-pull til en stateful applikasjonsoppgradering. Behold det forrige Uptime Kuma-imaget til grensen for datamigrering og rollback er forstått.