Sådan selvhoster du Uptime Kuma i 2026: alarmer, TLS og persistent data

De fleste installationsnoter til Uptime Kuma stopper efter den første sideindlæsning. Det er for tidligt: Data-volumenen er skrivebeskyttet, eller container-DNS kan ikke resolve de hosts, der overvåges. En nyttig produktionstest er mere krævende — opret HTTP- og TCP-monitors, fremprovokér én kontrolleret fejl, og modtag alarmen og recovery-notifikationen via den valgte provider.

Uptime Kumas rolle er enkel: overvågning af eksisterende services med alarmer til mere end 90 destinationer. Den operationelle afgrænsning omfatter mere end webprocessen, så dependency, gemt state og public route skal navngives eksplicit, før der kommer rigtige data ind.

Definér først, hvornår Uptime Kuma fungerer

Et nyttigt Uptime Kuma-diagram viser den offentlige route, den private port 3001, state-grænsen og alle understøttende krav. Markér, hvilke pile der transporterer credentials, og hvilke der er almindelig brugertrafik. Det eksterne krav til Uptime Kuma er outbound access til alle endpoints og alert-providers, der overvåges. Test outbound DNS, TLS og provider-adfærd uden at publicere endnu en inbound service.

Bevis diagrammet med én rigtig handling: Opret HTTP- og TCP-monitors, fremprovokér én kontrolleret fejl, og modtag alarmen og recovery-notifikationen via den valgte provider. Det forventede pres kommer sandsynligvis fra monitor interval, retry count, status page-trafik og antallet af outbound probes, der udføres i samme sekund; overvåg denne path i stedet for at behandle alle HTTP-requests ens.

Drift af Uptime Kuma omkring den reelle flaskehals

Den første nyttige operationelle metrik for Uptime Kuma er, om systemet kan oprette HTTP- og TCP-monitors, fremprovokere én kontrolleret fejl og modtage alarmen og recovery-notifikationen via den valgte provider. Kombinér den med saturation-signaler for monitor interval, retry count, status page-trafik og antallet af outbound probes, der udføres i samme sekund. En process-only probe bør ikke kalde dyre dependencies eller genstarte containeren, fordi en upstream er midlertidigt utilgængelig.

Behandl upgrades som dataændringer, fordi SQLite-migrations og ændringer i notification-providers kan gøre et hurtigt image pull til en stateful application upgrade. Pin versioner, øv dig på restored state, og behold det tidligere image tilgængeligt, indtil en rollback fortsat er gyldig. Når data-volumenen er skrivebeskyttet, eller container-DNS ikke kan resolve de hosts, der overvåges, skal du gemme logs fra før genstarten; de indeholder normalt den kausale fejlmeddelelse.

Dokumentér en kendt velfungerende Uptime Kuma-deployment

For Uptime Kuma skal du definere en kendt velfungerende transaktion før launch: Opret HTTP- og TCP-monitors, fremprovokér én kontrolleret fejl, og modtag alarmen og recovery-notifikationen via den valgte provider. Placér dens prerequisites, forventede respons og cleanup-trin i version control uden secret-værdier. Pin det image, der bruges til at etablere denne reference.

Brug transaktionen til at validere en replacement og en uafhængig restore. Den restored service er kun acceptabel, når monitor history, notification credentials og maintenance windows dukker op igen, og en testalarm stadig bliver leveret. Observér samtidig monitor interval, retry count, status page-trafik og antallet af outbound probes, der udføres i samme sekund, og gør den langsomste eller mest begrænsede del til en service-level alert.

Gaten skal også indeholde et negativt testtilfælde: Afvis midlertidigt den test-path, der bruges til outbound access til alle endpoints og alert-providers, der overvåges. Bekræft, at Uptime Kuma genererer en handlingsrettet fejl, samtidig med at data bevares, genskab den gyldige tilstand, og gentag den kendt velfungerende transaktion. Ved at gemme begge resultater undgår du, at et overfladisk health endpoint bliver det eneste produktionsbevis.

Containerindstillinger, der er værd at gennemgå

Brug containeren som en udskiftelig runtime, ikke som stedet, hvor sandheden 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

Tillad og verificér den outbound- eller client-side path, der kræves for outbound access til alle endpoints og alert-providers, der overvåges. Kontrollér container-brugeren, writable paths og den bundne listener, før du eksponerer den. Kør hele handlingen — opret HTTP- og TCP-monitors, fremprovokér én kontrolleret fejl, og modtag alarmen og recovery-notifikationen via den valgte provider — og gem den præcise image reference, der gav resultatet.

Gendan Uptime Kuma på en tom host

Beskyt Uptime Kumas state, før du optimerer containeren. Det nødvendige sæt er SQLite-databasen og uploadede assets i /app/data. Mount /app/data før bootstrap, skriv ufarlige sample data, og udskift containeren for at bevise, at pathen faktisk er persistent. Hvis flere stores skal være konsistente, skal du dokumentere rækkefølgen, som writes pauses og backups tages i.

Opbevar kopier uden for deployment-serveren, og encrypt materiale, der indeholder credentials eller privat indhold. Recovery lykkes, når monitor history, notification credentials og maintenance windows dukker op igen, og en testalarm stadig bliver leveret. Forskellen mellem et persistent mount og en uafhængig kopi er beskrevet i persistent storage and snapshots.

Giv Uptime Kuma én canonical address

Publicér én stabil HTTPS-origin gennem reverse proxyen. Send det valgte hostname til container port 3001, forward den oprindelige host og HTTPS scheme, og undgå at publicere endnu en direkte origin.

Test Uptime Kuma fra en ren ekstern client. Adskil ingress-fejl fra den kendte application boundary — data-volumenen er skrivebeskyttet, eller container-DNS kan ikke resolve de hosts, der overvåges. En certificate-, DNS- eller 502-fejl hører til routing; en request, der når Uptime Kuma og fejler senere, hører til application state, capacity eller en understøttende requirement. Guiden til TLS med custom domain dækker den første gruppe.

Sikkerhedsbeslutninger, der er specifikke for Uptime Kuma

Den applikationsspecifikke sikkerhedsrisiko er at køre first-user setup på en offentligt eksponeret instance. Det operationelle svar er at gennemføre first-user setup privat og derefter beskytte dashboards og status page-administration separat. Gennemfør bootstrap via en restricted route, og fjern straks den midlertidige setup-adgang bagefter.

UPTIME_KUMA_PORT styrer adfærd, ikke confidentiality; validér dens type og værdi, og opbevar ægte Uptime Kuma-credentials separat. Giv Uptime Kuma-processen kun dens dokumenterede mounts og dependency-routes; undgå adgang til host root og Docker socket. Log fejlslagen authentication og configuration errors, men redigér tokens, connection strings og brugerindhold.

En Dockup-deployment kræver stadig en acceptance test for Uptime Kuma

Routing, certificates, service replacement og attached storage er fornuftige automatiseringsmål. Dockup håndterer dem for Uptime Kuma og kan provisionere den tilknyttede managed database eller oprette forbindelse til services på kundens egen server.

Det, den ikke bør opfinde, er Uptime Kumas trust policy. Efter deployment skal du publicere én stabil HTTPS-origin gennem reverse proxyen, håndhæve denne grænse — gennemfør first-user setup privat, og beskyt derefter dashboards og status page-administration separat — og verificere resultatet af dette scenarie: Opret HTTP- og TCP-monitors, fremprovokér én kontrolleret fejl, og modtag alarmen og recovery-notifikationen via den valgte provider. Resultatet er one-click infrastructure med en applikationsspecifik acceptance test.

Ofte stillede spørgsmål

Hvad skal Uptime Kuma bruge til en produktionsdeployment?

Route Uptime Kuma-containeren på port 3001 gennem én HTTPS-origin. Det eksterne leveringskrav er outbound access til alle endpoints og alert-providers, der overvåges. Kald ikke Uptime Kuma klar, før du kan oprette HTTP- og TCP-monitors, fremprovokere én kontrolleret fejl og modtage alarmen og recovery-notifikationen via den valgte provider.

Hvilke Uptime Kuma-data hører hjemme i en backup?

Gør /app/data persistent, og inkludér SQLite-databasen og uploadede assets i /app/data i det samme recovery-manifest. En ren Uptime Kuma-restore er kun godkendt, når monitor history, notification credentials og maintenance windows dukker op igen, og en testalarm stadig bliver leveret.

Kræver Uptime Kuma HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Uptime Kuma-origin, og behold port 3001 på den interne route. Anvend Uptime Kuma-indstillingen korrekt: Publicér én stabil HTTPS-origin gennem reverse proxyen. For Uptime Kuma beskytter HTTPS credentials eller brugerindhold under transport og sikrer en ensartet client-adfærd, der er følsom over for origin.

Hvordan bør en Uptime Kuma-upgrade testes?

Gendan den aktuelle Uptime Kuma-state i en isoleret deployment, anvend candidate-versionen, og gentag dens acceptance transaction. Vær særligt opmærksom, fordi SQLite-migrations og ændringer i notification-providers kan gøre et hurtigt image pull til en stateful application upgrade. Behold det tidligere Uptime Kuma-image, indtil dets data-migration og rollback boundary er forstået.