Uptime Kuma im Jahr 2026 hosten: Preise und Plattformbeschränkungen

Stand November 2026 haben Teams, die das Open-Source-Monitoring-Tool Uptime Kuma selbst hosten möchten, fünf primäre Infrastrukturoptionen, die sich jeweils durch unterschiedliche Kostenstrukturen und technische Kompromisse auszeichnen. Die Analyse zeigt, dass Plattformen wie Heroku und Replit aufgrund von Dateisystembeschränkungen nicht mehr praktikabel sind, während Dienste wie Ownkube, Fly.io, Railway und Render unterstützte Umgebungen neben traditionellen virtuellen privaten Servern (VPS) anbieten.

Was ist passiert?

Uptime Kuma ist ein einzelner Node.js-Prozess, der eine SQLite-Datenbankdatei nutzt, um Monitor-Konfigurationen, Prüfhistorie und Einstellungen zu speichern. Aufgrund dieser Architektur muss die Hosting-Umgebung einen Datenträger bereitstellen, der Neustarts und erneute Bereitstellungen übersteht. Die Anwendung kann auf ephemeren Dateisystemen nicht korrekt funktionieren, weshalb die offizielle README-Datei Heroku und Replit als nicht unterstützte Plattformen auflistet. Jeder gewählte Host muss sicherstellen, dass das Datenverzeichnis auf einem lokalen oder Block-Volumen liegt und nicht auf einem Netzwerk-Dateisystem wie NFS, das ebenfalls inkompatibel ist.

Die praktischen Optionen für 2026 umfassen Ownkube, Fly.io, Railway, Render und selbst verwaltete VPS-Instanzen. Jede Option variiert in Bezug auf Einrichtungskomplexität, monatliche Kosten und Wartungsverantwortung. Ownkube bietet eine One-Click-Bereitstellung mit automatischem HTTPS und einem Prepaid-Abrechnungsmodell. Fly.io bietet den niedrigsten Einstiegspreis, erfordert jedoch eine manuelle Konfiguration über eine fly.toml-Datei. Railway und Render bieten vorlagenbasierte oder Docker-basierte Bereitstellungen mit persistenten Datenträgern, wobei Render spezifische Einschränkungen bei Zero-Downtime-Bereitstellungen auferlegt, wenn Datenträger angehängt sind. Ein selbst verwalteter VPS bleibt die Option für jene, die bereits Serverinfrastruktur betreiben und volle Kontrolle über OS-Updates und Firewall-Regeln wünschen.

Wichtige Details

• Ownkube: Kostet etwa 5 USD pro Monat mit minutengenauer Abrechnung. Es umfasst ein 2 GiB großes persistentes Volumen ohne zusätzliche Speicherkosten und behandelt HTTPS automatisch. Die Plattform übernimmt das Patchen des Servers.
• Fly.io: Die günstigste Option mit etwa 2,34 USD pro Monat für eine 256 MB Machine und ein 1 GB Volumen. Benutzer müssen eine fly.toml-Konfigurationsdatei schreiben, um das Volumen korrekt einzuhängen. Volumina werden basierend auf der provisionierten Größe abgerechnet, auch wenn die Maschine gestoppt ist.
• Railway: Erfordert eine Hobby-Gebühr von 5 USD, die 5 USD Nutzungsgebühr einschließt. Vorlagen hängen Volumina automatisch an, aber intensive Nutzung kann das enthaltene Guthaben überschreiten. Speicher und CPU werden separat berechnet, wenn Limits überschritten werden.
• Render: Beginnt bei 7,25 USD pro Monat für eine Starter-Instanz plus Disk-Kosten. Dienste mit angehängten Disks verlieren die Fähigkeit zu Zero-Downtime-Bereitstellungen, was zu kurzen Ausfällen des Monitors während Updates führt. Es kann nicht über eine Instanz hinaus skaliert werden, was mit der Single-Writer-Einschränkung von SQLite übereinstimmt.
• Selbst verwalteter VPS: Bietet die niedrigsten Stückkosten für jene, die bereits für Serverinfrastruktur zahlen. Der Nutzer ist verantwortlich für OS-Patches, Reverse-Proxy-Konfiguration, Zertifikatsverwaltung und Backups. Docker Compose ist die Standard-Installationsmethode.

Hintergrund

Die Abhängigkeit von Uptime Kuma von SQLite diktiert mehrere kritische Infrastruktur-Anforderungen. SQLite erlaubt nur einen Schreibzugriff zur gleichen Zeit, was bedeutet, dass die Anwendung als einzelne Instanz laufen muss. Horizontales Skalieren mit mehreren Kopien ist nicht möglich, ohne das Datenbank-Backend zu ändern, was Uptime Kuma in diesem Kontext nativ nicht unterstützt. Zusätzlich darf der Prozess niemals in den Ruhezustand versetzt werden. Viele Cloud-Anbieter bieten kostenlose Tarife an, die Container nach Inaktivitätsphasen herunterfahren, um Ressourcen zu sparen. Für ein Monitoring-Tool ist dieses Verhalten fatal, da ein schlafender Monitor keine Ausfälle erkennen kann und genau dann eine Blindstelle entsteht, wenn er am meisten benötigt wird.

Eine weitere wesentliche Anforderung ist ein öffentlicher Hostname mit HTTPS. Dies ist sowohl für den sicheren Zugriff auf das administrative Dashboard als auch für die Bereitstellung von Statusseiten für Endbenutzer erforderlich. Während einige Plattformen dies automatisch bereitstellen, erfordern andere eine manuelle Konfiguration von Reverse Proxies und TLS-Zertifikaten. Die Wahl des Hosts hängt oft davon ab, ob das Team verwalteten Komfort oder granulare Kontrolle über diese Netzwerkebenen bevorzugt.

Warum es wichtig ist

Für Teams, die ihre eigene Software betreiben, ist die Platzierung des Monitoring-Tools genauso kritisch wie das Tool selbst. Wenn Uptime Kuma auf derselben Plattform, Region oder demselben Server läuft wie die überwachten Anwendungen, wird ein weitreichender Ausfall den Monitor zusammen mit den Apps lahmlegen. Dies führt zu einem stillen Fehler, bei dem keine Warnungen gesendet werden und die Statusseite für Benutzer, die Informationen suchen, unzugänglich wird. Um dies zu vermeiden, sollte der Monitor bei einem anderen Anbieter oder in einer anderen Region als die primären Anwendungen gehostet werden. Zum Beispiel könnten Apps auf einer Plattform in Deutschland laufen, während der Monitor in Mumbai oder auf einem völlig anderen Dienst platziert wird.

Kostenplanbarkeit und operativer Aufwand sind ebenfalls signifikante Faktoren. Selbsthosting eliminiert die pro Monitor anfallenden Gebühren kommerzieller SaaS-Lösungen wie UptimeRobot, die 9 USD pro Monat für ihren Solo-Plan verlangt, um 60-Sekunden-Prüfintervalle zu erreichen. Allerdings bringt Selbsthosting die Belastung mit sich, die zugrunde liegende Infrastruktur zu warten. Teams müssen die Einsparungen gegen die Zeit abwägen, die für die Verwaltung von Server-Updates, Backups und Sicherheits-Patches aufgewendet wird. Die Entscheidung hängt oft davon ab, ob die Organisation bereits DevOps-Kapazitäten hat, um einen VPS zu verwalten, oder die Einfachheit einer verwalteten Container-Plattform bevorzugt.

Was Sie tun können

• Stellen Sie sicher, dass das Datenverzeichnis für Uptime Kuma auf einem persistenten Volumen gemountet ist, das Neustarts und erneute Bereitstellungen übersteht.
• Deaktivieren Sie alle Idle-Sleep- oder Spin-down-Funktionen in Ihrer Hosting-Plattform, um kontinuierliche Monitoring-Prüfungen zu gewährleisten.
• Führen Sie nur eine Instanz von Uptime Kuma aus, um Korruption der SQLite-Datenbank durch gleichzeitige Schreibvorgänge zu verhindern.
• Hosten Sie den Monitor bei einem anderen Cloud-Anbieter oder in einer anderen geografischen Region als Ihre Produktionsanwendungen, um Verfügbarkeit während Ausfällen zu sichern.
• Richten Sie eine regelmäßige Backup-Routine für die SQLite-Datendatei ein, um Monitor-Historie und Konfiguration zu erhalten.
• Senden Sie Testwarnungen an alle konfigurierten Kanäle, wie E-Mail, Slack oder Telegram, um sicherzustellen, dass die Benachrichtigungspfade funktionsfähig sind, bevor Sie sich darauf verlassen.