Uptime Kuma + ntfy: Push-Notifications fürs Homelab ohne Cloud

Wenn im Homelab etwas ausfällt, merke ich es meistens erst, wenn der Film nicht startet oder die Familie fragt, warum Home Assistant nicht geht. Ich wollte, dass mein Phone vorher Bescheid gibt, und zwar ohne dass meine Server-Daten bei einem Cloud-Dienst landen. Bei mir überwacht deshalb Uptime Kuma alle Dienste, und ntfy schickt die Push-Notification. Beides läuft selbst gehostet und kostet nichts.

Das Setup unten läuft bei mir über zwei Standorte (Berlin und Frankreich) mit mehreren Proxmox-Servern. Am Ende stehen die drei Pitfalls, die mich am meisten Zeit gekostet haben.

Was du brauchst

• Einen kleinen Linux-Container oder eine VM mit Docker (1 vCPU und 1 GB RAM reichen locker, bei mir ist es ein Debian-LXC auf Proxmox)
• Optional: einen Reverse Proxy (Caddy, Nginx Proxy Manager, Traefik) für HTTPS
• Die ntfy-App fürs Phone (iOS und Android, kostenlos)

Schritt 1: Docker Compose

Leg einen Ordner an, z. B. /opt/monitoring, und erstelle darin eine docker-compose.yml:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./kuma:/app/data
    ports:
      - "3001:3001"

  ntfy:
    image: binwiederhier/ntfy
    container_name: ntfy
    command: serve
    restart: unless-stopped
    environment:
      TZ: Europe/Berlin
    volumes:
      - ./ntfy/cache:/var/cache/ntfy
      - ./ntfy/etc:/etc/ntfy
    ports:
      - "8080:80"

Nimm bei Uptime Kuma das Tag :2 statt latest, dann kommt kein Major-Update überraschend rein.

Schritt 2: ntfy absichern

Ohne Konfiguration kann jeder, der deine ntfy-Adresse kennt, an deine Topics schicken oder mitlesen. Deshalb kommt das hier in ntfy/etc/server.yml:

base-url: "https://ntfy.example.de"
behind-proxy: true
auth-file: "/var/cache/ntfy/user.db"
auth-default-access: "deny-all"
cache-file: "/var/cache/ntfy/cache.db"
upstream-base-url: "https://ntfy.sh"

• deny-all sperrt alles, was nicht eingeloggt ist.
• behind-proxy brauchst du, wenn ein Reverse Proxy davor sitzt. Sonst hält ntfy jede Anfrage für eine vom Proxy.
• upstream-base-url ist für iPhones da. Apple stellt sofortige Push-Notifications nur über den eigenen Push-Dienst zu. ntfy.sh reicht dafür einen kurzen Weck-Impuls an Apple weiter, der Inhalt deiner Nachricht bleibt auf deinem Server. Ohne diese Zeile kommen Alerts auf iOS mit viel Verspätung an.

Dann die Container starten und die User anlegen:

docker compose up -d
docker exec -it ntfy ntfy user add --role=admin deinname
docker exec -it ntfy ntfy user add kuma
docker exec -it ntfy ntfy access kuma homelab-alerts write-only
docker exec -it ntfy ntfy token add kuma

Der User kuma darf nur ins Topic homelab-alerts schreiben. Den Token aus dem letzten Befehl brauchst du gleich in Uptime Kuma.

Schritt 3: Uptime Kuma einrichten

Öffne http://<server-ip>:3001. Uptime Kuma 2 fragt beim ersten Start nach der Datenbank. Fürs Homelab reicht SQLite völlig, danach legst du deinen Admin-Account an.

Die Notification legst du unter Einstellungen → Benachrichtigungen → Neu mit dem Typ „ntfy“ an:

• Server-URL: https://ntfy.example.de
• Topic: homelab-alerts
• Authentifizierung: Access Token → Token von oben
• „Standardmäßig für neue Monitore aktivieren“ anhaken

Danach kommen die Monitore. Bei mir sieht das so aus:

Was	Monitor-Typ	Warum
Proxmox-Hosts	HTTP(s) auf Port 8006, Zertifikatsfehler ignorieren	Server tot oder Netzwerk weg
Web-Dienste wie Plex, Home Assistant und Paperless	HTTP(s)	Dienst abgestürzt, Container hängt
Öffentliche Domains	HTTP(s) mit Zertifikatsablauf-Warnung	Abgelaufene Zertifikate fallen sonst erst Besuchern auf
Zweiter Standort	Ping über VPN (Tailscale/WireGuard)	Standort-Verbindung weg

Schritt 4: Die App verbinden

In der ntfy-App tippst du auf „+“, trägst das Topic homelab-alerts ein, wählst „Anderen Server verwenden“ mit https://ntfy.example.de und loggst dich mit deinem Admin-User ein. Zum Testen drückst du in Uptime Kuma bei der Notification auf „Testen“.

Die drei Pitfalls, die mich erwischt haben

1. ntfy liefert 502, und schuld war Tailscale

Mein Monitoring-Container läuft mit Tailscale und --accept-routes, damit er auch den zweiten Standort erreicht. Damit hat Tailscale aber auch eine Route für mein eigenes LAN übernommen. Anfragen vom Reverse Proxy kamen an, die Antworten gingen dann durch den Tunnel raus statt direkt zurück, und der Proxy zeigte 502 Bad Gateway.

Geholfen hat eine Routing-Regel, die das eigene LAN vor die Tailscale-Tabelle stellt:

ip rule add to 192.168.1.0/24 lookup main priority 2500

Das Subnetz musst du an dein LAN anpassen. Damit die Regel einen Reboot überlebt, steckt sie bei mir in einem kleinen systemd-Service, der nach tailscaled startet.

2. Uptime Kuma 2 und Automatisierung

Wenn du Monitore per Script anlegst, zum Beispiel mit der Python-Library uptime-kuma-api, erwartet Kuma 2 bei jedem neuen Monitor ein Feld conditions. Ohne das Feld schlägt das Anlegen fehl, ein mitgeschicktes conditions: "[]" reicht schon.

3. Zu viele False Alarms

Am Anfang hat mein Phone bei jedem kurzen Wackler geklingelt. Seit die Wiederholungen bei allen Monitoren auf 2 bis 3 stehen, kommt der Alert erst, wenn ein Dienst wirklich weg ist.

Bonus: Docker-Updates im Blick mit WUD

Wenn ntfy einmal läuft, kann es auch Updates melden. Auf jedem Docker-Host läuft bei mir What’s Up Docker (WUD) im reinen Benachrichtigungsmodus. Es schickt neue Image-Versionen an ein eigenes ntfy-Topic und aktualisiert selbst nichts, also entscheide ich, wann ein Update eingespielt wird.

Fazit

Das Setup hat mich eine Stunde gekostet und kostet seitdem nichts. Von Outages weiß ich jetzt meistens, bevor jemand fragt.

Fragen oder ein eigenes Setup, das anders läuft? Schreib es in die Kommentare.