Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Synology / NAS 11.09.2026 · 11 min Lesezeit

ntfy auf dem Synology NAS installieren: Push-Benachrichtigungen für Server und Skripte

ntfy ist ein selbst gehosteter Push-Dienst ohne Cloud-Konto. Die Anleitung zeigt die Installation auf dem Synology NAS per Container Manager mit aktivierter Authentifizierung, curl-Testpush und Anbindung von Backup-Skripten und Monitoring.

Geprüft am 23.10.2026 · für ntfy 2.33.1

WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

NAS mit vier Schächten im Regal, auf dem Holzschreibtisch ein Smartphone mit leuchtender Sprechblase und Pflanzen

Wer Backup-Skripte, Monitoring-Werkzeuge oder Cronjobs auf dem NAS betreibt, will Fehler sofort erfahren, ohne einen externen Push-Dienst. ntfy (ausgesprochen „notify“) ist ein schlanker Pub/Sub-Dienst, der Benachrichtigungen per einfachem HTTP-POST an ein Topic sendet und diese über die Android- oder iOS-App empfängt. Es gibt keine Registrierung, die Daten bleiben auf dem eigenen NAS. Uptime Kuma, WUD, Diun und eigene Shellskripte sprechen denselben HTTP-Endpunkt an. Stand 23.10.2026 ist Version 2.33.1 aktuell.

Voraussetzungen

  • Synology NAS mit x86_64- oder ARM64-Prozessor und DSM 7.2 oder neuer
  • Container Manager aus dem Paket-Zentrum
  • Mindestens 256 MB freier RAM für den ntfy-Container
  • SSH-Zugang zum NAS, nötig für docker exec: Benutzer und Tokens lassen sich nur per Befehl anlegen
  • Smartphone mit ntfy-App: Android via F-Droid (empfohlen, kein Firebase) oder Google Play, iOS via App Store
  • Optional: NGINX Proxy Manager auf der Synology für HTTPS und Reverse-Proxy-Betrieb

Schritt 1: Ordnerstruktur anlegen

Öffnen Sie die File Station und legen Sie unter /volume1/docker/ zwei Ordner an:

  • /volume1/docker/ntfy – Konfigurationsverzeichnis (server.yml, user.db)
  • /volume1/docker/ntfy/cache – SQLite-Nachrichten-Cache (cache.db)

Alternativ per SSH in einem Schritt:

mkdir -p /volume1/docker/ntfy/cache

Verifizieren: In der File Station müssen beide Ordner sichtbar sein. Per SSH zeigt ls -la /volume1/docker/ntfy/ den Unterordner cache. Ohne diese Ordner verliert der Container bei einer Neuerstellung Nachrichten und Benutzer.

Schritt 2: compose.yaml anlegen und Container starten

Öffnen Sie den Container Manager, wechseln Sie zu Projekt und klicken Sie auf Erstellen. Projektname: ntfy, Pfad: /volume1/docker/ntfy. Fügen Sie folgenden Inhalt ein:

services:
  ntfy:
    image: binwiederhier/ntfy:v2.33.1
    container_name: ntfy
    command: serve
    environment:
      - TZ=Europe/Berlin
      - NTFY_BASE_URL=https://ntfy.example.com
      - NTFY_CACHE_FILE=/var/cache/ntfy/cache.db
      - NTFY_AUTH_FILE=/etc/ntfy/user.db
      - NTFY_AUTH_DEFAULT_ACCESS=deny-all
      - NTFY_ENABLE_LOGIN=true
      # Nur hinter einem Reverse Proxy (z. B. NGINX Proxy Manager):
      # - NTFY_BEHIND_PROXY=true
      # Für sofortige Zustellung an iOS-Geräte:
      # - NTFY_UPSTREAM_BASE_URL=https://ntfy.sh
    volumes:
      - /volume1/docker/ntfy/cache:/var/cache/ntfy
      - /volume1/docker/ntfy:/etc/ntfy
    ports:
      - 6741: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
    init: true
    restart: unless-stopped

Passen Sie NTFY_BASE_URL an Ihre URL an; für rein lokale Nutzung genügt http://NAS-IP:6741. Die Base URL braucht ntfy unter anderem für Links zu Anhängen. Der Tag v2.33.1 hält die Version fest; für ein Update tragen Sie die neue Version ein. Mit dieser Compose-Datei lief im Test das Update von 2.28.0 auf 2.29.0 ohne Eingriff: Der Container war danach wieder healthy, Benutzer und eine vorher gesendete Nachricht blieben erhalten. init: true empfiehlt die ntfy-Doku, sobald ein Healthcheck aktiv ist. NTFY_BEHIND_PROXY aktivieren Sie erst, wenn ein Reverse Proxy vorgeschaltet ist: ntfy wertet dann den Header X-Forwarded-For aus, den bei direktem Zugriff jeder Client fälschen kann, um das Rate-Limit zu umgehen.

Die Parameter im Überblick:

ParameterWertZweck
Imagebinwiederhier/ntfy:v2.33.1Offizielles Image
Port6741:80Externer Port 6741, intern Port 80
Volume 1/volume1/docker/ntfy/cache:/var/cache/ntfyPersistenter Nachrichten-Cache
Volume 2/volume1/docker/ntfy:/etc/ntfyKonfig + Auth-Datenbank
NTFY_AUTH_DEFAULT_ACCESSdeny-allZugriff ohne Anmeldung sperren
NTFY_BEHIND_PROXYtrue (nur mit Proxy)Echte Client-IP hinter Reverse Proxy
restartunless-stoppedNeustart auch nach NAS-Reboot

Verifizieren: Starten Sie das Projekt. Unter Projekt > ntfy zeigt der Container nach 30 bis 40 Sekunden Wird ausgeführt. Prüfen Sie den Health-Endpunkt per SSH:

curl -s http://localhost:6741/v1/health

Erwartete Ausgabe: {"healthy":true}. Wird die Verbindung abgelehnt, prüfen Sie das Container-Log im Container Manager.

Schritt 3: Admin-Benutzer anlegen

ntfy legt die Benutzerdatenbank (user.db) beim ersten Start an, aber ohne Benutzer. Melden Sie sich per SSH am NAS an und führen Sie aus:

docker exec -it ntfy ntfy user add --role=admin meinadmin

ntfy fragt nach einem Passwort. Legen Sie zuerst die Benutzer skriptbenutzer und lesebenutzer mit docker exec -it ntfy ntfy user add BENUTZERNAME ohne --role=admin an. Geben Sie ihnen anschließend einzelne Topics frei:

docker exec -it ntfy ntfy access skriptbenutzer backup-alerts rw
docker exec -it ntfy ntfy access lesebenutzer backup-alerts ro

Verifizieren: Öffnen Sie http://NAS-IP:6741. Dank NTFY_ENABLE_LOGIN=true erscheint die Anmeldung; mit dem Admin-Konto sehen Sie danach die Topic-Übersicht. Ein Aufruf ohne Zugangsdaten wird abgewiesen:

curl -s -o /dev/null -w "%{http_code}" http://localhost:6741/mein-topic/json
# Erwartete Ausgabe: 403 (bzw. 401)

Schritt 4: Access Token für Skripte erstellen

Statt Passwörtern in Skripten verwenden Sie Access Tokens. Sie gehören zu einem Benutzer und lassen sich einzeln widerrufen. Legen Sie je Anwendungsfall einen eigenen Token an:

docker exec -it ntfy ntfy token add --label='backup-skript' meinadmin

Die Ausgabe zeigt den Token im Format tk_xxxxxxxxxxxxxxxxxxxxxxxx. Notieren Sie ihn; ntfy token list zeigt vorhandene Tokens.

Verifizieren: Senden Sie eine Testnachricht mit dem Token:

curl -s \
  -H "Authorization: Bearer tk_deintoken" \
  -H "Title: Token-Test" \
  -d "Token funktioniert" \
  http://localhost:6741/test-topic

Erwartete Antwort: ein JSON-Objekt mit "event":"message". Erscheint 401 Unauthorized, stimmt der Token nicht oder wurde er falsch kopiert.

Schritt 5: App einrichten und Topic abonnieren

Installieren Sie die ntfy-App. Unter Android nutzen F-Droid- und Google-Play-Version für selbst gehostete Server eine direkte Verbindung ohne Firebase; die F-Droid-Version enthält Firebase gar nicht. Unter iOS kommen Nachrichten ohne NTFY_UPSTREAM_BASE_URL=https://ntfy.sh teils erst nach Minuten bis Stunden an; mit der Einstellung sendet ntfy nur einen Abrufhinweis mit Nachrichten-ID über ntfy.sh, der Inhalt bleibt auf Ihrem Server.

  1. Öffnen Sie in der App Einstellungen > Standard-Server.
  2. Tragen Sie Ihre ntfy-URL ein, z. B. https://ntfy.example.com oder http://NAS-IP:6741.
  3. Hinterlegen Sie unter Benutzer verwalten Benutzername und Passwort für diesen Server.
  4. Abonnieren Sie ein Topic, z. B. backup-alerts.

Verifizieren: Senden Sie vom NAS eine Testnachricht und prüfen Sie den Eingang auf dem Smartphone:

curl -s \
  -u meinadmin:meinpasswort \
  -H "Title: NAS-Testpush" \
  -H "Priority: high" \
  -H "Tags: white_check_mark" \
  -d "Verbindung steht!" \
  http://localhost:6741/backup-alerts

Die App zeigt die Nachricht mit Titel, Priorität und Emoji-Tag. Kommt nichts an, prüfen Sie, ob Port 6741 in der DSM-Firewall (Systemsteuerung > Sicherheit > Firewall) für Ihr Subnetz freigegeben ist.

Schritt 6: Skript- und Monitoring-Integration

Jedes Werkzeug, das HTTP-Anfragen senden kann, lässt sich anbinden.

Bash-Skript (Backup-Alert)

#!/bin/bash
NTFY_URL="http://localhost:6741"
NTFY_TOPIC="backup-alerts"
NTFY_TOKEN="tk_ihrtoken"

rsync -az /volume1/data/ /volume2/backup/ && STATUS="OK" || STATUS="FEHLER"

curl -s \
  -H "Authorization: Bearer ${NTFY_TOKEN}" \
  -H "Title: Backup ${STATUS}" \
  -H "Priority: $([ "$STATUS" = "OK" ] && echo default || echo high)" \
  -H "Tags: $([ "$STATUS" = "OK" ] && echo white_check_mark || echo warning)" \
  -d "rsync auf NAS-Backup abgeschlossen: ${STATUS}" \
  "${NTFY_URL}/${NTFY_TOPIC}"

Uptime Kuma

In Uptime Kuma ist ntfy als nativer Notification-Typ eingebaut: Settings > Notifications > Add Notification > ntfy, dann Server-URL, Topic und Token eintragen.

WUD / DIUN (Container-Update-Monitoring)

WUD und Diun bringen jeweils einen eigenen ntfy-Benachrichtigungstyp mit; tragen Sie dort Server-URL, Topic und Token ein.

Nachrichten-Parameter im Überblick

HTTP-HeaderBeispielwertFunktion
TitleBackup abgeschlossenBenachrichtigungstitel
Priority1–5 (default=3)Dringlichkeit (5 = urgent)
Tagswhite_check_mark,warningEmoji-Tags (Unicode-Shortcodes)
Clickhttps://nas.example.comURL beim Tippen auf den Alert
Attachhttps://example.com/log.txtDatei-Anhang per URL

Verifizieren: Lösen Sie in Uptime Kuma mit „Test“ eine Benachrichtigung aus und prüfen Sie den Eingang in der App. Führen Sie das Backup-Skript einmal manuell aus: Die Meldung „Backup OK“ oder „Backup FEHLER“ erscheint auf dem Smartphone.

Version 2.30.0 ergänzt Links zu Anhängen in E-Mail-Benachrichtigungen und unterstützt SMTP-Server mit LOGIN-Authentifizierung. Die neue Cluster-Funktion ist experimentell und nicht für den produktiven Einsatz vorgesehen. Sichern Sie vor dem Update die SQLite-Dateien bei gestopptem Container und ändern Sie anschließend den Image-Tag auf v2.30.0. Im Upgrade von 2.29.0 auf 2.30.0 blieben das Benutzerkonto und eine gespeicherte Nachricht erhalten; anonyme Schreibzugriffe wurden weiterhin mit HTTP 403 abgewiesen. Auch die frische Installation beantwortete den Health-Endpunkt mit HTTP 200.

Version 2.31.1 macht das erneute Verbinden der App mit since=<Nachrichten-ID> deutlich günstiger, weil ein neuer Index in der cache.db hinzukommt. Beim ersten Start migriert ntfy dafür das Schema der Nachrichtendatenbank von Version 16 auf 17. Wollen Sie danach auf 2.31.0 oder älter zurück, setzen Sie vorher die Schemaversion in der cache.db zurück: UPDATE schemaVersion SET version = 16 WHERE id = 1. Neu ist außerdem der Endpunkt /v1/ready, und /v1/health meldet zusätzlich die Rolle des Knotens, der Healthcheck aus Schritt 2 erkennt die Antwort weiterhin. Im Test mit dieser Compose-Datei lief das Update von 2.30.0 auf 2.31.1 ohne Eingriff: Der Container war wieder healthy, die vor dem Update per Token gesendete Nachricht blieb abrufbar, derselbe Token konnte weiter senden, und anonyme Zugriffe wurden mit 403 abgewiesen.

Version 2.32.0 war bis zum 22.10.2026 aktuell. Streaming-Abonnements senden jetzt den Header Incremental: ?1, damit unterstützende Proxys Nachrichten ohne Pufferung weiterreichen. Ein über auth-users in der Konfiguration angelegter Benutzer lässt sich über die Admin-API nicht löschen oder ändern; statt HTTP 500 antwortet ntfy dann mit 409. Außerdem speichert jede Datenbank die älteste Schemaversion, mit der sie noch arbeitet: Eine ältere ntfy-Version verweigert künftig den Start auf einer Datenbank, die eine neuere Version inkompatibel migriert hat. Laut Release Notes ist keine der bisherigen Migrationen inkompatibel. Im Test mit dieser Compose-Datei lief das Update von 2.31.1 auf 2.32.0 ohne Eingriff: Der Container war wieder healthy, die vor dem Update per Token gesendete Nachricht blieb abrufbar, derselbe Token konnte weiter senden, und anonyme Zugriffe wurden mit 403 abgewiesen.

Version 2.33.1 (Stand 23.10.2026) ist die aktuelle Fassung. Version 2.33.0 baut ntfy mit Go 1.27.3 und bringt damit Sicherheitskorrekturen, unter anderem lehnt ntfy jetzt Zertifikatsketten über die kompromittierten eMudhra-Zwischenzertifizierungsstellen ab. Außerdem bestätigt ntfy eine Telefonnummer nur noch, wenn Twilio den Code ausdrücklich als genehmigt meldet, und ein Abonnement darf höchstens 150 Topics umfassen; doppelte Topics werden ignoriert. Neu sind Metriken für den PostgreSQL-Verbindungspool und eine Statusanzeige für das experimentelle Clustering. 2.33.1 behebt einen Absturz (SIGILL) auf älteren amd64-Prozessoren. Neue Pflichtvariablen oder Migrationen nennen die Release Notes nicht. Im Test mit dieser Compose-Datei lief das Update von 2.32.0 auf 2.33.1 am 23.10.2026 ohne Eingriff: Der Container war wieder healthy, die vor dem Update per Token gesendete Nachricht blieb abrufbar, derselbe Token konnte weiter senden, und anonyme Zugriffe wurden mit 403 abgewiesen.

Troubleshooting / Typische Fehler

  • Server ist trotz Konfiguration offen: Prüfen Sie mit docker exec -it ntfy ntfy user list – zeigt die Ausgabe keine Benutzer, wurden sie noch nicht angelegt. Die Env-Var NTFY_AUTH_DEFAULT_ACCESS=deny-all muss im laufenden Container aktiv sein: docker exec ntfy env | grep NTFY_AUTH.
  • Container startet, /v1/health liefert 503: Meist ein Rechteproblem. Prüfen Sie mit ls -la /volume1/docker/ntfy/, ob der Ordner existiert und beschreibbar ist. Der ntfy-Prozess läuft als root – kein PUID/PGID nötig, aber der Ordner muss vorhanden sein.
  • Live-Feed bricht ab (WebSocket-Fehler): Hinter NGINX Proxy Manager aktivieren Sie im Proxy-Host die Option WebSockets Support. Setzen Sie dann auch NTFY_BEHIND_PROXY=true.
  • Rate-Limiting sperrt eigene Skripte: Standard sind 60 Anfragen als Vorrat, danach eine je 5 Sekunden pro IP. Laufen alle Skripte auf dem NAS, zählen sie als eine IP. Erhöhen Sie per Umgebungsvariable oder server.yml die Werte visitor-request-limit-burst und visitor-request-limit-replenish.
  • $-Zeichen im Passwort: In doppelten Anführungszeichen wertet die Shell $ als Variable aus, die Anmeldung schlägt fehl. Setzen Sie solche Werte in Skripten in einfache Anführungszeichen; in einer compose.yaml schreiben Sie $$.
  • Benachrichtigungen kommen außerhalb des WLAN nicht an: Von außen ist der Server nur über eine Weiterleitung erreichbar. Nutzen Sie einen Reverse Proxy mit HTTPS (Port 443) oder ein VPN, keine direkte Weiterleitung von Port 6741.
  • Zeitstempel in Logs sind falsch: Ohne TZ=Europe/Berlin laufen Logs in UTC. TZ in der compose.yaml setzen und das Projekt neu erstellen.

Häufige Fragen

Muss ich Port 6741 im Router freigeben?

Nur wenn Push-Benachrichtigungen auch im mobilen Netz ankommen sollen. Für rein lokale Nutzung genügt die Freigabe in der DSM-Firewall. Für Zugriff von außen empfiehlt sich ein Reverse Proxy mit Let's-Encrypt-Zertifikat auf Port 443 statt einer Weiterleitung von 6741.

Kann ntfy komplett offline betrieben werden?

Mit Android und im Browser ja: Beide verbinden sich direkt mit dem Server, ohne Firebase. iOS-Geräte erhalten Nachrichten ohne Internetzugang zu ntfy.sh nur verzögert (siehe Schritt 5).

Was passiert mit Nachrichten, wenn das Handy offline war?

ntfy speichert Nachrichten serverseitig in der cache.db. Standard sind 12 Stunden, änderbar über cache-duration (bzw. NTFY_CACHE_DURATION). Beim erneuten Verbinden holt die App verpasste Nachrichten nach.

Wie integriere ich ntfy in Healthchecks auf dem NAS?

In Cron-Monitoring-Diensten wie einem selbst gehosteten Healthchecks tragen Sie ntfy als Benachrichtigungskanal ein. Bleibt ein Ping aus, sendet der Dienst die Warnung an das ntfy-Topic.

Wie aktualisiere ich ntfy auf eine neue Version?

Tragen Sie in der compose.yaml die neue Version aus den Release Notes ein und erstellen Sie das Projekt im Container Manager neu, oder per SSH im Projektordner:

cd /volume1/docker/ntfy
sudo docker compose pull
sudo docker compose up -d

Mit WUD oder DIUN erfahren Sie per ntfy, wenn eine neue Version bereitsteht.

Env-Vars oder server.yml – was ist besser?

Alle Konfigurationsoptionen können als Umgebungsvariablen (Präfix NTFY_) gesetzt werden, wie in dieser Anleitung gezeigt. Env-Vars überschreiben server.yml-Werte, falls beide vorhanden sind. Für einfache Setups sind Umgebungsvariablen übersichtlicher; eine server.yml lohnt sich bei vielen Optionen wie Rate-Limit-Anpassungen oder komplexen Zugriffsregeln.

Fazit

Ein einzelner ntfy-Container ersetzt externe Push-Dienste für Backup-Skripte, Monitoring-Alerts und Cronjob-Meldungen. Entscheidend ist die Authentifizierung: Ohne NTFY_AUTH_DEFAULT_ACCESS=deny-all kann jeder im lokalen Netz lesen und senden. Mit Admin-Benutzer, eigenen Tokens je Skript und fester Image-Version ist ntfy auch im KMU-Umfeld gut betreibbar.

Weiterführende Anleitungen und Quellen

Quellen: ntfy Dokumentation – Installation (Docker) | ntfy Dokumentation – Konfiguration und Access Control | ntfy Dokumentation – Nachrichten publizieren | ntfy Docker Hub