Ntfy Hosting

How ntfy works

ntfy uses named topics as notification channels. A script or application publishes a message with an HTTP PUT or POST request, and subscribers receive it through the web application, mobile clients, command-line tools, or subscription APIs. JSON streams, server-sent events, raw streams, and WebSockets support different integration styles.

Messages can include titles, priorities, tags, actions, attachments, delays, and other supported fields. Topic names and access rules are therefore security controls rather than mere labels. In the current catalogue template, no authentication file, users, tokens, or access-control defaults are configured.

Key ntfy features

Official ntfy documentation states that a server is open by default: anonymous users can read and write any topic unless authentication and ACLs are configured. Because the current template leaves those controls unset, hosted topics must be treated as publicly readable and writable to anyone who knows or discovers the topic name. Do not publish passwords, access tokens, personal data, or confidential alerts.

The server persists its message cache and attachment directory, but phone and desktop clients remain separate. Email publishing, phone calls, upstream push relays, SMS, monitoring sources, and third-party notification accounts are not included. Application email is disabled, so mail-based publishing is not available through this hosted offer.

ntfy vs Pushover

ntfy provides a customer-hosted topic service where publishers and subscribers use HTTP endpoints and client applications. Pushover is a provider-operated notification network using application tokens, user or group keys, subscriptions, and managed client delivery through its commercial account system.

Pushover may suit users who want managed clients, user-key distribution, delivery groups, and a provider-run service. ntfy is more appropriate when simple topic URLs, open APIs, and server control are priorities, provided the operator configures access controls or accepts the exposure of an open topic service.

Who uses ntfy

Operators send job failures and service events, developers publish build or deployment notices, and households route automation messages to phones and desktops. Scripts can also subscribe to topics when a machine-readable notification stream is needed.

ntfy is not an incident-management roster, monitoring collector, secret-sharing system, or access-control service by default. The current open template is unsuitable for confidential notifications until the platform offers a reviewed authentication configuration.

Self-hosting ntfy: requirements and cost

ntfy use is driven by publish rate, topic count, retained cache, attachment volume, subscriber count, open connections, API streams, and download traffic. PostgreSQL and MariaDB are Not required in the catalogue because the template uses its local persisted cache and attachment storage.

On AvaHost, ntfy uses Plan 1 at €2. The hosted ntfy package includes one-click deployment, a custom domain with automated HTTPS, automatic application updates, and scheduled backups. The current catalogue template does not enable ntfy authentication or ACLs, so anonymous read/write access remains the upstream default. Treat topic URLs as public, avoid confidential content, and do not rely on obscurity. Client apps, email publishing, phone calls, SMS, monitors, and upstream delivery services are not included.