Anforderungen von Uptime Kuma: wie groß der Server sein muss und wo er laufen sollte

Die Anforderungen von Uptime Kuma sind gering, und wo es läuft, ist wichtiger als seine Größe. Ein Monitor, der zusammen mit deinen Sites ausfällt, kann dir nicht melden, dass sie down sind. Kläre also zuerst den Standort, dann die Servergröße, und richte alles der Reihe nach ein.

Wo Uptime Kuma laufen sollte

Die Softwareagentur Sandstorm Media stieß darauf, als sie von UptimeRobot zu Uptime Kuma wechselte. Sie wollte den Monitor nicht in der Nähe ihrer eigenen Server haben und kaufte deshalb einen Cloud-Server in einem anderen Land.

Installiere Uptime Kuma auf einem Server, auf dem keine der Sites, Apps oder Datenbanken läuft, die es prüft. Wenn dem Server einer Site der Arbeitsspeicher ausgeht, ein Deployment schiefgeht oder eine Datenbank nicht mehr antwortet, fällt der Monitor nicht mit aus, und du bekommst trotzdem die Benachrichtigung.

Einer der Maintainer von Uptime Kuma legt die Messlatte höher: Du should not co-locate your uptime status page on the same infrastructure, datacenter or credit card. Wenn deine Sites bereits auf VPS-Servern von DreamHost laufen, teilt sich ein zweiter Server für Uptime Kuma ihr Rechenzentrum. Denn laut dem Help Center von DreamHost wird jeder VPS im Rechenzentrum US East in Ashburn, Virginia, gehostet. Er steht außerdem auf derselben Rechnung. Wenn deine Sites bei einem anderen Anbieter gehostet sind, liegt er komplett außerhalb ihrer Infrastruktur. So oder so richtest du in den Schritten unten eine externe Prüfung ein. Sie meldet dir, wenn das Rechenzentrum oder Uptime Kuma selbst ausfällt.

Wie groß der Server sein muss

Uptime Kuma nennt keine Mindestanforderungen. Die README verlangt für Installationen ohne Docker Node.js 20.4 oder neuer, mehr nicht. Ein Nutzer fand in der Dokumentation nirgends eine Angabe zu RAM oder CPU, also haben wir selbst gemessen. Am 21. und 22. Oktober 2026 haben wir Uptime Kuma 2.5.6 in Docker mit der compose.yaml des Projekts und der standardmäßigen SQLite-Datenbank betrieben. Dafür nutzten wir unsere Testmaschine mit 2 vCPU und 4 GB (arm64), keinen Server von DreamHost. Das entspricht der Ausstattung von Stack 4.

Ohne Monitore belegte es rund 200 MiB Arbeitsspeicher. Danach haben wir 200 Website-Monitore mit den Standardeinstellungen angelegt, also eine Prüfung alle 60 Sekunden ohne Wiederholungen, und alle 200 liefen ohne Fehler an. Nach 15 Minuten Prüfungen belegte der Container 237 MiB und 0,45 % der CPU, und von den 3.904 MB der Maschine waren noch 3.408 MB frei. Unsere Prüfungen riefen eine winzige Testseite auf derselben Maschine auf. Echte Sites mit HTTPS und Weiterleitungen kosten also etwas mehr. Der Test lief einmal, 15 Minuten lang, und sagt deshalb nichts über monatelange Verlaufsdaten aus.

Ein GitHub-Nutzer maß mit Version 1 auf einem gleich großen Server rund 126 MiB für 200 Prüfungen, und ein anderer Nutzer im selben Thread betrieb rund 250 Monitore auf einer Beta von Version 2 mit durchschnittlich unter 400 MiB.

Behalte vor allem den Speicherplatz im Blick: Jede Prüfung schreibt ein Ergebnis. Die Datenbank wächst also mit der Zahl deiner Monitore, der Prüfhäufigkeit und der Aufbewahrungsdauer des Verlaufs. Auf dem Server von DreamHost kannst du den Verlauf ein Jahr lang oder unbefristet aufbewahren. Der Nutzer, der 9 GB schätzte, sprach von an order of magnitude, da die Zahl aus einer 11-minütigen Stichprobe stammte. Unser Datenordner wuchs von 1,4 MB im leeren Zustand auf 5 MB nach 200 neuen Monitoren und 15 Minuten Prüfungen. Diese Stichprobe ist zu kurz, um auf Monate hochzurechnen. Stack 4 hat 75 GB Speicherplatz, prüf also anfangs alle ein bis zwei Monate df -h. Wenn er nicht mehr reicht, kannst du auf einen größeren Stack-Plan wechseln, und deine Umgebung zieht mit um.

So erreichst du das Dashboard

Der Reverse-Proxy-Leitfaden von Uptime Kuma empfiehlt einen regulären Webserver mit HTTPS davor und nennt Caddy als einen, der Zertifikate selbstständig bezieht und erneuert. Der Server für Uptime Kuma von DreamHost ist genau so aufgebaut: Du erreichst das Dashboard über Caddy, mit echtem HTTPS auf der IP des Servers.

Statusseiten und Badges sind als öffentlich gedacht und bleiben deshalb ohne Login erreichbar.

Schritt für Schritt einrichten

Die folgenden Befehle führst du als root aus. Wenn du dich als anderer Benutzer anmeldest, setzt du sudo davor.

Anmelden und aktualisieren

1. Ein Server, der sonst nichts hostet

   Bestell Stack 4 mit Uptime Kuma, die Empfehlung von DreamHost für diese Aufgabe, und nutze diesen Server ausschließlich für den Monitor.

2. Die beim ersten Start erstellten Zugangsdaten auslesen

   Das Admin-Passwort wird beim ersten Start erzeugt, noch bevor das Dashboard erreichbar ist. Verbinde dich per SSH mit dem Server und lass es dir anzeigen:

   bashKopieren

   cat /root/.uptime_kuma_credentials

   Melde dich per HTTPS über die IP deines Servers an. Bewahre das Passwort in einem Passwortmanager auf. Statusseiten kannst du später jeweils auf eine eigene Domain legen.

3. Aktualisieren, bevor du etwas hinzufügst

   Ein neuer Server startet mit der Version, die DreamHost festgelegt und getestet hat. Sie kann hinter dem neuesten Release von Uptime Kuma zurückliegen. Das Update-Skript legt selbst kein Backup an, also führ zuerst das Backup aus:

   bashKopieren

   uptime-kuma-backup
   uptime-kuma-update

   Der Updater bleibt bei Version 2 und springt nicht ohne dein Zutun auf eine neue Hauptversion. Stand 15. Oktober 2026 war 2.5.6 das neueste Release von Uptime Kuma.

Anmeldung und Benachrichtigungen einrichten

1. Zwei-Faktor-Anmeldung aktivieren

   Geh zu Settings, dann Security, und klick auf 2FA Settings. Uptime Kuma zeigt einen QR-Code, den du mit einer Authenticator-App scannst, und fragt dann zur Bestätigung einen Code aus der App ab.

2. Caddy in Uptime Kuma als vertrauenswürdig festlegen

   Geh zu Settings, dann Reverse Proxy, dann HTTP Headers, und setz Trust Proxy auf Yes, falls das noch nicht eingestellt ist. Der Reverse-Proxy-Leitfaden von Uptime Kuma nennt diese Einstellung für Server, die nur über einen vorgeschalteten Webserver erreichbar sind. Deine Logs zeigen dann die echte Adresse jedes Besuchers.

3. Erst eine Benachrichtigung, dann deine Monitore hinzufügen

   Ein ausgefallener Monitor erscheint nur auf dem Dashboard, bis du unter Settings, dann Notifications, einen Benachrichtigungsdienst hinzufügst. Verbinde zuerst E-Mail, Slack oder Telegram und leg dann deine Monitore an.

Den Monitor überwachen und eine Kopie aufbewahren

1. Eine externe Prüfung auf Uptime Kuma richten

   Der kostenlose Plan von UptimeRobot umfasst 50 Monitore mit Prüfungen alle 5 Minuten, und einer davon kann die Adresse von Uptime Kuma überwachen. Ein Kommentator auf Hacker News nutzt UptimeRobot genau dafür: I only use it to monitor the Uptime Kuma that monitors the rest of my homelab.

   Ein Heartbeat funktioniert ebenfalls. Der kostenlose Plan von Healthchecks.io überwacht 20 Jobs, und die Shell-Dokumentation liefert eine curl-Zeile, um ihn anzupingen. Setz eine kurze lokale Prüfung davor, damit der Ping nur rausgeht, solange Uptime Kuma antwortet. Füg die Zeile dann mit crontab -e in die crontab des Servers ein:

   bashKopieren

   */5 * * * * curl -fsS -m 5 -o /dev/null http://127.0.0.1:3001 && curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here

   Dieser Heartbeat belegt, dass der Server, seine geplanten Jobs und die App laufen. Die Prüfung über UptimeRobot bestätigt zusätzlich, dass das Dashboard von außen über HTTPS antwortet. Die kostenpflichtigen Pläne von UptimeRobot findest du in unserem Leitfaden zu den Preisen von UptimeRobot im Vergleich zu Pingdom und Better Stack.

2. Jedes Backup vom Server kopieren

   Der Migrationsleitfaden für v2 von Uptime Kuma bezeichnet eine Kopie des Datenverzeichnisses als einziges unterstütztes Backup. uptime-kuma-backup erstellt eine solche Kopie als lokales Archiv und zeigt dir an, wo es gespeichert wurde. Lade diese Datei von deinem eigenen Computer aus herunter:

   bashKopieren

   scp YOUR-USER@YOUR-SERVER-IP:/path/printed/by/the/script.tar.gz .

   Wenn du dich als anderer Benutzer als root anmeldest, kopierst du das Archiv mit sudo cp in deinen Home-Ordner und übernimmst mit sudo chown den Besitz daran, bevor du es herunterlädst.

   Das Skript schreibt sein Archiv auf dieselbe Festplatte wie Uptime Kuma. Mit dieser Kopie kommst du nach einem missglückten Update zurück, aber sie hilft dir nicht, wenn du den Server verlierst. Lass sie deshalb nicht dort liegen.

3. Neue Versionen im Blick behalten

   Debian spielt Patches im Hintergrund selbst ein. Der Container von Uptime Kuma aktualisiert sich nicht selbst, daher wartet jedes neue Release, bis du die beiden Update-Befehle erneut ausführst. Folge den Releases von Uptime Kuma über das Watch-Menü des Repositorys auf GitHub und aktualisiere auf das neueste Release, sobald eines erscheint.

Häufige Fragen zum Hosting von Uptime Kuma