Uptime Kuma und Beszel auf einem VPS mit Docker Compose selbst hosten
Uptime Kuma für externes Verfügbarkeitsmonitoring und Beszel für Server-Metriken auf einem einzelnen VPS bereitstellen. Docker-Compose-Setup mit Benachrichtigungen, Alarmen, Statusseiten und Sicherheitshärtung.
Ihre App ist deployed. Nutzer melden sich an. Aber Sie haben keine Ahnung, ob sie um 3 Uhr nachts ausfällt oder ob die Festplatte vollläuft, während Sie schlafen.
Diese Anleitung stellt zwei Monitoring-Tools auf einem einzelnen VPS mit Docker Compose bereit:
- Uptime Kuma (84k+ GitHub-Sterne) überwacht die externe Verfügbarkeit: HTTP-Endpoints, TCP-Ports, DNS-Einträge, SSL-Zertifikate.
- Beszel (~20k Sterne) überwacht die interne Servergesundheit: CPU, RAM, Festplatte, Netzwerk und Docker-Statistiken pro Container.
Zusammen benötigen sie etwa 150–180 MB RAM. Ein Prometheus + Grafana + node_exporter-Stack für dieselbe Aufgabe braucht 800+ MB.
Voraussetzungen: Ein VPS mit Debian 12 oder Ubuntu 24.04, auf dem Docker und Docker Compose installiert sind. Ein Reverse Proxy (Caddy oder Nginx) für TLS. Ein Domainname mit DNS-Eintrag, der auf Ihren Server zeigt. Diese Anleitung verwendet Caddy für die Reverse-Proxy-Beispiele. Docker in Produktion auf einem VPS: Was schiefgeht und wie Sie es beheben
Was ist der Unterschied zwischen Uptime Kuma und Beszel?
Uptime Kuma überwacht die externe Verfügbarkeit. Es sagt Ihnen, ob Ihre Websites, APIs und Dienste von außerhalb Ihres Servers erreichbar sind. Beszel überwacht die interne Servergesundheit: CPU-Auslastung, RAM, Festplattenplatz, Netzwerkbandbreite und Docker-Statistiken pro Container. Ein Webserver kann niedrige CPU-Auslastung und reichlich freien Speicher anzeigen und dennoch komplett unerreichbar sein – wegen einer falsch konfigurierten Firewall oder eines abgelaufenen TLS-Zertifikats. Sie brauchen beide Tools.
| Funktion | Uptime Kuma | Beszel |
|---|---|---|
| Was es überwacht | HTTP, TCP, DNS, Ping, SSL-Ablauf, Push/Heartbeat | CPU, RAM, Festplatte, Netzwerk, Temperatur, Docker-Container |
| Architektur | Einzelner Container, Web-UI | Hub + Agent (ein Agent pro überwachtem Server) |
| Datenbank | SQLite (Standard) oder MariaDB | PocketBase (eingebettetes SQLite) |
| Benachrichtigungskanäle | 90+ (E-Mail, Telegram, Discord, Slack, Webhooks usw.) | E-Mail (SMTP über PocketBase) |
| Statusseiten | Ja, öffentlich mit eigener Domain | Nein |
| RAM-Verbrauch | ~80–120 MB | Hub: ~10–50 MB, Agent: ~25 MB |
| GitHub-Sterne | 84k+ | ~20k |
Keines der beiden Tools ersetzt das andere. Uptime Kuma erkennt externe Ausfälle. Beszel erkennt Ressourcenerschöpfung, bevor sie externe Ausfälle verursacht.
Wie viel RAM verbraucht der Monitoring-Stack?
Uptime Kuma v2.x benötigt je nach Anzahl der Monitore etwa 80–120 MB RAM. Der Beszel-Hub fügt 10–50 MB hinzu, und jeder Agent verbraucht etwa 25 MB. Der kombinierte Stack läuft problemlos auf einem 1-GB-VPS mit etwa 150–180 MB Gesamtverbrauch. Zum Vergleich: Prometheus + Grafana + node_exporter zusammen brauchen 800+ MB allein im Leerlauf.
| Stack | RAM im Leerlauf | Einrichtungszeit | Geeignet für |
|---|---|---|---|
| Uptime Kuma + Beszel | ~150–180 MB | 30 Minuten | Kleine bis mittlere Self-Hosting-Setups |
| Prometheus + Grafana + node_exporter | ~800 MB+ | 2–4 Stunden | Große Infrastrukturen mit individuellen Abfragen |
| Netdata | ~300–400 MB | 15 Minuten | Echtzeitmetriken, einzelner Server |
Wie installiere ich Uptime Kuma mit Docker Compose?
Uptime Kuma läuft als einzelner Container und stellt seine Web-UI auf Port 3001 bereit. Die folgende Compose-Datei pinnt auf den Major-Version-Tag 2, bindet nur an localhost, setzt Ressourcenlimits und fügt einen Health Check hinzu.
Erstellen Sie das Projektverzeichnis:
mkdir -p /opt/uptime-kuma && cd /opt/uptime-kuma
Erstellen Sie die Compose-Datei:
# /opt/uptime-kuma/compose.yaml
services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: unless-stopped
ports:
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
environment:
- TZ=Europe/Berlin
deploy:
resources:
limits:
memory: 256m
cpus: "0.5"
healthcheck:
test: ["CMD", "node", "/app/extra/healthcheck.js"]
interval: 30s
timeout: 10s
retries: 3
start_period: 15s
Das Binding 127.0.0.1:3001:3001 stellt sicher, dass der Container nur auf localhost lauscht. Ohne das Präfix 127.0.0.1 veröffentlicht Docker den Port auf allen Interfaces und umgeht damit Ihre Firewall. Docker umgeht UFW: 4 getestete Lösungen für Ihren VPS
Starten Sie den Container:
docker compose up -d
[+] Running 1/1
✔ Container uptime-kuma Started
docker compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
uptime-kuma louislam/uptime-kuma:2 "/usr/bin/dumb-init …" uptime-kuma 10 seconds ago Up 9 seconds (healthy) 127.0.0.1:3001->3001/tcp
Der Status (healthy) bedeutet, dass der eingebaute Health Check bestanden wurde. Wenn Sie (starting) sehen, warten Sie 15 Sekunden, bis die start_period abgelaufen ist.
Reverse Proxy mit Caddy
Fügen Sie einen Eintrag zu Ihrem Caddyfile hinzu:
# /etc/caddy/Caddyfile (append)
status.example.com {
reverse_proxy localhost:3001
}
Laden Sie Caddy neu:
systemctl reload caddy
Caddy bezieht automatisch ein TLS-Zertifikat von Let's Encrypt. Öffnen Sie https://status.example.com in Ihrem Browser. Uptime Kuma fordert Sie beim ersten Zugriff auf, ein Administratorkonto zu erstellen.
2FA sofort aktivieren
Nachdem Sie Ihr Administratorkonto erstellt haben, gehen Sie zu Settings > Security > Two-Factor Authentication und aktivieren Sie es. Das Uptime-Kuma-Dashboard gibt Lesezugriff auf die gesamte Topologie Ihrer Infrastruktur. Jeder, der den Login kompromittiert, sieht jeden überwachten Endpoint. Richten Sie 2FA ein, bevor Sie Monitore hinzufügen.
Wie richte ich Beszel zur Überwachung meines VPS ein?
Beszel verwendet eine Hub-Agent-Architektur. Der Hub ist das Web-Dashboard, das Daten speichert und Metriken anzeigt. Der Agent läuft auf jedem Server, den Sie überwachen möchten, und streamt Metriken zurück an den Hub. Wenn beide auf demselben VPS laufen, kommunizieren sie über einen Unix-Socket statt über das Netzwerk.
Erstellen Sie das Projektverzeichnis:
mkdir -p /opt/beszel && cd /opt/beszel
Erstellen Sie die Compose-Datei:
# /opt/beszel/compose.yaml
services:
beszel-hub:
image: henrygd/beszel:0.18
container_name: beszel-hub
restart: unless-stopped
ports:
- "127.0.0.1:8090:8090"
environment:
- APP_URL=https://beszel.example.com
volumes:
- ./beszel_data:/beszel_data
- ./beszel_socket:/beszel_socket
deploy:
resources:
limits:
memory: 128m
cpus: "0.25"
beszel-agent:
image: henrygd/beszel-agent:0.18
container_name: beszel-agent
restart: unless-stopped
network_mode: host
volumes:
- ./beszel_agent_data:/var/lib/beszel-agent
- ./beszel_socket:/beszel_socket
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- LISTEN=/beszel_socket/beszel.sock
- KEY=${BESZEL_KEY}
deploy:
resources:
limits:
memory: 64m
cpus: "0.15"
Zu dieser Konfiguration:
- Das Hub-Image ist auf
0.18gepinnt, das den Fix für CVE-2026-27734 (v0.18.4) enthält. Das Pinnen auf eine Minor-Version verhindert unerwartete Breaking Changes, während Patch-Updates weiterhin empfangen werden. - Der Agent verwendet
network_mode: host, um die Netzwerk-Interface-Statistiken des Hosts lesen zu können. Dies ist für akkurates Bandbreitenmonitoring erforderlich. - Agent und Hub teilen sich ein
beszel_socket-Volume für die Unix-Socket-Kommunikation. Das vermeidet es, Port 45876 im Netzwerk freizugeben, wenn beide auf demselben Server laufen. - Der Docker-Socket wird schreibgeschützt (
:ro) eingebunden. Mehr dazu im Sicherheitsabschnitt unten.
Docker-Socket-Sicherheit
Das Einbinden von /var/run/docker.sock gibt dem Agent Zugriff auf die Docker-API. Selbst mit :ro ist dies effektiv ein Root-äquivalenter Zugriff, da die Docker-API privilegierte Container erstellen, Umgebungsvariablen aus beliebigen Containern lesen und auf Volumes zugreifen kann. Docker-Sicherheit härten: Rootless-Modus, Seccomp, AppArmor auf einem VPS
Beszel benötigt den Socket, um CPU-, Speicher- und Netzwerkstatistiken pro Container zu sammeln. Wenn Sie kein Container-Monitoring benötigen, entfernen Sie das Docker-Socket-Mount vollständig.
CVE-2026-27734 (behoben in v0.18.4) demonstrierte dieses Risiko: Ein authentifizierter Beszel-Benutzer konnte die Docker-API über nicht bereinigte Container-IDs traversieren und beliebige Endpoints wie /version oder /containers/json erreichen. Der Fix bereinigt alle Benutzereingaben, bevor Docker-API-URLs konstruiert werden. Stellen Sie sicher, dass Sie v0.18.4 oder neuer ausführen. Der Tag 0.18 in der obigen Compose-Datei löst sich zu v0.18.4 auf (neuester Patch, Stand März 2026).
Agent-Schlüssel generieren
Starten Sie zuerst den Hub:
cd /opt/beszel
docker compose up -d beszel-hub
Öffnen Sie den Hub unter https://beszel.example.com (nachdem Sie Ihren Reverse Proxy konfiguriert haben, nächster Abschnitt). Erstellen Sie ein Administratorkonto. Gehen Sie zu Add System im Dashboard. Der Hub zeigt einen öffentlichen Schlüssel an. Kopieren Sie ihn.
Erstellen Sie eine .env-Datei für den Agent:
# /opt/beszel/.env
BESZEL_KEY="ssh-ed25519 AAAA... (paste the key from the hub UI)"
chmod 600 /opt/beszel/.env
Starten Sie nun den Agent:
docker compose up -d beszel-agent
Zurück in der Hub-UI fügen Sie das System mit dem Socket-Pfad /beszel_socket/beszel.sock hinzu. Innerhalb von Sekunden erscheinen CPU-, RAM-, Festplatten- und Docker-Container-Metriken.
Reverse Proxy für Beszel
Fügen Sie Folgendes zu Ihrem Caddyfile hinzu:
# /etc/caddy/Caddyfile (append)
beszel.example.com {
reverse_proxy localhost:8090
}
systemctl reload caddy
Wie konfiguriere ich Benachrichtigungen in Uptime Kuma?
Uptime Kuma unterstützt über 90 Benachrichtigungskanäle. Die drei häufigsten für Self-Hoster sind E-Mail (SMTP), Telegram und Discord.
SMTP-E-Mail-Benachrichtigungen
Gehen Sie zu Settings > Notifications > Setup Notification. Wählen Sie Email (SMTP) als Typ.
| Feld | Wert |
|---|---|
| Hostname | Ihr SMTP-Server (z. B. smtp.example.com) |
| Port | 587 (STARTTLS) oder 465 (implizites TLS) |
| Security | STARTTLS oder TLS |
| Username | Ihr SMTP-Benutzername |
| Password | Ihr SMTP-Passwort |
| From Email | monitoring@example.com |
| To Email | sie@example.com |
Klicken Sie auf Test, um vor dem Speichern eine Testbenachrichtigung zu senden. Uptime Kuma sendet den Test sofort. Bei einem Fehler prüfen Sie Ihre SMTP-Zugangsdaten und Firewall-Regeln (Port 587 ausgehend muss offen sein).
Telegram-Bot-Benachrichtigungen
- Schreiben Sie @BotFather auf Telegram eine Nachricht und erstellen Sie einen neuen Bot mit
/newbot. - Kopieren Sie den Bot-Token (Format:
123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11). - Starten Sie einen Chat mit Ihrem Bot und senden Sie eine beliebige Nachricht.
- Ermitteln Sie Ihre Chat-ID: Öffnen Sie
https://api.telegram.org/bot<YOUR_TOKEN>/getUpdatesin Ihrem Browser. Das Feldchat.idin der Antwort ist Ihre Chat-ID. - Fügen Sie in Uptime Kuma eine Telegram-Benachrichtigung hinzu. Fügen Sie den Bot-Token und die Chat-ID ein. Klicken Sie auf Test.
Discord-Webhook-Benachrichtigungen
- Gehen Sie in Ihrem Discord-Server zu Server Settings > Integrations > Webhooks > New Webhook.
- Benennen Sie ihn (z. B. „Uptime Kuma"), wählen Sie einen Kanal und kopieren Sie die Webhook-URL.
- Fügen Sie in Uptime Kuma eine Discord-Benachrichtigung hinzu und fügen Sie die Webhook-URL ein. Klicken Sie auf Test.
Setzen Sie die Standardbenachrichtigung so, dass sie für alle neuen Monitore gilt, indem Sie Default Enabled aktivieren. So erbt jeder erstellte Monitor den Benachrichtigungskanal ohne manuelle Konfiguration.
Welche Uptime-Kuma-Monitortypen sollte ich einrichten?
Uptime Kuma unterstützt viele Monitortypen. Hier sind die vier nützlichsten für einen selbst gehosteten Stack:
- HTTP(s) – Prüft eine URL, optional mit Keyword-Abgleich im Antworttext. Verwenden Sie es für Web-Apps, APIs und Dashboards. Setzen Sie das Keyword auf einen String, der nur erscheint, wenn die App gesund ist (z. B. Ihr App-Name im HTML-Titel).
- TCP – Verbindet sich mit einem Host:Port. Verwenden Sie es für Datenbanken (PostgreSQL auf 5432), Mailserver (SMTP auf 587) oder jeden Dienst ohne HTTP-Endpoint.
- DNS – Löst einen Hostnamen auf und prüft, ob das Ergebnis einer erwarteten IP entspricht. Erkennt DNS-Hijacking oder falsch konfigurierte Einträge.
- Push / Heartbeat – Uptime Kuma generiert eine URL. Ihr Cronjob oder Backup-Skript ruft sie bei Erfolg auf. Wird die URL nicht innerhalb des Intervalls aufgerufen, löst Uptime Kuma einen Alarm aus. Dies ist die einzige Möglichkeit, Skripte zu überwachen, die keinen lauschenden Port haben.
Push-Monitor-Beispiel für Cronjobs
Erstellen Sie einen Push-Monitor in Uptime Kuma. Setzen Sie das Heartbeat-Intervall auf Ihre Cron-Frequenz plus eine Karenzzeit. Kopieren Sie die Push-URL.
Fügen Sie den curl-Aufruf am Ende Ihres Backup-Skripts hinzu:
#!/bin/bash
# /opt/scripts/backup.sh
pg_dump mydb | gzip > /backups/mydb-$(date +%F).sql.gz
# Signal success to Uptime Kuma
curl -fsS -o /dev/null "https://status.example.com/api/push/abc123?status=up&msg=backup-ok"
Wenn das Skript vor der curl-Zeile fehlschlägt oder Cron nicht ausführt, markiert Uptime Kuma den Monitor nach Ablauf des Intervalls als down.
Wie richte ich Beszel-Alarme für CPU und Festplatte ein?
Beszel-Alarme benachrichtigen Sie, wenn Server-Metriken einen Schwellenwert überschreiten. Klicken Sie auf das Glockensymbol neben einem System im Dashboard, um Alarme zu konfigurieren.
Empfohlene Schwellenwerte für einen kleinen VPS (2–4 vCPU, 4–8 GB RAM):
| Metrik | Warnung | Kritisch | Warum |
|---|---|---|---|
| CPU | > 70 % für 5 Min. | > 90 % für 2 Min. | Anhaltend hohe CPU bedeutet außer Kontrolle geratene Prozesse oder eine unterdimensionierte Instanz |
| RAM | > 80 % für 5 Min. | > 90 % für 2 Min. | Linux beginnt ab 85 % stark zu swappen und zerstört die Performance |
| Festplatte | > 80 % | > 90 % | Docker-Images, Logs und Datenbanken wachsen unbemerkt. Bei 100 % stürzen Dienste ab |
| Bandbreite | > 80 % des Planlimits | > 95 % | Verhindert Zusatzkosten oder Drosselung |
Diese Schwellenwerte sind absichtlich niedriger als Enterprise-Standards. Auf einem kleinen VPS haben Sie weniger Spielraum. Ein Anstieg von 70 % auf 100 % CPU dauert Sekunden, nicht Minuten.
SMTP für Beszel-Alarme konfigurieren
Beszel verwendet PocketBase als Backend. SMTP wird über das PocketBase-Admin-Panel konfiguriert:
- Gehen Sie zu
https://beszel.example.com/_/(die PocketBase-Admin-URL, beachten Sie den Unterstrich). - Melden Sie sich mit den Administratorzugangsdaten an, die Sie bei der Einrichtung erstellt haben.
- Gehen Sie zu Settings > Mail settings.
- Aktivieren Sie Use SMTP mail server.
- Geben Sie Ihren SMTP-Host, Port, Benutzernamen und Passwort ein.
- Setzen Sie die Absenderadresse.
- Klicken Sie auf Save und Send test email.
Wie erstelle ich eine öffentliche Statusseite mit Uptime Kuma?
Uptime Kuma kann öffentliche Statusseiten bereitstellen, die die Verfügbarkeit Ihrer Dienste anzeigen. Diese sind nützlich, um Nutzern die Uptime zu kommunizieren, ohne Ihr Monitoring-Dashboard freizugeben.
- Gehen Sie zu Status Pages in der linken Seitenleiste.
- Klicken Sie auf New Status Page. Wählen Sie einen Namen und Slug (z. B.
status). - Fügen Sie Gruppen hinzu (z. B. „Webdienste", „APIs", „Infrastruktur").
- Ziehen Sie Monitore in jede Gruppe.
- Veröffentlichen Sie die Seite. Sie ist erreichbar unter
https://status.example.com/status/<slug>.
Eigene Domain für die Statusseite
Wenn Sie möchten, dass https://status.example.com die Statusseite direkt anzeigt, setzen Sie die Statusseite als Standard in den Uptime-Kuma-Einstellungen. Der Wurzelpfad zeigt dann die öffentliche Seite, während das Dashboard unter /dashboard bleibt.
Statusseiten erfordern keine Authentifizierung. Fügen Sie keine Monitore in eine Statusseiten-Gruppe ein, wenn das Offenlegen der Existenz des Endpoints ein Sicherheitsrisiko darstellt.
Incident-Management
Wenn ein Dienst ausfällt, zeigt Uptime Kuma ihn automatisch als beeinträchtigt auf der Statusseite an. Sie können auch manuelle Incidents erstellen:
- Gehen Sie zu Status Pages, wählen Sie Ihre Seite und klicken Sie auf Create Incident.
- Schreiben Sie einen Titel und eine Beschreibung (z. B. „Datenbankwartung, geschätzte Dauer 15 Minuten").
- Setzen Sie den Stil auf info, warning, danger oder primary.
- Veröffentlichen Sie. Das Incident-Banner erscheint oben auf der öffentlichen Statusseite.
Lösen Sie den Incident auf, wenn er behoben ist. Uptime Kuma speichert eine Historie vergangener Incidents, sodass Ihre Nutzer Ihre Betriebsbilanz einsehen können.
Wie überwache ich meinen Monitoring-Stack von außen?
Wenn Ihr VPS ausfällt, fallen Uptime Kuma und Beszel mit ihm aus. Sie erfahren vom Ausfall zur gleichen Zeit wie Ihre Nutzer. Die Lösung: Ein externer Watchdog, der Ihre Uptime-Kuma-Instanz von einem anderen Standort aus überwacht.
Option 1: UptimeRobot (kostenlose Stufe)
- Erstellen Sie ein kostenloses Konto bei UptimeRobot.
- Fügen Sie einen neuen Monitor hinzu: Typ HTTP(s), URL
https://status.example.com/api/status-page/heartbeat/<slug>. - Setzen Sie das Prüfintervall auf 5 Minuten.
- Konfigurieren Sie E-Mail- oder Telegram-Benachrichtigungen.
Der Endpoint /api/status-page/heartbeat/<slug> gibt ein JSON-Payload mit dem Status zurück. UptimeRobot prüft ihn und alarmiert Sie, wenn Ihre Uptime-Kuma-Instanz unerreichbar wird.
Option 2: Healthchecks.io (kostenlose Stufe)
Healthchecks.io arbeitet mit dem Push-Modell. Erstellen Sie einen Check, kopieren Sie die Ping-URL und fügen Sie einen Cronjob auf Ihrem VPS hinzu:
# /etc/cron.d/monitoring-heartbeat
*/5 * * * * root curl -fsS --retry 3 -o /dev/null https://hc-ping.com/your-uuid-here
Wenn der Cron-Ping ausbleibt (weil Ihr Server down ist), sendet Healthchecks.io Ihnen einen Alarm. Das deckt das Szenario ab, in dem Ihr gesamter VPS unerreichbar wird.
Option 3: Von einem zweiten VPS aus überwachen
Wenn Sie mehrere Server betreiben, installieren Sie Uptime Kuma auf einem anderen VPS und lassen Sie jede Instanz die andere überwachen. Das ist der zuverlässigste Ansatz, da Sie beide Endpoints kontrollieren und keine Abhängigkeit von einem kostenlosen Drittanbieterdienst besteht.
Sicherheitshärtung
Firewall-Regeln
Wenn Sie den Beszel-Agent im Standalone-Modus auf einem entfernten Server betreiben (ohne die Unix-Socket-Methode), lauscht er auf Port 45876. Nur der Hub muss diesen Port erreichen:
ufw allow from <hub-ip-address> to any port 45876 proto tcp comment "Beszel agent"
ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 80/tcp ALLOW IN Anywhere
[ 3] 443/tcp ALLOW IN Anywhere
[ 4] 45876/tcp ALLOW IN <hub-ip-address>
Öffnen Sie Port 45876 nicht für die ganze Welt. Der Agent gibt Systemmetriken ohne Authentifizierung auf diesem Port preis. Er verlässt sich auf den SSH-Schlüssel des Hubs zur Verifizierung, aber eine Einschränkung auf Netzwerkebene bietet zusätzliche Tiefenverteidigung.
Für das Single-VPS-Setup in dieser Anleitung wird Port 45876 überhaupt nicht benötigt, da Hub und Agent über einen Unix-Socket kommunizieren.
Uptime Kuma: Passwort-Authentifizierung für API deaktivieren
Wenn Sie Uptime Kuma nur über die Web-UI nutzen, deaktivieren Sie den API-Zugriff über Settings > Security > API Key. Weniger exponierte Endpoints, weniger zu patchen.
Versionsinformationen verbergen
Uptime Kuma und Beszel zeigen beide standardmäßig Versionsinformationen in ihrer Web-UI an. Ihr Reverse Proxy sollte das nicht verschlimmern. In Ihrem Caddyfile lässt Caddy Server-Header bereits standardmäßig weg. Wenn Sie stattdessen Nginx verwenden:
server_tokens off;
Die Offenlegung von Versionsinformationen hilft Angreifern, bekannte Schwachstellen gezielt auszunutzen. Halten Sie sie minimal.
Wie sichere ich Uptime-Kuma- und Beszel-Daten?
Beide Tools verwenden SQLite-basierte Datenbanken. SQLite-Dateien können nicht sicher kopiert werden, während die Anwendung darauf schreibt. Verwenden Sie die richtigen Backup-Methoden.
Uptime-Kuma-Backup
Uptime Kuma speichert alles in /app/data (gemappt auf ./data in der Compose-Datei). Das eingebaute Backup exportiert eine JSON-Datei:
- Gehen Sie zu Settings > Backup.
- Klicken Sie auf Export. Speichern Sie die JSON-Datei außerhalb des Servers.
Für automatisierte Backups stoppen Sie den Container kurz oder verwenden Sie SQLites Online-Backup:
sqlite3 /opt/uptime-kuma/data/kuma.db ".backup '/opt/backups/kuma-$(date +%F).db'"
Beszel-Backup
Beszel verwendet PocketBase. Sichern Sie das Datenverzeichnis:
sqlite3 /opt/beszel/beszel_data/data.db ".backup '/opt/backups/beszel-$(date +%F).db'"
Speichern Sie Backups außerhalb des Servers. Ein Monitoring-Stack, der seine Historie verliert, wenn die Festplatte stirbt, überwacht gar nichts. Docker-Volumes auf einem VPS sichern und wiederherstellen
Wie aktualisiere ich Uptime Kuma und Beszel sicher?
Pinnen Sie auf die Minor-Version, nicht auf latest. Das verhindert, dass Breaking Changes ohne Ihr Wissen eintreffen.
# Update Uptime Kuma
cd /opt/uptime-kuma
docker compose pull
docker compose up -d
[+] Pulling 1/1
✔ uptime-kuma Pulled
[+] Running 1/1
✔ Container uptime-kuma Started
docker compose ps
Prüfen Sie, ob die Spalte STATUS den Wert (healthy) anzeigt. Wenn die neue Version Probleme verursacht, pinnen Sie die vorherige Version in compose.yaml und erstellen Sie den Container neu:
# In compose.yaml, change the image tag to the previous version:
# image: louislam/uptime-kuma:2.2.1
docker compose up -d
Derselbe Prozess gilt für Beszel. Erstellen Sie immer ein Backup, bevor Sie aktualisieren.
Image-Pinning-Strategie
Der Tag louislam/uptime-kuma:2 verfolgt das neueste 2.x-Release. Das ist bequem, bedeutet aber, dass docker compose pull ohne Vorwarnung von 2.2.1 auf 2.3.0 springen kann. Für Produktionsumgebungen pinnen Sie auf eine spezifische Minor-Version:
image: louislam/uptime-kuma:2.2
Prüfen Sie die Release Notes vor dem Pull. Uptime Kuma veröffentlicht Releases auf GitHub. Beszel ebenso auf ihrer Releases-Seite.
Abonnieren Sie die Release-Benachrichtigungen beider Repositories (Watch > Custom > Releases auf GitHub), damit Sie wissen, wann Sicherheitspatches erscheinen.
Docker Compose Ressourcenlimits, Healthchecks und Neustartrichtlinien
Fehlerbehebung
Uptime Kuma zeigt (unhealthy) in docker compose ps:
docker compose logs uptime-kuma --tail 50
Häufige Ursachen: Korrupte SQLite-Datenbank (aus Backup wiederherstellen), Port-Konflikt (ein anderer Dienst auf 3001) oder unzureichender Speicher (Ressourcenlimit erhöhen).
Beszel-Agent verbindet sich nicht mit dem Hub:
docker compose logs beszel-agent --tail 50
Prüfen Sie, ob der KEY in .env mit dem Schlüssel übereinstimmt, der im Add-System-Dialog des Hubs angezeigt wird. Wenn Sie Unix-Sockets verwenden, überprüfen Sie, ob der Pfad des gemeinsamen Volume-Mounts bei beiden Diensten übereinstimmt.
Beszel zeigt keine Docker-Container-Statistiken:
Das Docker-Socket-Mount fehlt oder der Docker-Socket-Pfad ist falsch. Prüfen Sie:
ls -la /var/run/docker.sock
srw-rw---- 1 root docker 0 Mar 20 10:00 /var/run/docker.sock
Der Socket muss existieren und der Container muss Lesezugriff haben. Das :ro-Mount in der Compose-Datei regelt dies.
Benachrichtigungen kommen nicht an:
Für SMTP: Prüfen Sie, ob Port 587 (oder 465) ausgehend nicht von Ihrem Hosting-Anbieter blockiert wird. Manche Anbieter blockieren ausgehenden SMTP-Verkehr standardmäßig. Testen Sie mit:
nc -zv smtp.example.com 587
Connection to smtp.example.com 587 port [tcp/submission] succeeded!
Für Telegram: Überprüfen Sie den Bot-Token und die Chat-ID. Die Chat-ID muss eine Zahl sein, nicht der Bot-Benutzername.
Hoher Speicherverbrauch:
Die Anzahl der Monitore zählt. Uptime Kuma v2.x verbraucht etwa 100 MB im Leerlauf. Jeder HTTP-Monitor fügt Verbindungszustand hinzu. Wenn Sie bei einem Speicherlimit von 256 MB über 100 Monitore hinausgehen, erhöhen Sie das Limit oder verteilen Sie auf mehrere Instanzen.
Prüfen Sie den tatsächlichen Verbrauch:
docker stats --no-stream uptime-kuma beszel-hub beszel-agent
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
abc123 uptime-kuma 0.15% 99MiB / 256MiB 38.67% 1.2kB / 2kB 0B / 0B 8
def456 beszel-hub 0.08% 10MiB / 128MiB 7.81% 1kB / 1.5kB 0B / 745kB 8
ghi789 beszel-agent 0.05% 22MiB / 64MiB 34.38% 0B / 0B 0B / 0B 5
Docker-Logrotation: Verhindern Sie, dass Logs Ihre VPS-Festplatte füllen
Bereit, es selbst auszuprobieren?
Stellen Sie Ihren Monitoring-Stack auf einem Virtua Cloud VPS bereit. →