Benachrichtigungsdienst
ntfy, Konfiguration, Cache und Anhänge werden reproduzierbar bereitgestellt und kontrolliert aktualisiert.
Wir planen, installieren und betreiben ntfy als Benachrichtigungs-Gateway - mit HTTP-API, Topic-Rechten, Clients, Monitoring, Backups und dokumentierten Push-Wegen.
Die genannten Namen sind Marken ihrer jeweiligen Inhaber: ntfy (the ntfy project). WZ-IT ist ein unabhängiger Dienstleister und steht in keiner geschäftlichen, partnerschaftlichen oder vertraglichen Beziehung zu diesen Unternehmen. Wir bieten unabhängige Migrations-, Installations-, Hosting- und Betriebsdienstleistungen an.
ntfy nimmt Nachrichten über eine einfache HTTP-Publish-Subscribe-Schnittstelle entgegen und stellt sie abonnierten Web-, Mobil- und Desktop-Clients bereit. Skripte und Systeme können Nachrichten unter anderem per PUT, POST, JSON oder CLI veröffentlichen.
WZ-IT plant Reverse Proxy und TLS, Cache und Anhänge, Benutzer und Topic-ACLs, Access Tokens, Rate Limits, Client-Zugriff, Prometheus-Metriken und Wiederherstellung als zusammenhängenden Betriebsweg.
Das Zustellverhalten hängt von Plattform, Client und Serverkonfiguration ab. Für sofortige iOS-Benachrichtigungen benötigt ein selbst gehosteter ntfy-Server einen mit Firebase und APNS verbundenen Upstream; der offizielle Ablauf überträgt dafür einen Poll-Request und ruft den eigentlichen Nachrichteninhalt anschließend vom eigenen Server ab.
Wir klären vorab, welche Clients und Push-Wege benötigt werden, ob externe Push-Infrastruktur zulässig ist und wie Topic-Namen, Protokollierung, Aufbewahrung und Rechte gestaltet werden. So bleibt die technische Datenflussentscheidung nachvollziehbar.
Produktiver ntfy-Betrieb umfasst mehr als einen HTTP-Endpunkt. Wir verbinden TLS und Reverse Proxy, Topic-Zugriffe, Cache, Anhänge, Clients, Push-Wege, Rate Limits und Monitoring zu einem dokumentierten Benachrichtigungspfad.
ntfy, Konfiguration, Cache und Anhänge werden reproduzierbar bereitgestellt und kontrolliert aktualisiert.
Benutzer, Tokens sowie Lese- und Schreibrechte werden für private oder gezielt öffentliche Topics konfiguriert.
HTTP-Publisher, Clients und plattformspezifische Push-Abhängigkeiten werden nachvollziehbar angebunden.
Healthchecks, Prometheus-Metriken, Updates, Backups und Kapazitätsgrenzen werden in den Betrieb integriert.
Wir trennen technischen Nachrichtentransport, Integrationen und fachliche Eskalationsentscheidungen.
| Bereich | Verantwortung | Leistung und Abgrenzung |
|---|---|---|
| Architektur und Bereitstellung | WZ-IT | ntfy, TLS, Reverse Proxy, persistenter Cache, Auth-Daten, Anhänge und reproduzierbares Deployment. |
| Laufzeit und Updates | WZ-IT | Wartung der vereinbarten Instanz mit Versionsprüfung, Backup und kontrollierten Aktualisierungen. |
| Monitoring und Backups | WZ-IT | Überwachung von Health, Ressourcen und Zustellpfaden sowie Sicherung der vereinbarten persistenten Daten. |
| Publisher und Integrationen | Gemeinsam | WZ-IT bindet Systeme technisch an; der Kunde stellt Ereignisse, Zugangsdaten und gewünschte Meldungslogik bereit. |
| Clients und externe Push-Wege | Gemeinsam | Wir dokumentieren die Plattformabhängigkeiten; der Kunde bestätigt zulässige Clients und externe Push-Infrastruktur. |
| Inhalte, Empfänger und Eskalation | Kunde | Der Kunde verantwortet Nachrichteninhalte, Empfängerkreise, Priorisierung und fachliche Reaktion auf Meldungen. |
| Adapter und Eskalationsworkflows | Optional durch WZ-IT | Individuelle Publisher, Middleware, Rückkanäle und mehrstufige Eskalationen werden als separates Modul umgesetzt. |
Nachrichten mit PUT, POST, JSON, curl oder dem ntfy-CLI veröffentlichen und ohne anwendungsspezifisches SDK abonnieren.
Benachrichtigungen über Topics verteilen und mehrere Web-, Mobil- oder Desktop-Clients an definierte Kanäle anbinden.
Nachrichten mit Titel, Priorität, Tags, Anhängen, Zeitsteuerung und unterstützten Aktionsschaltflächen anreichern.
Benutzerrollen, Access Tokens sowie Lese- und Schreibrechte pro Topic oder Topic-Muster für private Instanzen konfigurieren.
ntfy über seine HTTP-Schnittstelle mit Monitoring, Backup, Automatisierung und weiteren Systemen verbinden; vorhandene Projektintegrationen können dabei genutzt werden.
Den Health-Endpunkt und optional bereitgestellte Prometheus-Metriken in den Betrieb einbinden und Cache, Zustellung sowie Ressourcen überwachen.
Ein klarer Betriebsumfang statt einer unübersichtlichen Hosting-Pauschale.
Compute, Anwendungen, Speicher und Reaktionszeit werden getrennt ausgewiesen. So sehen Sie, was im laufenden Betrieb enthalten ist und welche Anforderungen erst nach einem technischen Assessment angeboten werden.
Wir planen auch individuelle ntfy-Architekturen, Integrationen und Migrationsprojekte. Kontaktieren Sie uns für ein technisches Assessment.
Eine verwaltete ntfy-Standardanwendung ist im Starter-Workload enthalten. Jedes Service Level enthält zusätzlich flexibel nutzbare Expertenzeit für planbare Leistungen innerhalb der regulären Servicezeit. Wählen Sie Compute, weitere Anwendungen, Speicher und das passende Service Level.
Ein Workload ist eine Compute-Instanz mit den darauf vereinbarten Anwendungen.
Ein Standard-App je Workload ist bereits enthalten. Zusätzliche dedizierte Server zählen als weitere Workloads.
79,90 € je angefangenem TB und Monat, inklusive täglichem verschlüsseltem Offsite-Backup mit 7 Tagen Aufbewahrung.
Nicht nur die Zahl der Nutzer entscheidet. Nachrichtenrate, parallele Abonnements, Aufbewahrung, Anhänge, WebSocket- oder Long-Poll-Verbindungen und externe Push-Wege prägen den Betrieb.
| Nutzungsszenario | Technischer Startpunkt | Wichtige Einflussfaktoren |
|---|---|---|
| Interne Systemmeldungen ohne große Anhänge | S, persistenter Cache und Auth-Daten | Geeigneter Startpunkt bei niedriger Nachrichtenrate und wenigen parallelen Abonnements. |
| Mehrere Teams, Monitoring-Systeme und mobile Clients | M, persistente Daten und getrennter Anhangsspeicher | Nachrichtenrate, Aufbewahrung, Anhänge und benötigte Push-Wege werden vorab bewertet. |
| Viele dauerhafte Verbindungen oder Lastspitzen | L oder individuelle Dimensionierung | Proxy-Verbindungen, Dateideskriptoren, Rate Limits, Cache und Clientverhalten prägen die Architektur. |
| Geschäftskritische Alarmierung | Individuelle Mehrkanal-Architektur | ntfy, Quellsysteme, externe Push-Dienste, Eskalation und alternative Meldewege müssen gemeinsam betrachtet werden. |
Große Anhangsvolumen, individuelle Publisher, Mehrkanal-Eskalation, hohe Verbindungslasten und besondere Push-Architekturen sind nicht im allgemeinen Workload-Preis enthalten.
ntfy kann als verwalteter Workload oder in einer Umgebung des Kunden betrieben werden. Mobile Push-Pfade und mögliche externe Abhängigkeiten werden vorab dokumentiert.
Dedizierter Workload mit vereinbartem Compute, Cache, Anhangsspeicher, Backup, Monitoring und Service Level.
Betrieb im Account des Kunden mit Anbindung vorhandener Monitoring-, Netzwerk- und Sicherheitsdienste.
Betrieb im internen Netz für lokale Publisher und Clients mit kontrolliertem externem Zugriff, falls erforderlich.
Interne Publisher erreichen ntfy über private Verbindungen; mobile und externe Clients nutzen definierte öffentliche oder private Zugriffswege.
ntfy sitzt zwischen Ereignisquellen und Empfängern. Wir dokumentieren, welche Daten den eigenen Server verlassen, wie Topics geschützt sind und welche Zustellwege für jede Client-Plattform gelten.
Monitoring, Backup, Automatisierung, Anwendungen, Skripte und HTTP- oder CLI-Clients.
Öffentliche oder private Endpunkte, korrekte Proxy-Header, WebSockets, Rate Limits und Netzwerkregeln.
Rollen sowie Lese- und Schreibrechte für einzelne Topics oder Muster mit restriktivem Standardzugriff.
HTTP Publish-Subscribe, Topic-Verteilung, Cache, zeitgesteuerte Nachrichten, Anhänge und Weboberfläche.
Persistente Nachrichtenhistorie im konfigurierten Zeitraum sowie Benutzer, Tokens und Zugriffsregeln.
Dateien mit definierten Größen-, Aufbewahrungs- und Bandbreitenlimits sowie abgestimmter Sicherung.
Web-, Mobil- und CLI-Clients, optional erforderliche externe Push-Wege, Healthchecks und Prometheus-Metriken.
Für sofortige iOS-Zustellung über die offizielle App benötigt eine selbst gehostete Instanz einen mit Firebase und APNS verbundenen Upstream. Der dokumentierte Poll-Request enthält nicht den eigentlichen Nachrichteninhalt; dieser wird anschließend vom eigenen ntfy-Server abgerufen.
Antworten zu Lizenz, Topic-Schutz, iOS-Datenfluss, Integrationen, Backups und Zustellgrenzen.
Ja. Das offizielle ntfy-Repository nennt eine duale Lizenzierung unter Apache License 2.0 und GPLv2. WZ-IT betreibt die Software als unabhängiger Dienstleister und prüft Anpassungen sowie Weiterverteilung gegen die jeweils anwendbare Lizenz.
Ja, nach einer technischen Bestandsaufnahme. Wir prüfen Version, Konfiguration, Auth-Daten, Access Tokens, Cache-Datenbank, Anhänge, Reverse Proxy, Publisher und verwendete Clients. Die Migration wird mit gesicherten Ausgangsdaten, Testinstanz und kontrolliertem Umschalten geplant; flüchtige Nachrichten außerhalb der konfigurierten Aufbewahrung können nicht nachträglich übernommen werden.
Publisher können unter anderem HTTP PUT oder POST, JSON, curl und das ntfy-CLI verwenden. Wir definieren Endpunkt, Authentifizierung, Topic, Retry- und Fehlerverhalten für jedes angebundene System.
Nein. ntfy ist standardmäßig offen konfiguriert. Für private Instanzen richten wir Authentifizierung, Access Tokens, Topic-ACLs und typischerweise einen restriktiven Standardzugriff ein. Verbindlich ist die geprüfte Konfiguration, nicht ein schwer erratbarer Topic-Name.
iOS beschränkt Hintergrundverarbeitung. Die offizielle ntfy-Konfiguration beschreibt deshalb für sofortige Meldungen einen Upstream, der über Firebase und APNS weckt. Der selbst gehostete Server sendet dabei einen Poll-Request mit Nachrichten-ID und abgeleitetem Topic-Wert; den eigentlichen Nachrichteninhalt ruft die App anschließend vom eigenen Server ab.
Der Server, die Weboberfläche und verschiedene direkte Abonnementwege können selbst gehostet werden. Das Verhalten mobiler Hintergrundzustellung hängt jedoch von Betriebssystem, Client und Konfiguration ab. Ohne den dokumentierten iOS-Upstream können Meldungen verzögert eintreffen; deshalb klären wir die benötigten Clients vorab.
Je nach Setup sichern wir Auth-Daten, Access Tokens, Konfiguration, Cache-Datenbank und Anhangsspeicher. Die Nachrichtenhistorie ist nur für die konfigurierte Cache-Dauer vorgesehen; ntfy ersetzt dadurch nicht automatisch eine dauerhafte Event-Queue oder revisionssichere Ereignisablage.
Grundsätzlich können Systeme mit HTTP-Unterstützung Nachrichten veröffentlichen. Das Projekt dokumentiert außerdem zahlreiche Integrationen und stellt einen Health-Endpunkt sowie optional Prometheus-Metriken bereit. Wir prüfen Authentifizierung, Payload, Fehlerpfad und Rate Limits je Anbindung.
Eine pauschale Zustellgarantie wäre nicht seriös, weil Quellsystem, Netzwerk, ntfy, Client und gegebenenfalls externe Push-Dienste beteiligt sind. Für kritische Alarmierung planen wir Überwachung des Zustellwegs, Eskalationsregeln und bei Bedarf einen unabhängigen zweiten Meldekanal.
Ob ihr ntfy selbst im Haus betreiben oder Daten von Berufsgeheimnisträgern §203-tauglich unterbringen müsst - wir bauen, betreiben und warten ntfy auf einem verschlüsselten Vor-Ort-Server. Daten verlassen das Haus nie im Klartext.
ntfy on-premise ansehen
Diese Lösungen werden oft zusammen mit ntfy eingesetzt
Diese Lösungen bieten ähnliche Funktionalitäten und können gemeinsam evaluiert werden
Kein Risiko: Im schlechtesten Fall gehen Sie mit mehr Klarheit über Ihr Projekt heraus als vorher.


„Die Beratung von WZ-IT zu unserer Azure-Migration war schon im Erstgespräch fachlich sehr fundiert und völlig unverbindlich - wir haben eine Menge mitgenommen.“
Ob konkrete IT-Herausforderung oder einfach eine Idee - wir freuen uns auf den Austausch. In einem kurzen Gespräch prüfen wir gemeinsam, ob und wie Ihr Projekt zu WZ-IT passt.
Timo Wevelsiep & Robin Zins
Geschäftsführer
