Uptime Kuma zelf hosten in 2026: alerts, TLS en persistente data

De meeste installatienotities voor Uptime Kuma eindigen zodra de eerste pagina is geladen. Dat is te vroeg: het datavolume is alleen-lezen of container-DNS kan de gemonitorde hosts niet resolven. Een bruikbare productietest is veeleisender: maak HTTP- en TCP-monitors aan, forceer één gecontroleerde storing en ontvang de alert en herstelmelding via de gekozen provider.

De rol van Uptime Kuma is duidelijk: bestaande services monitoren en alerts versturen naar meer dan 90 bestemmingen. De operationele scope omvat meer dan alleen het webproces. Daarom moeten de dependency, opgeslagen state en publieke route expliciet worden benoemd voordat er echte data binnenkomt.

Definieer eerst wat succes betekent voor Uptime Kuma

Een bruikbaar diagram van Uptime Kuma toont de publieke route, de private poort 3001, de state boundary en elke ondersteunende vereiste. Markeer welke pijlen credentials bevatten en welke gewone user traffic vervoeren. De externe vereiste voor Uptime Kuma is outbound access naar elk gemonitord endpoint en elke alertprovider. Test outbound DNS, TLS en het gedrag van de provider zonder een extra inbound service te publiceren.

Bewijs het diagram met één echte actie: maak HTTP- en TCP-monitors aan, forceer één gecontroleerde storing en ontvang de alert en herstelmelding via de gekozen provider. De vermoedelijke druk ontstaat door het monitorinterval, het aantal retries, status-page traffic en het aantal outbound probes dat op dezelfde seconde wordt uitgevoerd; monitor dat pad in plaats van alle HTTP-requests als gelijkwaardig te behandelen.

Beheer Uptime Kuma rond de werkelijke bottleneck

De eerste nuttige operationele metric voor Uptime Kuma is of het HTTP- en TCP-monitors kan aanmaken, één gecontroleerde storing kan forceren en de alert en herstelmelding via de gekozen provider kan ontvangen. Combineer dat met saturation-signalen voor het monitorinterval, het aantal retries, status-page traffic en het aantal outbound probes dat op dezelfde seconde wordt uitgevoerd. Een process-only probe mag geen dure dependencies aanroepen of de container herstarten omdat een upstream kortstondig niet beschikbaar is.

Behandel upgrades als datamutaties, omdat SQLite-migraties en wijzigingen aan notification providers van een snelle image pull een stateful application-upgrade kunnen maken. Pin versies, oefen upgrades op een herstelde state en houd de vorige image beschikbaar zolang een rollback nog geldig is. Wanneer het datavolume alleen-lezen is of container-DNS de gemonitorde hosts niet kan resolven, bewaar dan de logs van vóór de restart; daarin staat meestal de causale melding.

Leg een bekende goede Uptime Kuma-deployment vast

Definieer voor Uptime Kuma vóór de launch een bekende goede transactie: maak HTTP- en TCP-monitors aan, forceer één gecontroleerde storing en ontvang de alert en herstelmelding via de gekozen provider. Leg de prerequisites, verwachte respons en cleanup-stappen zonder secret values vast in version control. Pin de image die is gebruikt om die referentie vast te leggen.

Gebruik de transactie om een vervanging en een onafhankelijke restore te valideren. De herstelde service is alleen acceptabel wanneer de monitorhistorie, notification credentials en maintenance windows terugkeren en een testalert nog steeds wordt afgeleverd. Observeer tegelijkertijd het monitorinterval, het aantal retries, status-page traffic en het aantal outbound probes dat op dezelfde seconde wordt uitgevoerd en maak van het traagste of meest beperkte onderdeel een service-level alert.

De gate heeft ook een negatieve case nodig: blokkeer tijdelijk het testpad dat wordt gebruikt voor outbound access naar elk gemonitord endpoint en elke alertprovider. Controleer of Uptime Kuma een bruikbare foutmelding produceert en de data behoudt, herstel de geldige situatie en herhaal de bekende goede transactie. Door beide resultaten te bewaren voorkom je dat een oppervlakkig health-endpoint het enige bewijs in productie wordt.

Containerinstellingen die je moet controleren

Gebruik de container als een vervangbare runtime, niet als de locatie van de waarheid.

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

Sta het vereiste outbound- of client-side pad toe en verifieer dit voor outbound access naar elk gemonitord endpoint en elke alertprovider. Controleer de container user, writable paths en de gebonden listener voordat je de service blootstelt. Voer de volledige actie uit — maak HTTP- en TCP-monitors aan, forceer één gecontroleerde storing en ontvang de alert en herstelmelding via de gekozen provider — en bewaar de exacte image reference die het resultaat heeft opgeleverd.

Uptime Kuma herstellen op een lege host

Bescherm de state van Uptime Kuma voordat je de container optimaliseert. De vereiste set bestaat uit de SQLite-database en geüploade assets in /app/data. Mount /app/data vóór de bootstrap, schrijf onschadelijke sampledata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Als meerdere stores consistent moeten blijven, documenteer dan de volgorde waarin writes worden gepauzeerd en back-ups worden gemaakt.

Bewaar kopieën buiten de deploymentserver en versleutel materiaal dat credentials of private content bevat. Recovery is geslaagd wanneer de monitorhistorie, notification credentials en maintenance windows terugkeren en een testalert nog steeds wordt afgeleverd. Het verschil tussen een persistente mount en een onafhankelijke kopie wordt behandeld in persistente opslag en snapshots.

Geef Uptime Kuma één canoniek adres

Publiceer één stabiele HTTPS-origin via de reverse proxy. Stuur de gekozen hostname naar containerpoort 3001, stuur de oorspronkelijke host en het HTTPS-schema door en voorkom dat een tweede directe origin wordt gepubliceerd.

Test Uptime Kuma vanaf een schone externe client. Maak onderscheid tussen een ingress-fout en de bekende applicatiegrens: het datavolume is alleen-lezen of container-DNS kan de gemonitorde hosts niet resolven. Een certificaat-, DNS- of 502-fout hoort bij routing; een request dat Uptime Kuma bereikt en daarna faalt, hoort bij applicatiestate, capaciteit of de ondersteunende vereiste. De handleiding voor custom-domain TLS behandelt de eerste groep.

Beveiligingsbeslissingen die specifiek zijn voor Uptime Kuma

Het applicatiespecifieke beveiligingsrisico is het uitvoeren van de first-user setup op een publiek blootgestelde instance. Het operationele antwoord is om de first-user setup privé af te ronden en vervolgens dashboards en status-page administration afzonderlijk te beveiligen. Rond de bootstrap af via een beperkte route en verwijder tijdelijke setup-toegang direct daarna.

UPTIME_KUMA_PORT bepaalt gedrag, niet vertrouwelijkheid; valideer het type en de waarde ervan en bewaar echte Uptime Kuma-credentials afzonderlijk. Geef het Uptime Kuma-proces alleen de gedocumenteerde mounts en dependency routes; vermijd toegang tot de host root en de Docker socket. Log mislukte authenticatie en configuratiefouten, maar redigeer tokens, connection strings en user content.

Voor een Dockup-deployment is nog steeds een Uptime Kuma-acceptatietest nodig

Routing, certificaten, service replacement en attached storage zijn redelijke automatiseringsdoelen. Dockup regelt deze voor Uptime Kuma en kan de bijbehorende managed database provisionen of verbinding maken met services op de eigen server van een klant.

Wat het niet moet verzinnen, is het trustbeleid van Uptime Kuma. Publiceer na de deployment één stabiele HTTPS-origin via de reverse proxy, dwing deze grens af — rond de first-user setup privé af en beveilig vervolgens dashboards en status-page administration afzonderlijk — en verifieer het resultaat van dit scenario: maak HTTP- en TCP-monitors aan, forceer één gecontroleerde storing en ontvang de alert en herstelmelding via de gekozen provider. Het resultaat is one-click infrastructure met een applicatiespecifieke acceptatietest.

Veelgestelde vragen

Wat heeft Uptime Kuma nodig voor een production deployment?

Routeer de Uptime Kuma-container op poort 3001 via één HTTPS-origin. De externe deliveryvereiste is outbound access naar elk gemonitord endpoint en elke alertprovider. Verklaar Uptime Kuma pas gereed wanneer je HTTP- en TCP-monitors kunt aanmaken, één gecontroleerde storing kunt forceren en de alert en herstelmelding via de gekozen provider ontvangt.

Welke Uptime Kuma-data hoort in een back-up?

Maak /app/data persistent en neem de SQLite-database en geüploade assets in /app/data op in hetzelfde recovery manifest. Een schone Uptime Kuma-restore is alleen geslaagd wanneer de monitorhistorie, notification credentials en maintenance windows terugkeren en een testalert nog steeds wordt afgeleverd.

Heeft Uptime Kuma HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Uptime Kuma-origin en houd poort 3001 op de interne route. Pas de Uptime Kuma-instelling correct toe: publiceer één stabiele HTTPS-origin via de reverse proxy. Voor Uptime Kuma beschermt HTTPS credentials of user content tijdens transport en zorgt het voor consistent gedrag van clients die afhankelijk zijn van de origin.

Hoe moet je een Uptime Kuma-upgrade testen?

Herstel de huidige Uptime Kuma-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat SQLite-migraties en wijzigingen aan notification providers van een snelle image pull een stateful application-upgrade kunnen maken. Houd de vorige Uptime Kuma-image beschikbaar totdat de grenzen voor datamigratie en rollback duidelijk zijn.