Notification service
ntfy, its configuration, cache and attachments are deployed reproducibly and updated through controlled procedures.
We design, install and operate ntfy as a notification gateway - including HTTP API, topic permissions, clients, monitoring, backups and documented push paths.
The following are trademarks of their respective owners: ntfy (the ntfy project). WZ-IT is an independent service provider and has no business, partnership, or contractual relationship with these companies. We offer independent migration, installation, hosting, and operations services.
ntfy accepts messages through a simple HTTP publish-subscribe interface and delivers them to subscribed web, mobile and desktop clients. Scripts and systems can publish messages through PUT, POST, JSON or the CLI, among other options.
WZ-IT designs the reverse proxy and TLS, cache and attachments, users and topic ACLs, access tokens, rate limits, client access, Prometheus metrics and recovery as a cohesive operating path.
Delivery behaviour depends on the platform, client and server configuration. For instant iOS notifications, a self-hosted ntfy server needs an upstream connected to Firebase and APNS; the official flow sends a poll request and then retrieves the actual message content from the self-hosted server.
We clarify which clients and push paths are required, whether external push infrastructure is acceptable, and how topic names, logging, retention and permissions should be designed. This keeps the technical data-flow decision transparent.
Production ntfy operations involve more than an HTTP endpoint. We connect TLS and reverse proxy, topic access, cache, attachments, clients, push paths, rate limits and monitoring into a documented notification path.
ntfy, its configuration, cache and attachments are deployed reproducibly and updated through controlled procedures.
Users, tokens and read or write permissions are configured for private or deliberately public topics.
HTTP publishers, clients and platform-specific push dependencies are integrated transparently.
Health checks, Prometheus metrics, updates, backups and capacity limits are integrated into operations.
We distinguish technical message transport, integrations and business escalation decisions.
| Area | Responsibility | Scope and boundaries |
|---|---|---|
| Architecture and deployment | WZ-IT | ntfy, TLS, reverse proxy, persistent cache, authentication data, attachments and reproducible deployment. |
| Runtime and updates | WZ-IT | Maintenance of the agreed instance with version review, backups and controlled updates. |
| Monitoring and backups | WZ-IT | Monitoring health, resources and delivery paths and protecting the agreed persistent data. |
| Publishers and integrations | Shared | WZ-IT connects systems technically; the customer supplies events, credentials and the required notification logic. |
| Clients and external push paths | Shared | We document platform dependencies; the customer approves permitted clients and external push infrastructure. |
| Content, recipients and escalation | Customer | The customer is responsible for notification content, recipient groups, prioritisation and business response to messages. |
| Adapters and escalation workflows | Optional WZ-IT service | Custom publishers, middleware, response channels and multi-stage escalation are implemented as a separate module. |
Publish messages using PUT, POST, JSON, curl or the ntfy CLI and subscribe without an application-specific SDK.
Distribute notifications through topics and connect multiple web, mobile or desktop clients to defined channels.
Enrich messages with titles, priorities, tags, attachments, scheduled delivery and supported action buttons.
Configure user roles, access tokens and read or write permissions for individual topics or topic patterns on private instances.
Connect ntfy to monitoring, backup, automation and other systems through its HTTP interface and make use of available project integrations.
Integrate the health endpoint and optional Prometheus metrics into operations and monitor cache, delivery paths and resource usage.
A clearly defined operating scope instead of an opaque hosting flat fee.
Compute, applications, storage and response are shown separately. You can see what ongoing operations include and which requirements need a technical assessment.
We also design custom ntfy architectures, integrations and migrations. Contact us for a technical assessment.
One managed standard ntfy application is included in the Starter workload. Every service level also includes flexible expert time for planned work during regular service hours. Select compute, additional applications, storage and the appropriate service level.
A workload is one compute instance with the applications agreed for it.
One standard app per workload is already included. Additional dedicated servers count as separate workloads.
€79.90 per started TB and month, including daily encrypted offsite backup with 7-day retention.
User count is not the only factor. Message rate, parallel subscriptions, retention, attachments, WebSocket or long-poll connections and external push paths shape operations.
| Usage scenario | Technical starting point | Key factors |
|---|---|---|
| Internal system notifications without large attachments | S, persistent cache and auth data | A suitable starting point for a low message rate and few parallel subscriptions. |
| Multiple teams, monitoring systems and mobile clients | M, persistent data and separate attachment storage | Message rate, retention, attachments and required push paths are assessed beforehand. |
| Many persistent connections or traffic spikes | L or custom sizing | Proxy connections, file descriptors, rate limits, cache and client behaviour shape the architecture. |
| Business-critical alerting | Custom multi-channel architecture | ntfy, source systems, external push services, escalation and alternative notification paths must be considered together. |
Large attachment volumes, custom publishers, multi-channel escalation, high connection loads and special push architectures are not included in the general workload price.
ntfy can run as a managed workload or in a customer environment. Mobile push paths and possible external dependencies are documented beforehand.
Dedicated workload with agreed compute, cache, attachment storage, backups, monitoring and service level.
Operations in the customer's account with existing monitoring, network and security services integrated.
Operations in the internal network for local publishers and clients with controlled external access where required.
Internal publishers reach ntfy over private connections; mobile and external clients use defined public or private access paths.
ntfy sits between event sources and recipients. We document which data leaves the self-hosted server, how topics are protected and which delivery paths apply to each client platform.
Monitoring, backup, automation, applications, scripts and HTTP or CLI clients.
Public or private endpoints, correct proxy headers, WebSockets, rate limits and network rules.
Roles and read or write permissions for individual topics or patterns with restrictive default access.
HTTP publish-subscribe, topic distribution, cache, scheduled messages, attachments and web interface.
Persistent message history for the configured period as well as users, tokens and access rules.
Files with defined size, retention and bandwidth limits and agreed backup coverage.
Web, mobile and CLI clients, external push paths where required, health checks and Prometheus metrics.
For instant iOS delivery through the official app, a self-hosted instance needs an upstream connected to Firebase and APNS. The documented poll request does not contain the actual message content; the content is retrieved from the self-hosted ntfy server afterwards.
Answers about licensing, topic protection, the iOS data flow, integrations, backups and delivery boundaries.
Yes. The official ntfy repository states dual licensing under the Apache License 2.0 and GPLv2. WZ-IT operates the software as an independent service provider and checks modifications and redistribution against the applicable licence.
Yes, following a technical assessment. We review the version, configuration, authentication data, access tokens, cache database, attachments, reverse proxy, publishers and clients in use. The migration is planned with protected source data, a test instance and a controlled cutover; transient messages outside the configured retention period cannot be recovered retrospectively.
Publishers can use HTTP PUT or POST, JSON, curl and the ntfy CLI, among other options. We define the endpoint, authentication, topic, retry and error behaviour for every connected system.
No. ntfy is open by default. For private instances, we configure authentication, access tokens, topic ACLs and typically restrictive default access. The reviewed configuration, rather than a hard-to-guess topic name, provides the access boundary.
iOS restricts background processing. The official ntfy configuration therefore describes an upstream that wakes the app through Firebase and APNS. The self-hosted server sends a poll request containing the message ID and a derived topic value; the app then retrieves the actual message content from the self-hosted server.
The server, web interface and various direct subscription paths can be self-hosted. Mobile background delivery behaviour still depends on the operating system, client and configuration. Without the documented iOS upstream, notifications can arrive with a delay, so we establish the required clients beforehand.
Depending on the setup, we protect authentication data, access tokens, configuration, cache database and attachment storage. Message history is intended only for the configured cache duration; this does not automatically make ntfy a durable event queue or an audit-proof event archive.
Systems that support HTTP can generally publish messages. The project also documents numerous integrations and provides a health endpoint and optional Prometheus metrics. We review authentication, payload, error paths and rate limits for every connection.
A blanket delivery guarantee would not be credible because the source system, network, ntfy, client and potentially external push services are involved. For critical alerting, we design delivery-path monitoring, escalation rules and an independent secondary notification channel where required.
Whether you run ntfy in-house or need to host confidentiality-professional data §203-ready - we build, operate and maintain ntfy on an encrypted on-site server. Data never leaves the building in cleartext.
See ntfy on-premise
These solutions are often used together with ntfy
These solutions offer similar functionalities and can be evaluated together
No risk: worst case, you leave with a clearer understanding of your project than before.


“WZ-IT's advice on our Azure migration was technically sound and completely non-binding right from the intro call - we took away a great deal.”
Whether a specific IT challenge or just an idea - we look forward to the exchange. In a brief conversation, we'll evaluate together if and how your project fits with WZ-IT.
Timo Wevelsiep & Robin Zins
Managing Directors of WZ-IT
