Uptime Kuma und Beszel auf einem VPS mit Docker Compose selbst hosten

15 Min. Lesezeit·Matthieu·uptime-kumabeszelmonitoringself-hostingdocker-composedocker|

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.18 gepinnt, 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

  1. Schreiben Sie @BotFather auf Telegram eine Nachricht und erstellen Sie einen neuen Bot mit /newbot.
  2. Kopieren Sie den Bot-Token (Format: 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11).
  3. Starten Sie einen Chat mit Ihrem Bot und senden Sie eine beliebige Nachricht.
  4. Ermitteln Sie Ihre Chat-ID: Öffnen Sie https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates in Ihrem Browser. Das Feld chat.id in der Antwort ist Ihre Chat-ID.
  5. 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

  1. Gehen Sie in Ihrem Discord-Server zu Server Settings > Integrations > Webhooks > New Webhook.
  2. Benennen Sie ihn (z. B. „Uptime Kuma"), wählen Sie einen Kanal und kopieren Sie die Webhook-URL.
  3. 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:

  1. 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).
  2. 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.
  3. DNS – Löst einen Hostnamen auf und prüft, ob das Ergebnis einer erwarteten IP entspricht. Erkennt DNS-Hijacking oder falsch konfigurierte Einträge.
  4. 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:

  1. Gehen Sie zu https://beszel.example.com/_/ (die PocketBase-Admin-URL, beachten Sie den Unterstrich).
  2. Melden Sie sich mit den Administratorzugangsdaten an, die Sie bei der Einrichtung erstellt haben.
  3. Gehen Sie zu Settings > Mail settings.
  4. Aktivieren Sie Use SMTP mail server.
  5. Geben Sie Ihren SMTP-Host, Port, Benutzernamen und Passwort ein.
  6. Setzen Sie die Absenderadresse.
  7. 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.

  1. Gehen Sie zu Status Pages in der linken Seitenleiste.
  2. Klicken Sie auf New Status Page. Wählen Sie einen Namen und Slug (z. B. status).
  3. Fügen Sie Gruppen hinzu (z. B. „Webdienste", „APIs", „Infrastruktur").
  4. Ziehen Sie Monitore in jede Gruppe.
  5. 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:

  1. Gehen Sie zu Status Pages, wählen Sie Ihre Seite und klicken Sie auf Create Incident.
  2. Schreiben Sie einen Titel und eine Beschreibung (z. B. „Datenbankwartung, geschätzte Dauer 15 Minuten").
  3. Setzen Sie den Stil auf info, warning, danger oder primary.
  4. 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)

  1. Erstellen Sie ein kostenloses Konto bei UptimeRobot.
  2. Fügen Sie einen neuen Monitor hinzu: Typ HTTP(s), URL https://status.example.com/api/status-page/heartbeat/<slug>.
  3. Setzen Sie das Prüfintervall auf 5 Minuten.
  4. 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:

  1. Gehen Sie zu Settings > Backup.
  2. 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