ntfy mit Docker Compose: Push-Benachrichtigungen lokal in wenigen Minuten starten

Wenn ein frisches News-Thema heute nicht sauber genug ueber den bereits aktuellen Artikeln im Blog liegt, sollte der Ersatz nicht beliebig sein. ntfy ist als Fallback stark genug, weil das Ergebnis sofort sichtbar wird: eine lokale Weboberflaeche im Browser und ein HTTP-Endpunkt, an den du aus Shell-Skripten, Cronjobs oder Containern direkt Meldungen schicken kannst.

Die aktuelle Quellenlage ist sauber. Die offizielle Installationsdoku beschreibt fuer Docker weiterhin Port 80 im Container, ein Volume fuer den persistenten Cache unter /var/cache/ntfy und ein Compose-Beispiel mit Healthcheck. Die Release-Notes listen ntfy server v2.21.0 als aktuelle stabile Server-Version mit Release-Datum 30. Maerz 2026. Genau diese Version pinne ich hier bewusst, statt blind latest zu verwenden.

Lokal erzeugtes Artikelbild fuer ntfy mit Docker Compose

Was du am Ende hast

Einen laufenden ntfy-Server unter http://127.0.0.1:8095
Eine sichtbare Web-UI im Browser
Einen verifizierten Healthcheck unter /v1/health
Einen funktionierenden Publish-Test per curl

Warum ntfy gerade jetzt ein guter Compose-Kandidat ist

ntfy loest ein sehr reales Problem: Benachrichtigungen aus eigenen Jobs, Backups, Deployments oder Homelab-Diensten sollen schnell raus, ohne dass du gleich Slack, Teams oder einen kompletten Alerting-Stack einrichten musst.

Der praktische Vorteil liegt in der Schlichtheit:

Nachrichten gehen per HTTP POST
Die gleiche Instanz liefert API und Web-UI
Das Setup kommt fuer den lokalen Start mit einem einzigen Container aus
Das Ergebnis ist sofort pruefbar, statt nur "irgendwie zu laufen"

Voraussetzungen

Docker und Docker Compose
Ein freier lokaler Port, hier 8095
Ein neues Arbeitsverzeichnis statt irgendeines bestehenden Projektordners

Projektordner anlegen

Starte sauber in einem eigenen Verzeichnis:

mkdir ntfy-local
cd ntfy-local
mkdir -p ntfy-cache

Die Compose-Datei schreiben

Lege ntfy-local/compose.yaml mit diesem Inhalt an:

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

Warum dieses Setup so aussieht:

v2.21.0 ist reproduzierbar und entspricht der aktuell stabilen Server-Release aus den offiziellen Notes.
8095:80 vermeidet Kollisionen mit Diensten, die lokal schon Port 80 oder 8080 nutzen.
./ntfy-cache:/var/cache/ntfy sorgt dafuer, dass der Nachrichten-Cache nicht bei jedem Neustart verschwindet.
--base-url http://localhost:8095 passt Links und UI sauber an den lokalen Host-Port an.
init: true ist sinnvoll, wenn der Healthcheck aktiviert ist.

Container starten

docker compose up -d

Wenn das Image schon lokal vorhanden ist, dauert das nur kurz. Beim ersten Start zieht Docker das gepinnte Release.

Lokalen Start pruefen

Der wichtigste Schnelltest ist der offizielle Health-Endpunkt:

curl -fsS http://127.0.0.1:8095/v1/health

Erwartete Antwort:

{"healthy":true}

Zusatzcheck ueber die Container-Logs:

docker compose logs --tail 20 ntfy

In meinem lokalen Test meldete ntfy dabei exakt, dass es auf Port 80 im Container lauscht und als Version 2.21.0 gestartet ist.

Die erste Nachricht schicken

Jetzt kommt der Teil mit echtem sichtbarem Ergebnis. Sende eine Testnachricht an das Topic hausserver:

curl -fsS -d "Backup fertig um 08:15 Uhr" http://127.0.0.1:8095/hausserver

Die API antwortet mit JSON, unter anderem mit id, time, event, topic und deiner Nachricht. In meinem Test kam dabei sofort ein message-Event fuer das Topic zurueck.

Die Nachricht im Browser sehen

Oeffne jetzt http://127.0.0.1:8095 im Browser. In der Weboberflaeche kannst du das Topic hausserver abonnieren. Danach siehst du neue Meldungen direkt im UI, ohne weitere Zusatzdienste.

Genau hier wird der Nutzen von ntfy greifbar:

Shell-Skripte koennen einen erfolgreichen Lauf melden
Backup-Jobs koennen nur im Fehlerfall anschlagen
Kleine Self-Hosting-Dienste bekommen eine einfache Benachrichtigungsschicht

Sinnvolle Praxisbeispiele

Ein Backup-Skript kann nach erfolgreichem Lauf so enden:

curl -fsS -d "Restic-Backup erfolgreich" http://127.0.0.1:8095/ops

Oder bei einem Fehler:

curl -fsS \
  -H "Title: Backup fehlgeschlagen" \
  -H "Priority: urgent" \
  -d "Pruefe die Logs auf dem Backup-Host." \
  http://127.0.0.1:8095/ops

Damit ist ntfy nicht nur ein laufender Container, sondern sofort ein brauchbarer Baustein fuer Automatisierung.

Was du fuer spaeter im Blick behalten solltest

Fuer einen ersten lokalen Test reicht dieses Ein-Container-Setup voellig aus.
Wenn du ntfy spaeter extern veroeffentlichen willst, gehoeren HTTPS und ein Reverse Proxy davor.
Wer Benutzerverwaltung, Mail oder weitergehende Policies braucht, sollte danach gezielt die Konfigurationsdoku fuer server.yml nachziehen.

Fazit

ntfy ist am 20. April 2026 ein starker Docker-Compose-Fallback, weil die Doku aktuell ist, die stabile Version klar benannt ist und das Ergebnis in wenigen Minuten sichtbar wird. Du bekommst keinen abstrakten "Stack", sondern einen konkreten Dienst, den du direkt per curl ansprechen und im Browser nutzen kannst.

User Dashboard