ntfy 2026 selbst hosten: Topics, Zugriffskontrolle und Zustellung
Eine praxisnahe Anleitung zum Self-Hosting von ntfy mit Docker, Ports, persistenten Daten, TLS, Sicherheit, Backups und den Fehlern, die den Produktiveinsatz verhindern. Schritt für Schritt.
Die meisten Installationsnotizen zu ntfy enden beim ersten Seitenaufruf. Das ist zu früh: Der Cache ist flüchtig oder WebSocket-/SSE-Verbindungen laufen am Proxy ab. Ein aussagekräftiger Production-Test ist anspruchsvoller – veröffentlichen Sie mit curl eine Nachricht, empfangen Sie sie über HTTP- und WebSocket-Subscriptions, hängen Sie eine Datei an und testen Sie ein authentifiziertes Topic.
Die Rolle von ntfy ist klar: Push-Benachrichtigungen, die mit einer einfachen HTTP-Anfrage versendet werden. Der operative Umfang umfasst mehr als den Webprozess. Deshalb müssen Abhängigkeit, gespeicherter Zustand und öffentliche Route ausdrücklich benannt werden, bevor echte Daten eintreffen.
Der Aufbau von ntfy für den Produktiveinsatz
Der ntfy-HTTP-Prozess lauscht auf Port 80. Belassen Sie diesen Port im Anwendungsnetzwerk und veröffentlichen Sie ausschließlich die Plattform-Route. Die lokale Laufzeitanforderung besteht aus einem Konfigurations-Volume und optional einer Auth-Datenbank. Testen Sie diese Grenze vor der Veröffentlichung und erneut nach dem Austausch eines Containers.
Halten Sie die Grenze als kurzen Vertrag fest: Wer ist für die Anforderung zuständig, welches Credential wird verwendet, welcher Timeout ist akzeptabel und woran ist ein Fehler erkennbar? Führen Sie anschließend diese Transaktion aus: Veröffentlichen Sie mit curl eine Nachricht, empfangen Sie sie über HTTP- und WebSocket-Subscriptions, hängen Sie eine Datei an und testen Sie ein authentifiziertes Topic. Beobachten Sie währenddessen langlebige Subscriber-Verbindungen, die Größe von Attachments, die Cache-Aufbewahrung und ausgehende Push-Relays, denn diese Auslastung liefert eine bessere Ausgangsgröße als ein inaktiver Container.
ntfy starten, ohne die beweglichen Teile zu verbergen
Verwenden Sie den Container als austauschbare Laufzeitumgebung, nicht als Ort der Wahrheit.
docker run -d \
--name ntfy \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v ntfy-data:/var/cache/ntfy \
-e NTFY_BASE_URL=https://app.example.com \
binwiederhier/ntfy:latest serve
Bestätigen Sie die lokale Anforderung vor der Veröffentlichung: ein Konfigurations-Volume und optional eine Auth-Datenbank. Prüfen Sie vor der Veröffentlichung den Container-Benutzer, beschreibbare Pfade und den gebundenen Listener. Führen Sie die vollständige Aktion aus – veröffentlichen Sie mit curl eine Nachricht, empfangen Sie sie über HTTP- und WebSocket-Subscriptions, hängen Sie eine Datei an und testen Sie ein authentifiziertes Topic – und speichern Sie die exakte Image-Referenz, mit der das Ergebnis erzielt wurde.
ntfy eine kanonische Adresse geben
Setzen Sie base-url auf die öffentliche HTTPS-Origin, die von Publishern und Subscribern verwendet wird. Leiten Sie den gewählten Hostnamen an Container-Port 80 weiter, geben Sie den ursprünglichen Host und das HTTPS-Schema weiter und vermeiden Sie eine zweite direkte Origin.
Testen Sie ntfy von einem sauberen externen Client aus. Trennen Sie Ingress-Fehler von der bekannten Anwendungsgrenze – der Cache ist flüchtig oder WebSocket-/SSE-Verbindungen laufen am Proxy ab. Ein Zertifikats-, DNS- oder 502-Fehler gehört zum Routing; eine Anfrage, die ntfy erreicht und erst später fehlschlägt, gehört zum Anwendungszustand, zur Kapazität oder zu einer unterstützenden Anforderung. Der Leitfaden für TLS mit eigener Domain behandelt die erste Gruppe.
Nachweisen, dass ntfy einen Austausch übersteht
Schützen Sie den Zustand von ntfy, bevor Sie den Container optimieren. Zum erforderlichen Bestand gehören Konfiguration, Auth-Datenbank und Attachments, die erhalten bleiben müssen. Binden Sie /var/cache/ntfy vor dem Bootstrap ein, schreiben Sie harmlose Beispieldaten und ersetzen Sie den Container, um nachzuweisen, dass dieser Pfad tatsächlich persistent ist. Wenn mehrere Stores konsistent bleiben müssen, dokumentieren Sie die Reihenfolge, in der Schreibvorgänge pausiert und Backups erstellt werden.
Bewahren Sie Kopien außerhalb des Deployment-Servers auf und verschlüsseln Sie Material, das Credentials oder private Inhalte enthält. Die Wiederherstellung ist erfolgreich, wenn Benutzer, ACLs, Konfiguration und aufbewahrte Attachments zurückkehren und ein authentifizierter Subscriber eine neue Nachricht empfängt. Der Unterschied zwischen einem persistenten Mount und einer unabhängigen Kopie wird unter Persistent Storage und Snapshots erläutert.
ntfy nicht den gesamten Host überlassen
Bei ntfy ist die wertvolle Angriffsfläche nicht unbedingt die Landingpage. Der häufigste Fehler besteht darin, öffentliches Erraten von Topics zu erlauben, obwohl Nachrichten operative Details enthalten. Gehen Sie gezielt dagegen vor: Verwenden Sie Topic-ACLs, denn nicht erratbare Topic-Namen sind für operative Nachrichten keine zuverlässige Autorisierung.
NTFY_BASE_URL ist Konfiguration und kein Secret. Halten Sie seinen Wert explizit, während Sie die separaten Credentials schützen, die ntfy verwendet. Verwenden Sie einen unprivilegierten Container-Benutzer, sofern das Image dies unterstützt, und binden Sie keine nicht zugehörigen Credentials ein. Wenden Sie Rate- oder Größenlimits am Ingress an, wo nicht vertrauenswürdige Arbeit langlebige Subscriber-Verbindungen, Attachment-Größe, Cache-Aufbewahrung und ausgehende Push-Relays verbrauchen kann.
ntfy aktualisieren, ohne zu raten
Verwenden Sie „eine Nachricht mit curl veröffentlichen, sie über HTTP- und WebSocket-Subscriptions empfangen, eine Datei anhängen und ein authentifiziertes Topic testen“ als ntfy-Smoke-Test nach jedem Deployment. Die zugehörigen Metriken sind langlebige Subscriber-Verbindungen, Attachment-Größe, Cache-Aufbewahrung und ausgehende Push-Relays. Lösen Sie Alerts aus, sobald sich diese Ressourcen einem Punkt nähern, an dem die Benutzeraktion beeinträchtigt wird.
Das größte Änderungsrisiko besteht darin, dass Konfigurationsschlüssel, Migrationen der Auth-Datenbank und Erwartungen der Clients vor der Aktualisierung von ntfy geprüft werden müssen. Ein sicheres Release beginnt mit einem wiederherstellbaren Snapshot und validiert jede einseitige Zustandsänderung, bevor Traffic umgeleitet wird. Wenn der Cache flüchtig ist oder WebSocket-/SSE-Verbindungen am Proxy ablaufen, lassen Sie den fehlerhaften Container lange genug bestehen, um seine Konfiguration und den ersten Fehler zu lesen.
Das ntfy-Release-Gate
Ein Release Candidate für ntfy erhält Traffic, wenn er ein festgelegtes Szenario erfolgreich absolviert: Veröffentlichen Sie mit curl eine Nachricht, empfangen Sie sie über HTTP- und WebSocket-Subscriptions, hängen Sie eine Datei an und testen Sie ein authentifiziertes Topic. Erfassen Sie den Image-Digest, die effektive Konfiguration ohne Secrets, die öffentliche Origin und die Zeitstempel dieses Szenarios. Die Testdaten sollten verwerfbar sein, aber realistisch genug, um denselben Pfad wie bei den Benutzern auszuführen.
Führen Sie den Test nach dem Austausch der Laufzeitumgebung aus und bauen Sie den Service anschließend aus Konfiguration, Auth-Datenbank und Attachments neu auf, die erhalten bleiben müssen. Die Wiederherstellung ist erfolgreich, wenn Benutzer, ACLs, Konfiguration und aufbewahrte Attachments zurückkehren und ein authentifizierter Subscriber eine neue Nachricht empfängt. Vergleichen Sie die Ressourcenmessungen für langlebige Subscriber-Verbindungen, Attachment-Größe, Cache-Aufbewahrung und ausgehende Push-Relays mit dem vorherigen Release und untersuchen Sie signifikante Abweichungen vor der Freigabe.
Führen Sie abschließend diesen kontrollierten Fehler aus: Senden Sie harmlose Eingaben nahe am Ressourcen- oder Formatlimit, das mit dieser Grenze verbunden ist: Der Cache ist flüchtig oder WebSocket-/SSE-Verbindungen laufen am Proxy ab. Stellen Sie sicher, dass ntfy den Fehler erklärt, keinen bestehenden Zustand beschädigt und fortgesetzt werden kann, sobald die gültige Bedingung wiederhergestellt ist. Speichern Sie einen bereinigten Logauszug und die Wiederherstellungszeit. Zusammen decken diese Prüfungen Verhalten, Dauerhaftigkeit und Betriebsfähigkeit ab – nicht nur die Verfügbarkeit des Prozesses.
ntfy explizit halten, während Dockup das Routing übernimmt
Routing, Zertifikate, der Austausch von Services und angebundener Storage sind sinnvolle Ziele für Automatisierung. Dockup übernimmt dies für ntfy und kann die zugehörige verwaltete Datenbank bereitstellen oder eine Verbindung zu Services auf dem eigenen Server eines Kunden herstellen.
Was Dockup nicht selbst erfinden sollte, ist die Trust Policy von ntfy. Setzen Sie nach dem Deployment base-url auf die öffentliche HTTPS-Origin, die von Publishern und Subscribern verwendet wird, erzwingen Sie diese Grenze – verwenden Sie Topic-ACLs, denn nicht erratbare Topic-Namen sind für operative Nachrichten keine zuverlässige Autorisierung – und überprüfen Sie das Ergebnis dieses Szenarios: Veröffentlichen Sie mit curl eine Nachricht, empfangen Sie sie über HTTP- und WebSocket-Subscriptions, hängen Sie eine Datei an und testen Sie ein authentifiziertes Topic. Das Ergebnis ist Infrastruktur mit One-Click-Bereitstellung und einem anwendungsspezifischen Abnahmetest.
Häufig gestellte Fragen
Was benötigt ntfy für ein Production-Deployment?
Routen Sie den ntfy-Container auf Port 80 über eine einzige HTTPS-Origin. Die lokale Laufzeitanforderung besteht aus einem Konfigurations-Volume und optional einer Auth-Datenbank. Erklären Sie ntfy erst dann für bereit, wenn Sie mit curl eine Nachricht veröffentlichen, sie über HTTP- und WebSocket-Subscriptions empfangen, eine Datei anhängen und ein authentifiziertes Topic testen können.
Welche ntfy-Daten gehören in ein Backup?
Machen Sie /var/cache/ntfy persistent und nehmen Sie Konfiguration, Auth-Datenbank sowie Attachments, die erhalten bleiben müssen, in dasselbe Recovery-Manifest auf. Eine saubere ntfy-Wiederherstellung ist erst erfolgreich, wenn Benutzer, ACLs, Konfiguration und aufbewahrte Attachments zurückkehren und ein authentifizierter Subscriber eine neue Nachricht empfängt.
Benötigt ntfy HTTPS hinter einem Reverse Proxy?
Verwenden Sie HTTPS für die öffentliche ntfy-Origin und belassen Sie Port 80 auf der internen Route. Wenden Sie die ntfy-Einstellung korrekt an: Setzen Sie base-url auf die öffentliche HTTPS-Origin, die von Publishern und Subscribern verwendet wird. Bei ntfy schützt HTTPS Credentials oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, von der Origin abhängiges Client-Verhalten.
Wie sollte ein ntfy-Upgrade getestet werden?
Stellen Sie den aktuellen ntfy-Zustand in einem isolierten Deployment wieder her, wenden Sie die Candidate-Version an und wiederholen Sie die Abnahmetransaktion. Gehen Sie dabei besonders sorgfältig vor, da Konfigurationsschlüssel, Migrationen der Auth-Datenbank und Erwartungen der Clients vor der Aktualisierung von ntfy geprüft werden müssen. Behalten Sie das vorherige ntfy-Image, bis die Grenzen für Datenmigration und Rollback geklärt sind.