ntfy mit Docker Compose: Eigene Push-Nachrichten lokal in Minuten starten

Wenn Skripte, Backups, Cronjobs oder kleine Home-Server nur in Logdateien vor sich hin arbeiten, merkt man Fehler oft erst zu spaet. ntfy loest genau dieses Problem mit sehr wenig Reibung: ein kleiner HTTP-basierter Benachrichtigungsserver, den du selbst hosten und direkt per curl fuettern kannst.

Die Quellenlage ist fuer 3. Juni 2026 sauber genug, um daraus einen belastbaren Fallback zu bauen. Die offizielle Installationsdoku zeigt Docker samt optionalem Compose-Healthcheck, die Konfigurationsdoku dokumentiert den Health-Endpunkt /v1/health, und die offiziellen Release-Notes fuehren ntfy server v2.23.0 vom 17. Mai 2026 als aktuellen stabilen Stand. Genau deshalb pinne ich hier bewusst auf binwiederhier/ntfy:v2.23.0 statt auf latest.

Lokal erzeugtes Artikelbild fuer ntfy mit Docker Compose

Was du am Ende hast

ntfy lokal unter http://127.0.0.1:8085
Einen kleinen Compose-Stack mit persistentem Nachrichten-Cache
Einen echten Funktionstest mit Browser und curl
Einen Healthcheck, den Docker selbst auswerten kann

Voraussetzungen

Docker Engine und docker compose sind installiert
Port 8085 ist lokal frei
Du startest in einem neuen Projektordner statt in einem bestehenden Compose-Verzeichnis

1. Arbeitsordner anlegen

Erst der dedizierte Ordner, dann der Dienst:

mkdir ntfy-lab && cd ntfy-lab
mkdir -p cache

2. Compose-Datei erstellen

Die offizielle ntfy-Doku ist hier angenehm direkt: Die Docker-Variante liefert Web-UI und API auf Port 80, der persistente Nachrichten-Cache liegt unter /var/cache/ntfy, und ein Healthcheck gegen /v1/health ist ausdruecklich vorgesehen. Wichtig ist auch ein kleines Detail aus der Installationsseite: Das Image bringt kein fertiges /etc/ntfy/server.yml mit. Fuer einen schnellen lokalen Start sind Kommandozeilen-Flags deshalb der sauberste Weg.

ntfy-lab/compose.yaml:

services:
  ntfy:
    image: binwiederhier/ntfy:v2.23.0
    container_name: ntfy
    command:
      - serve
      - --cache-file
      - /var/cache/ntfy/cache.db
    environment:
      TZ: Europe/Berlin
    volumes:
      - ./cache:/var/cache/ntfy
    ports:
      - "127.0.0.1:8085:80"
    healthcheck:
      test: ["CMD-SHELL", "wget -q --tries=1 http://localhost:80/v1/health -O - | grep -Eo '\"healthy\"\\s*:\\s*true' || exit 1"]
      interval: 60s
      timeout: 10s
      retries: 3
      start_period: 40s
    restart: unless-stopped
    init: true

Warum diese Form sinnvoll ist:

binwiederhier/ntfy:v2.23.0 macht das Setup reproduzierbar
./cache:/var/cache/ntfy haelt den SQLite-Cache persistent
127.0.0.1:8085:80 bindet den Dienst bewusst nur lokal
init: true ist laut offizieller Compose-Empfehlung sinnvoll, wenn der Healthcheck aktiv ist

ntfy ist standardmaessig offen: Ohne weitere Auth-Konfiguration darf grundsaetzlich jeder Topics lesen und beschreiben. Fuer einen lokalen Start auf 127.0.0.1 ist das okay. Sobald du den Dienst ueber Heimnetz, Reverse Proxy oder oeffentliche Domain freigibst, musst du Auth und Zugriffskontrolle nachziehen.

3. Stack starten

Jetzt ziehst du das gepinnte Image und startest den Container:

docker compose pull
docker compose up -d

Danach sollte ntfy hier antworten:

http://127.0.0.1:8085

4. Laufenden Dienst pruefen

Bevor du den ersten Topic-Test machst, pruefe Status, Logs und Health-Endpunkt:

docker compose ps
docker compose logs --tail=100 ntfy
curl http://127.0.0.1:8085/v1/health

Wenn alles sauber steht, zeigt docker compose ps einen laufenden Container und curl liefert eine JSON-Antwort wie:

{"healthy":true}

Genau hier ist das Setup technisch schon brauchbar: Der Dienst laeuft, antwortet ueber HTTP und meldet sich selbst als gesund.

5. Erste echte Nachricht sichtbar machen

Der eigentliche Nutzwert von ntfy zeigt sich erst mit einer Nachricht. Oeffne im Browser diese Topic-Seite:

http://127.0.0.1:8085/homelab-demo

Dann sende aus einem zweiten Terminal eine Nachricht an genau dieses Topic:

curl \
  -H "Title: Compose-Test" \
  -d "ntfy laeuft lokal und nimmt Nachrichten an." \
  http://127.0.0.1:8085/homelab-demo

Wenn die Topic-Seite im Browser offen ist, siehst du sofort, ob der Kern des Projekts funktioniert. Genau das ist der sichtbare Endpunkt, den viele generische Docker-Tutorials schuldig bleiben.

6. Wofuer ntfy im Alltag taugt

ntfy wird stark, sobald du einfache Automatisierung dazu packst:

Backup-Skripte schicken nach Erfolg oder Fehler eine Nachricht
Docker-Jobs melden abgeschlossene Deployments
Cronjobs senden einen Ping, wenn sie wirklich gelaufen sind
kleine Home-Server koennen Warnungen ohne komplettes Monitoring-Monster ausgeben

Die technische Huerde bleibt dabei bewusst niedrig: HTTP rein, Nachricht raus.

7. Was du fuer eine private oder externe Instanz spaeter brauchst

Die Konfigurationsdoku ist hier klar: Standardmaessig ist auth-default-access auf read-write, also offen. Wenn du aus dem lokalen Test eine private echte Instanz machen willst, sind die naechsten Schritte:

/etc/ntfy/server.yml lokal anlegen und in den Container mounten
auth-default-access: "deny-all" setzen
eine Auth-Datenbank ueber auth-file konfigurieren
danach Benutzer, ACLs oder Tokens sauber verwalten

Fuer diesen Artikel mache ich das bewusst noch nicht auf, weil der lokale Start auf 127.0.0.1 das kleinere und ehrlichere erste Ziel ist.

8. Sinnvolle Befehle fuer den Alltag

Fuer Logs, Updates und Stoppen brauchst du zunaechst nur diese Kommandos:

docker compose logs -f ntfy
docker compose pull
docker compose up -d
docker compose down

Der Cache bleibt im Verzeichnis ntfy-lab/cache erhalten.

Fazit

Wenn aktuelle News in diesem Lauf nicht sauber genug belegbar oder zu nah an bestehenden Themen sind, muss der Ersatz ein reales Problem loesen. Genau das schafft ntfy: ein kleiner Compose-Stack, ein sichtbarer Browser-Test, direkte Nutzbarkeit per curl und genug Substanz, um spaeter echte Alarm- oder Automatisierungswege daraus zu bauen.

Als Fallback am 3. Juni 2026 ist das deutlich brauchbarer als noch ein abstrakter Docker-Grundlagenpost ohne Endergebnis.

User Dashboard