Uptime Kuma Version 2: Migration & warum „latest“ fehlt

Uptime Kuma hatte ich hier auf dem Blog schon einmal vorgestellt – aber seitdem hat sich einiges getan. Es ist nämlich Version 2 erschienen. So leise, dass viele sie schlicht nicht bekommen, weil das Docker-Tag latest nicht mehr das tut, was man von ihm erwartet. Klingt komisch? Ist aber so. Ich erkläre dir in diesem Beitrag, was es damit auf sich hat und wie du sauber von Version 1 auf Version 2 migrierst.

Kurz für alle, die Uptime Kuma noch nicht kennen

Uptime Kuma ist ein kleines, selfhosted Monitoring-Tool – schön lightweight und wirklich hervorragend funktionierend. Es kann zum Beispiel HTTP-Requests senden, Pings absetzen oder TCP-Ports prüfen, und noch eine ganze Menge mehr. Im Kern geht es um genau eine Frage: Sind deine Dienste erreichbar, so wie sie erreichbar sein sollen?

Ein Monitor ist schnell eingerichtet. Oben wählst du den Monitoring Type – etwa „TCP Port“, um zu prüfen, ob ein Port auf einem Host offen ist. Du gibst Hostname und Port an, vergibst einen Namen, speicherst – und schon läuft der Checker. Erreicht er sein Ziel nicht, schlägt er rot aus; ist alles in Ordnung, bleibt er grün. Aus den Messpunkten entstehen mit der Zeit ein paar schöne Grafen, und natürlich lassen sich auch Benachrichtigungen einrichten.

Wenn du also ein leichtgewichtiges Überwachungstool suchst, das dir einfach sagt, ob deine Dienste laufen, bekommst du mit Uptime Kuma ein wirklich starkes Werkzeug.

Das Problem: „latest“ ist nicht mehr die neueste Version

Jetzt zum eigentlichen Thema. In meiner Testumgebung zeigt mir Uptime Kuma rechts oben „Aktualisierung verfügbar“ an. Unter Einstellungen → Über sehe ich, dass ich noch auf einer 1.x-Version unterwegs bin. Also ein Update – sollte man meinen.

Meine Testinstanz läuft im Portainer und nutzt das latest-Image. Ich gehe also den gewohnten Weg: Recreate mit aktivierter Option Re-pull image. Damit zieht Portainer normalerweise zuverlässig das neueste latest-Image und startet den Container neu. Das klappt auch – nur passiert dabei eben keine Migration auf Version 2.

Der Grund: Version 2 erfordert eine echte Datenbank-Migration, weil sich im Hintergrund das Datenbank-Schema bzw. die Datenbank-Optionen geändert haben. Und genau deshalb ist das Wörtchen latest im Docker-Universum nicht mehr automatisch die wirklich aktuelle Version. Auf der Docker-Hub-Seite steht es ganz oben unmissverständlich: latest ist „deprecated“.

Warum überhaupt? Man kann sich gut vorstellen, dass mit all den Monitoren, die Nutzer einrichten, sehr viele Messpunkte in der Datenbank entstehen. Das ursprüngliche Datenbank-Design war für diese Größenordnung – die so vorher schlicht nicht absehbar war – offenbar nicht optimal ausgelegt. Version 2 räumt hier auf.

Wichtig vorab: Mach ein Backup!

Bevor wir loslegen, der wichtigste Satz dieses Beitrags – und der steht auch in der offiziellen Doku gefühlt zehnmal drin: Mach ein Backup.

Ein Backup eines Docker-Containers bedeutet in der Praxis: Sichere die persistenten Daten, also dein Volume. Bei Uptime Kuma ist das der Ordner bzw. das Volume, in dem die Datenbank liegt. Genau diese Daten werden gleich in das neue Datenbankformat migriert – wenn dir deine Monitore und deine Historie lieb sind, sicherst du dieses Volume also vorher. Den Container selbst muss man nicht sichern; das macht in der Regel niemand und ist auch nicht nötig.

Die richtigen Docker-Tags für Version 2

Bevor du Version 2 einsetzt, lohnt ein Blick ins Docker Hub. Dort tauchen die relevanten Tags auf:

• 2 – die fixe Versionslinie 2. Wählst du dieses Tag, bleibst du im automatischen Update-Zirkel und bekommst über Portainer („Recreate this container“) immer die neueste 2er-Version.
• next – im Prinzip das, was früher latest war: die jeweils aktuelle Version. Auch damit bleibst du automatisch aktuell.
• nightly2 – ein Nightly-Build, der jede Nacht neu generiert wird.
• Rootless-Variante – ein Container, der ohne Root-Rechte läuft. Praktisch aus Sicherheitsgründen, allerdings funktioniert dann nicht immer alles.
• Feste Versions-Tags – wenn du eine ganz konkrete Version festnageln möchtest.

Mein Tipp: Nimm 2 oder next, wenn du wie gewohnt automatische Updates über deinen Portainer haben möchtest.

Die Migration: Schritt für Schritt

Die offizielle Doku verweist im Wiki unter „How to Update“ auf den Migrationsweg. Im Kern ist er angenehm simpel. Für einen klassischen docker run-Aufbau läuft es so:

1. Backup des Volumes erstellen (siehe oben).
2. Das neue Image louislam/uptime-kuma:2 herunterladen.
3. Die aktuelle Instanz stoppen.
4. Den alten Container entfernen.
5. Den Container mit dem vorhandenen Volume neu starten – diesmal eben mit dem 2-Tag statt latest.

Für alle, die Uptime Kuma per Docker Compose betreiben, gibt es die entsprechende Anleitung ebenfalls in der Doku: Dort passt du einfach das YAML an. Und auch für Non-Docker-Installationen (via npm) ist ein Weg beschrieben – wobei das erfahrungsgemäß die wenigsten betrifft. Docker ist hier einfach die komfortabelste Variante.

Ich nehme an dieser Stelle die Schnellvariante über Portainer: Ich gehe in meinen Container, wähle Duplicate/Edit, entferne hinten das latest und mache schlicht eine 2 daraus. Alles andere lasse ich stehen und klicke auf Deploy the container mit Replace. Portainer lädt das neue Image herunter und startet den Container neu.

Was bei der Migration im Hintergrund passiert

Ein Blick in die Logs zeigt es: Beim ersten Start unter Version 2 wird die Datenbank-Migration durchgeführt. Es werden neue Tabellen aufgebaut, und die vorhandenen Daten werden in die neue Datenbankstruktur übertragen. Hast du viele Daten, dauert dieser Schritt einen Moment länger – das ist normal.

Das Wichtigste: Der gesamte Migrationsprozess ist vollständig automatisiert. Du musst wirklich nur die Version deines Containers ändern, den Rest erledigt Uptime Kuma selbst. Nach einem F5 im Browser ist der Hinweis „Aktualisierung verfügbar“ verschwunden, und unter Einstellungen → Über steht jetzt eine aktuelle 2.3.x-Version.

„Sieht doch alles gleich aus“ – und das ist gut so

Vielleicht fragst du dich jetzt: neue Major-Version, und es sieht aus wie vorher? Genau so ist es gewollt. Der Hauptfokus von Version 2 lag darin, das System zu optimieren – insbesondere datenbanktechnisch – und eben nicht, die ohnehin schon schöne, lightweighte Oberfläche umzubauen. Unter der Haube hat sich viel getan, optisch bewusst wenig.

Noch ein Hinweis für alle, die Auto-Updates über Tools wie Watchtower fahren: Watchtower wird nach meinem Kenntnisstand inzwischen nicht mehr aktiv gepflegt. Wer es trotzdem einsetzt, dessen Uptime-Kuma-Container fällt nach der Umstellung auf das 2– oder next-Tag aber wieder ganz normal in den Update-Zyklus zurück.

Bonus: Docker-Container direkt überwachen

Zum Schluss noch ein Feature, das sich wirklich lohnt, wenn Uptime Kuma dein Hauptmonitoring ist: Du kannst damit mittlerweile auch Docker-Container überwachen – nicht nur Dienste per Ping oder HTTP-Request.

Die Einrichtung ist einfach. Du gibst deinem Uptime-Kuma-Container Zugriff auf den Docker-Socket:

1. Im Container unter Volumes einen Bind-Mount einrichten, der /var/run/docker.sock vom Host in den Container hängt.
2. Container mit Deploy / Replace neu ausrollen.
3. In Uptime Kuma einen neuen Monitor anlegen und als Typ Docker Container wählen.
4. Vorher unter Docker Hosts einen neuen Host hinzufügen – ich nenne ihn z. B. „Docker Environment“ – und als Verbindung den Socket /var/run/docker.sock eintragen. Mit einem Klick auf Test sollte ein grünes Symbol erscheinen, dann speichern.
5. Beim Monitor selbst den Container angeben – Container-Name reicht völlig aus, alternativ ginge auch die Container-ID. Intervall und Benachrichtigung wie gewohnt einstellen, speichern, fertig.

Ab sofort werden deine Container direkt über den Socket überwacht. Falls dir also mal ein Container um die Ohren fliegt, bekommst du es sofort mit.

Mein Fazit

Die Migration auf Version 2 ist kein Hexenwerk: Backup machen, Tag von latest auf 2 (oder next) ändern, neu deployen – den Rest erledigt Uptime Kuma automatisch. Wichtig ist nur zu wissen, dass latest eben nicht mehr automatisch zu Version 2 führt.

Ich nutze Uptime Kuma selbst für die einfache Überwachung meiner Umgebung – einfach, um eine Meldung zu bekommen, wenn etwas nicht stimmt. Egal ob per SMS über mein SMS-Gateway, per Mail oder per Gotify: Das funktioniert alles hervorragend. Für die einfache, zuverlässige Überwachung ist das ein wirklich starkes Tool, und mit Version 2 ist es unter der Haube nochmal deutlich besser geworden.