Nach monatelanger Entwicklung ist am 20. Oktober 2025 die Version 2.0 von Uptime Kuma erschienen – das wohl größte Update in der Geschichte des beliebten Open-Source-Monitoring-Tools. Mit über 77.000 GitHub-Stars und einer aktiven Community hat sich Uptime Kuma als führende self-hosted Alternative zu kommerziellen Diensten wie UptimeRobot etabliert. Version 2.0 bringt nun zwei langersehnte Funktionen: MariaDB-Unterstützung für große Deployments und rootless Docker-Images für erhöhte Sicherheit. Doch das Major-Update erfordert eine sorgfältige Migration und bringt einige Breaking Changes mit sich.
Was ist Uptime Kuma?
Uptime Kuma ist eine kostenlose, selbst gehostete Monitoring-Lösung, die von Louis Lam entwickelt wurde. Das Tool überwacht die Verfügbarkeit von Websites, Servern, APIs und verschiedensten Netzwerkdiensten. Die Idee entstand, als Lam nach einer modernen Alternative zu „Uptime Robot“ suchte, die man auf eigener Infrastruktur betreiben kann. Das Ergebnis ist eine reaktionsschnelle Web-Anwendung mit intuitivem Interface, die HTTP(S), TCP, ICMP, DNS, Docker Container, Datenbanken und viele weitere Protokolle überwacht.
Die Stärken von Uptime Kuma liegen in seiner Einfachheit und Flexibilität: Eine Docker-Installation ist in wenigen Minuten erledigt, über 90 Notification-Dienste werden unterstützt (von Telegram über Discord bis zu Email), und die moderne Vue.js-basierte Oberfläche bietet sowohl Dark Mode als auch mobile Optimierung. Status Pages ermöglichen es, die Verfügbarkeit öffentlich zu kommunizieren – ideal für Agenturen, DevOps-Teams und Homelab-Enthusiasten gleichermaßen.
MariaDB bringt die Skalierung, die große Deployments brauchten
Die bedeutendste Neuerung in Version 2.0 ist die MariaDB/MySQL-Unterstützung. Bisher nutzte Uptime Kuma ausschließlich SQLite als Datenbank, was für kleine bis mittlere Setups völlig ausreichend war. Doch Nutzer mit hunderten Monitoren oder Datenbanken über 1,5 GB stießen an Performance-Grenzen. Mit MariaDB als optionaler Datenbank-Backend löst Version 2.0 diese Limitation.
Die neue Multi-Datenbank-Architektur ermöglicht es, Uptime Kuma horizontal zu skalieren und auch in unternehmenskritischen Umgebungen einzusetzen. Aggregate Tables optimieren die Speicherung historischer Heartbeat-Daten, was zu deutlich schnelleren Abfragen führt. Nutzer berichten von einer spürbaren Performance-Verbesserung: Die Weboberfläche lädt schneller, besonders bei umfangreichen Monitor-Listen, und die Stabilität bei hoher Last hat sich merklich verbessert.
Wichtig zu wissen: Die Migration von Version 1 zu 2 betrifft zunächst nur die SQLite-Datenbank-Optimierung. Eine automatische Migration von SQLite zu MariaDB ist nicht vorgesehen – hierfür sind externe Tools notwendig. Neue Installationen können aber direkt mit MariaDB starten.
Rootless Docker Images erhöhen die Sicherheit
Die zweite große Neuerung sind rootless Docker-Container. Bisher liefen Uptime Kuma Container mit Root-Rechten, was in produktiven Umgebungen ein Sicherheitsrisiko darstellt. Ab Version 2.0 können Container als unprivilegierter User node:node (UID 1000) ausgeführt werden, was die Angriffsfläche deutlich reduziert.
Für Kubernetes-Deployments und sicherheitsbewusste Administratoren ist dies ein entscheidender Fortschritt. Die rootless Images sind allerdings nicht für die Migration von v1 zu v2 empfohlen, da es zu Berechtigungsproblemen kommen kann. Docker bietet nun drei Image-Varianten an: Full (~1,2 GB mit Chromium und MariaDB), Slim (~800-900 MB ohne Embedded-Dienste) und Rootless.
Neue Monitoring-Funktionen erweitern die Einsatzmöglichkeiten
Version 2.0 bringt zahlreiche neue Monitor-Typen, die das Einsatzspektrum deutlich erweitern:
SNMP-Monitoring ermöglicht die Überwachung von Netzwerk-Hardware wie Switches und Routern. RabbitMQ-Monitoring richtet sich an Teams, die Message-Queue-Systeme einsetzen. Neu ist auch der Manual/Static Monitor, mit dem man Monitore mit festem Status für Dokumentationszwecke erstellen kann.
Bestehende Monitor-Typen wurden ebenfalls verbessert: Remote Browser Support erlaubt die Anbindung externer Browser-Instanzen für realistisches Website-Testing. MQTT-Monitore unterstützen nun JSON-Queries und custom Client-IDs. HTTP-Monitore können gezielt IPv4 oder IPv6 erzwingen, und OAuth2-Authentifizierung wurde um Audience-Parameter erweitert.
Über 20 neue Notification-Dienste integriert
Die Notification-Landschaft hat sich massiv erweitert: Nextcloud Talk, Brevo (ehemals Sendinblue), Home Assistant, SendGrid, Grafana OnCall und viele weitere Dienste sind nun direkt integriert. Insgesamt wurden über 20 neue Notification-Provider hinzugefügt.
Ein besonderes Highlight ist die LiquidJS-Template-Unterstützung für Email-Benachrichtigungen. Der bisherige Custom-Regex-Parser wurde durch die moderne Template-Engine ersetzt, was deutlich flexiblere HTML-Emails ermöglicht. Verfügbare Variablen sind name, msg, status, heartbeatJSON, monitorJSON und hostnameOrUrl – allerdings sind diese nun case-sensitive.
Neu ist auch die Möglichkeit, Notification-Provider hinter Proxies zu nutzen, was durch eine Environment-Variable gesteuert wird. MS Teams nutzt jetzt moderne AdaptiveCards, Discord unterstützt Threads und Foren, und Slack bietet verschiedene Message-Formate zur Auswahl.
Performance-Optimierungen spürbar im Alltag
Die Performance-Verbesserungen gehen weit über die MariaDB-Integration hinaus. Blocking I/O-Operationen wurden eliminiert, was die Reaktionsfähigkeit der Anwendung deutlich verbessert. Server-seitige Paginierung reduziert die Last auf Client-Seite, besonders bei umfangreichen Event-Listen. Die Chart-Rendering-Performance wurde durch Integration des UptimeCalculators optimiert.
Nutzer berichten, dass sich die Oberfläche „deutlich schneller anfühlt“, besonders beim Laden großer Monitor-Listen. Die Seitenlade-Performance bei hunderten überwachten URLs wurde laut Entwicklerteam signifikant verbessert. Neue aggregate Tables ermöglichen effizientere Zeitreihen-Abfragen ohne vollständige Table-Scans.
Migration erfordert Planung und Geduld
Version 2.0 ist ein Major-Release mit Breaking Changes, das eine Datenbank-Migration erfordert. Die wichtigste Regel: Backup, Backup, Backup. Der Entwickler betont mehrfach, wie wichtig eine vollständige Sicherung des Data-Verzeichnisses vor dem Update ist.
Die Migration-Dauer variiert stark je nach Datenmenge. Beispiele aus der Community: 20 Monitore mit 90 Tagen Daten benötigten etwa 7 Minuten, 40 Monitore mit 7-Tage-Retention etwa 20 Minuten, und eine 1,5 GB große Datenbank zwischen 20 und 30 Minuten. In Extremfällen auf schwacher Hardware wurden auch mehrere Stunden berichtet. Wichtig: Die Migration niemals unterbrechen und während des Prozesses die Logs überwachen.
Breaking Changes, die beachtet werden müssen:
- Node.js 20.4+ ist jetzt Mindestanforderung (Support für 14, 16, 18 entfällt)
- Alpine Docker Images werden nicht mehr bereitgestellt (nur noch Debian-basiert)
- JSON Backup/Restore Feature wurde entfernt – nur noch direktes Data-Directory-Backup
- Badge-Endpoints akzeptieren nur noch die Werte
24,24h,30d,1yfür den Duration-Parameter - Default Retry-Versuche wurden von 1 auf 0 geändert für neue Monitore
- Legacy Browser Support entfällt komplett
- Debian/Raspbian Buster sollte NICHT auf v2 aktualisieren (libseccomp2 Bug)
Die umfangreiche Migration-Guide auf GitHub erklärt jeden Schritt detailliert und listet alle Änderungen auf, die seit Beta 0 vorgenommen wurden.
Community reagiert positiv trotz Migrations-Herausforderungen
Die Community-Reaktion auf Version 2.0 ist überwiegend positiv (etwa 70% sehr positiv). Die MariaDB-Unterstützung wird als das am meisten gefeierte Feature bezeichnet. Linuxiac schreibt: „Mit MariaDB können größere Deployments endlich leichter skalieren, besonders für Setups mit hunderten Monitoren.“
Die Migrations-Komplexität ist jedoch der Hauptkritikpunkt. Einige Nutzer waren überrascht von der langen Dauer und unklaren Progress-Anzeigen. Ein GitHub-Issue berichtet von einer 10-stündigen Migration bei der die Prozentanzeige bei 0% stehen blieb. Solche Extremfälle sind selten, zeigen aber, dass die Migration nicht immer reibungslos verläuft.
Positiv hervorgehoben wird die Transparenz des Entwicklers Louis Lam. Innerhalb von zwei Tagen nach Release erschienen bereits Version 2.0.1 und 2.0.2, die kritische Bugs beheben – darunter ein Google Chrome False-Positive-Problem und Healthcheck-Issues während der Migration. Die schnelle Reaktion zeigt ein engagiertes Team.
Ein Cloudron-Nutzer fasst die Stimmung gut zusammen: „Die Weboberfläche fühlt sich deutlich schneller an – besonders beim Laden großer Monitoring-Listen.“ Ein anderer ergänzt: „Zwischen v1 und v2 liegen Welten, besonders bei der Performance.“
Technischer Ausblick: Was bedeutet das für die Zukunft?
Mit Version 2.0 positioniert sich Uptime Kuma als ernstzunehmende Enterprise-Alternative zu kommerziellen SaaS-Lösungen. Die MariaDB-Integration und rootless Container ermöglichen den Einsatz in größeren Organisationen mit strengen Sicherheits- und Compliance-Anforderungen.
Die Refactoring-Arbeiten schaffen eine solidere Code-Basis für künftige Entwicklungen. Die Migration auf Vue 3, Vite.js und Bootstrap 5 stellt sicher, dass die technische Grundlage modern bleibt. Mit über 20 unterstützten Sprachen und einer aktiven Translation-Community über Weblate wird das Tool zunehmend internationaler.
Die Entwicklung von E2E-Tests mit Playwright zeigt, dass das Projekt auf professionellere Testing-Prozesse setzt. Die Community wird ermutigt, Pull Requests zu testen und beizutragen – ein Zeichen für ein gesundes Open-Source-Ökosystem.
Fazit: Ein mutiger Schritt mit Kinderkrankheiten
Uptime Kuma 2.0 ist ein bedeutendes Update, das langjährige Limitationen adressiert und das Tool für größere Deployments fit macht. MariaDB-Support und rootless Docker sind genau die Features, die Enterprise- und Power-User gefordert haben. Die Performance-Verbesserungen sind spürbar und die erweiterten Monitoring-Funktionen decken neue Use Cases ab.
Die Migration erfordert jedoch sorgfältige Planung und Geduld. Administratoren sollten die Breaking Changes genau studieren, ausreichend Zeit einplanen und unbedingt Backups erstellen. Die ersten Wochen nach Release zeigen die typischen Kinderkrankheiten eines Major-Updates, aber die schnellen Bug-Fixes demonstrieren ein reaktionsschnelles Entwicklerteam.
Für neue Installationen ist Version 2.0 uneingeschränkt empfehlenswert. Bestehende Nutzer sollten in Testumgebungen migrieren, bevor sie produktive Systeme updaten – besonders bei großen Deployments mit hunderten Monitoren.
Empfehlung: Wer mit weniger als 50 Monitoren arbeitet und die aktuellen Performance ausreichend findet, kann mit dem Update noch etwas warten, bis die 2.x-Serie stabilisiert ist. Wer hingegen Performance-Probleme oder Skalierungs-Bedarf hat, sollte die Migration planen – die Vorteile überwiegen deutlich die Mühen des Updates.
Die Zukunft von Uptime Kuma sieht vielversprechend aus: Ein aktives Projekt, eine engagierte Community und nun eine technische Basis, die auch anspruchsvolle Anforderungen erfüllt.