Uptime Kuma 2026 selbst hosten: Alerts, TLS und persistente Daten

Die meisten Installationsanleitungen für Uptime Kuma enden nach dem ersten Seitenaufruf. Das ist zu früh: Das Daten-Volume ist schreibgeschützt oder der Container-DNS kann die überwachten Hosts nicht auflösen. Ein aussagekräftiger Production-Test ist anspruchsvoller — erstellen Sie HTTP- und TCP-Monitore, erzwingen Sie einen kontrollierten Ausfall und empfangen Sie den Alert sowie die Wiederherstellungsmeldung über den gewählten Provider.

Die Rolle von Uptime Kuma ist klar: Monitoring bestehender Services mit Alerts an mehr als 90 Zielsysteme. Sein operativer Umfang geht über den Web-Prozess hinaus. Deshalb müssen Dependency, gespeicherter Zustand und öffentlicher Zugriffspfad explizit benannt werden, bevor echte Daten anfallen.

Erfolg für Uptime Kuma zuerst definieren

Ein aussagekräftiges Uptime-Kuma-Diagramm zeigt den öffentlichen Zugriffspfad, den privaten Port 3001, die Zustandsgrenze und alle unterstützenden Voraussetzungen. Kennzeichnen Sie, welche Pfeile Credentials übertragen und welche normalen User-Traffic darstellen. Die externe Voraussetzung für Uptime Kuma ist ausgehender Zugriff auf jeden überwachten Endpoint und jeden Alert-Provider. Testen Sie ausgehendes DNS, TLS und das Verhalten des Providers, ohne einen weiteren eingehenden Service zu veröffentlichen.

Beweisen Sie das Diagramm mit einer echten Aktion: Erstellen Sie HTTP- und TCP-Monitore, erzwingen Sie einen kontrollierten Ausfall und empfangen Sie den Alert sowie die Wiederherstellungsmeldung über den gewählten Provider. Die wahrscheinliche Belastung entsteht durch das Monitor-Intervall, die Anzahl der Retries, den Traffic von Status Pages und die Anzahl ausgehender Probes, die in derselben Sekunde ausgeführt werden. Überwachen Sie diesen Pfad, anstatt alle HTTP-Requests gleich zu behandeln.

Uptime Kuma entlang seines tatsächlichen Bottlenecks betreiben

Die erste nützliche Betriebsmetrik für Uptime Kuma ist die Frage, ob HTTP- und TCP-Monitore erstellt, ein kontrollierter Ausfall erzwungen und der Alert sowie die Wiederherstellungsmeldung über den gewählten Provider empfangen werden können. Kombinieren Sie das mit Saturation-Signalen für das Monitor-Intervall, die Anzahl der Retries, den Traffic von Status Pages und die Anzahl ausgehender Probes, die in derselben Sekunde ausgeführt werden. Ein reiner Process-Probe sollte keine teuren Dependencies aufrufen oder den Container neu starten, nur weil ein Upstream kurzzeitig nicht verfügbar ist.

Behandeln Sie Upgrades als Datenänderungen, da SQLite-Migrationen und Änderungen am Notification-Provider aus einem schnellen Image-Pull ein zustandsbehaftetes Application-Upgrade machen können. Pinnen Sie Versionen, proben Sie Upgrades mit wiederhergestelltem Zustand und halten Sie das vorherige Image verfügbar, solange ein Rollback noch möglich ist. Wenn das Daten-Volume schreibgeschützt ist oder der Container-DNS die überwachten Hosts nicht auflösen kann, sichern Sie die Logs vor dem Neustart. Sie enthalten meist die ursächliche Meldung.

Ein funktionierendes Uptime-Kuma-Deployment dokumentieren

Definieren Sie für Uptime Kuma vor dem Start eine bekannte funktionierende Transaktion: Erstellen Sie HTTP- und TCP-Monitore, erzwingen Sie einen kontrollierten Ausfall und empfangen Sie den Alert sowie die Wiederherstellungsmeldung über den gewählten Provider. Hinterlegen Sie die Voraussetzungen, die erwartete Antwort und die Cleanup-Schritte in der Versionsverwaltung — ohne Secret-Werte. Pinnen Sie das Image, mit dem diese Referenz erstellt wurde.

Verwenden Sie die Transaktion, um einen Ersatz und eine unabhängige Wiederherstellung zu validieren. Der wiederhergestellte Service ist nur dann akzeptabel, wenn die Monitor-Historie, Notification-Credentials und Maintenance Windows wieder vorhanden sind und ein Test-Alert weiterhin zugestellt wird. Beobachten Sie gleichzeitig das Monitor-Intervall, die Anzahl der Retries, den Traffic von Status Pages und die Anzahl ausgehender Probes, die in derselben Sekunde ausgeführt werden. Machen Sie den langsamsten oder am stärksten begrenzten Teil zu einem Service-Level-Alert.

Der Abnahmetest benötigt außerdem einen Negativfall: Verweigern Sie vorübergehend den Testpfad, der für den ausgehenden Zugriff auf jeden überwachten Endpoint und jeden Alert-Provider verwendet wird. Bestätigen Sie, dass Uptime Kuma einen verwertbaren Fehler erzeugt und dabei die Daten erhält, stellen Sie den gültigen Zustand wieder her und wiederholen Sie die bekannte funktionierende Transaktion. Wenn beide Ergebnisse dokumentiert sind, kann ein oberflächlicher Health-Endpoint nicht zur einzigen Evidenz für den Production-Betrieb werden.

Container-Einstellungen, die Sie prüfen sollten

Verwenden Sie den Container als austauschbare Runtime, nicht als Ort der Wahrheit.

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

Erlauben und prüfen Sie den für den ausgehenden Zugriff auf jeden überwachten Endpoint und jeden Alert-Provider erforderlichen Outbound- oder Client-seitigen Pfad. Prüfen Sie den Container-User, beschreibbare Pfade und den gebundenen Listener, bevor Sie den Service veröffentlichen. Führen Sie die vollständige Aktion aus — erstellen Sie HTTP- und TCP-Monitore, erzwingen Sie einen kontrollierten Ausfall und empfangen Sie den Alert sowie die Wiederherstellungsmeldung über den gewählten Provider — und speichern Sie die exakte Image-Referenz, mit der das Ergebnis erzielt wurde.

Uptime Kuma auf einem leeren Host wiederherstellen

Schützen Sie den Zustand von Uptime Kuma, bevor Sie den Container optimieren. Benötigt werden die SQLite-Datenbank und hochgeladene Assets in /app/data. Mounten Sie /app/data vor dem Bootstrap, schreiben Sie harmlose Beispieldaten und ersetzen Sie den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Wenn mehrere Stores konsistent sein müssen, dokumentieren Sie die Reihenfolge, in der Schreibvorgänge pausiert und Backups erstellt werden.

Bewahren Sie Kopien außerhalb des Deployment-Servers auf und verschlüsseln Sie Material, das Credentials oder private Inhalte enthält. Die Wiederherstellung ist erfolgreich, wenn die Monitor-Historie, Notification-Credentials und Maintenance Windows wieder vorhanden sind und ein Test-Alert weiterhin zugestellt wird. Der Unterschied zwischen einem persistenten Mount und einer unabhängigen Kopie wird in persistent storage and snapshots erläutert.

Uptime Kuma eine kanonische Adresse geben

Veröffentlichen Sie einen stabilen HTTPS-Origin über den Reverse Proxy. Leiten Sie den gewählten Hostnamen an den Container-Port 3001 weiter, geben Sie den ursprünglichen Host und das HTTPS-Scheme weiter und vermeiden Sie einen zweiten direkten Origin.

Testen Sie Uptime Kuma von einem sauberen externen Client aus. Trennen Sie Routing-Fehler von der bekannten Application Boundary — das Daten-Volume ist schreibgeschützt oder der Container-DNS kann die überwachten Hosts nicht auflösen. Ein Zertifikats-, DNS- oder 502-Fehler gehört zum Routing. Erreicht ein Request Uptime Kuma und schlägt erst danach fehl, liegt die Ursache in Application State, Kapazität oder einer unterstützenden Voraussetzung. Der Leitfaden für TLS mit eigener Domain behandelt die erste Gruppe.

Uptime-Kuma-spezifische Security-Entscheidungen

Das anwendungsspezifische Security-Risiko besteht darin, das First-User-Setup auf einer öffentlich erreichbaren Instanz auszuführen. Die operative Antwort lautet: Schließen Sie das First-User-Setup privat ab und schützen Sie Dashboards sowie die Administration von Status Pages anschließend separat. Führen Sie den Bootstrap über einen eingeschränkten Zugriffspfad durch und entfernen Sie den temporären Setup-Zugriff sofort danach.

UPTIME_KUMA_PORT steuert das Verhalten, nicht die Vertraulichkeit. Validieren Sie Typ und Wert und speichern Sie echte Uptime-Kuma-Credentials separat. Geben Sie dem Uptime-Kuma-Prozess nur die dokumentierten Mounts und Dependency-Routen. Vermeiden Sie Zugriff auf Host-Root und den Docker-Socket. Protokollieren Sie fehlgeschlagene Authentifizierungen und Konfigurationsfehler, redigieren Sie jedoch Tokens, Connection Strings und User-Inhalte.

Auch ein Dockup-Deployment benötigt einen Uptime-Kuma-Abnahmetest

Routing, Zertifikate, das Ersetzen von Services und angebundener Storage sind sinnvolle Automatisierungsziele. Dockup übernimmt diese Aufgaben für Uptime Kuma und kann die zugehörige Managed Database provisionieren oder eine Verbindung zu Services auf dem Server des Kunden herstellen.

Was Dockup nicht erfinden sollte, ist die Trust Policy von Uptime Kuma. Veröffentlichen Sie nach dem Deployment einen stabilen HTTPS-Origin über den Reverse Proxy, setzen Sie diese Grenze durch — schließen Sie das First-User-Setup privat ab und schützen Sie Dashboards sowie die Administration von Status Pages anschließend separat — und verifizieren Sie das Ergebnis dieses Szenarios: Erstellen Sie HTTP- und TCP-Monitore, erzwingen Sie einen kontrollierten Ausfall und empfangen Sie den Alert sowie die Wiederherstellungsmeldung über den gewählten Provider. Das Ergebnis ist eine One-Click-Infrastruktur mit einem anwendungsspezifischen Abnahmetest.

Häufig gestellte Fragen

Was benötigt Uptime Kuma für ein Production-Deployment?

Führen Sie den Uptime-Kuma-Container über einen einzigen HTTPS-Origin auf Port 3001. Die externe Voraussetzung für die Zustellung ist ausgehender Zugriff auf jeden überwachten Endpoint und jeden Alert-Provider. Betrachten Sie Uptime Kuma erst dann als bereit, wenn Sie HTTP- und TCP-Monitore erstellen, einen kontrollierten Ausfall erzwingen und den Alert sowie die Wiederherstellungsmeldung über den gewählten Provider empfangen können.

Welche Uptime-Kuma-Daten gehören in ein Backup?

Machen Sie /app/data persistent und nehmen Sie die SQLite-Datenbank sowie die hochgeladenen Assets in /app/data in dasselbe Recovery-Manifest auf. Eine saubere Wiederherstellung von Uptime Kuma ist erst dann erfolgreich, wenn die Monitor-Historie, Notification-Credentials und Maintenance Windows wieder vorhanden sind und ein Test-Alert weiterhin zugestellt wird.

Benötigt Uptime Kuma hinter einem Reverse Proxy HTTPS?

Verwenden Sie HTTPS für den öffentlichen Uptime-Kuma-Origin und belassen Sie Port 3001 im internen Zugriffspfad. Wenden Sie die Uptime-Kuma-Einstellung korrekt an: Veröffentlichen Sie einen stabilen HTTPS-Origin über den Reverse Proxy. Bei Uptime Kuma schützt HTTPS Credentials oder User-Inhalte während der Übertragung und sorgt für ein konsistentes, Origin-sensitives Client-Verhalten.

Wie sollte ein Uptime-Kuma-Upgrade getestet werden?

Stellen Sie den aktuellen Uptime-Kuma-Zustand in einem isolierten Deployment wieder her, wenden Sie die Kandidatenversion an und wiederholen Sie die Abnahmetransaktion. Gehen Sie besonders sorgfältig vor, da SQLite-Migrationen und Änderungen am Notification-Provider aus einem schnellen Image-Pull ein zustandsbehaftetes Application-Upgrade machen können. Behalten Sie das vorherige Uptime-Kuma-Image, bis die Grenzen von Datenmigration und Rollback verstanden sind.