Why Self-Hosted Push Notifications Make Sense
Push notifications have become the default way servers, scripts, and home lab tools communicate status updates to their owners. Most developers reach for services like Pushover or Pushbullet without thinking twice – but those services sit between you and your alerts, log your messages, and can disappear or raise prices at any time. Ntfy flips that dependency entirely. It is a free, open-source notification server you run yourself, and any HTTP client can send it a message with a single line of code.
The appeal is not just philosophical. Ntfy supports Android and iOS apps, a clean web UI, and a dead-simple API where sending a notification is as easy as a curl POST request. You can subscribe to topics, protect them with access tokens, and route alerts from cron jobs, Docker containers, monitoring scripts, or anything else that can speak HTTP. The setup takes under an hour on a basic Linux server, and once it is running you own the entire pipeline from sender to receiver.
What You Need Before Starting
The minimum requirement is a Linux server with a public IP address or a domain name pointing to it. A small VPS running Ubuntu 22.04 or Debian 12 works perfectly. You will need root or sudo access, and optionally a reverse proxy like Nginx or Caddy if you want HTTPS – which you should, since notifications often carry sensitive status data. Docker is also an option if you prefer container-based deployments, and Ntfy maintains an official image on Docker Hub.
If you are already running other self-hosted services on the same server, you likely have most of this infrastructure in place already. A server handling a monitoring stack like Netdata for real-time performance monitoring is an ideal candidate to also run Ntfy, since the two complement each other – Netdata detects the anomaly, Ntfy delivers the alert to your phone.
Installing and Configuring Ntfy
The quickest installation path on Debian or Ubuntu is through the official apt repository. Add the Ntfy GPG key and repository, then run apt install ntfy. On other distributions, you can download a pre-built binary directly from the GitHub releases page. Ntfy ships as a single static binary with no external dependencies, which makes it unusually straightforward to place anywhere on a system and run. Verify the installation with ntfy --version before moving forward.
Configuration lives in a single YAML file, typically at /etc/ntfy/server.yml. The most important settings at the start are base-url, which should match your domain or IP, and listen-http, which controls what port Ntfy binds to. Set base-url to your full public-facing address including the protocol – for example, https://ntfy.yourdomain.com. If you are using a reverse proxy, set the listen address to something like :2586 so Nginx or Caddy can forward traffic to it without port conflicts.
Authentication deserves attention before you open the server to the internet. By default, Ntfy allows anyone to publish and subscribe to any topic, which is fine for a local network but dangerous on a public-facing server. Enable access control by setting auth-default-access: deny-all in the config file, then use the Ntfy CLI to create users and assign them permissions. The command ntfy user add yourname creates a user, and ntfy access yourname mytopic rw grants that user read-write access to a specific topic. Tokens are another option – generate one per application or script so you can revoke access without changing passwords.
Once the config is ready, enable and start the service with systemctl enable ntfy and systemctl start ntfy. Check the logs with journalctl -u ntfy -f to confirm it is binding to the right address and not throwing errors. At this point the server is running, but it is only accessible over plain HTTP unless you add a reverse proxy layer in front of it.
Setting Up HTTPS With a Reverse Proxy
Caddy is the easiest option for adding HTTPS because it handles certificate issuance and renewal automatically through Let’s Encrypt. Install Caddy from its official apt repository, then create a simple Caddyfile at /etc/caddy/Caddyfile. The configuration block you need is minimal:
- ntfy.yourdomain.com – the site block directive
- reverse_proxy localhost:2586 – forwards traffic to Ntfy
Reload Caddy with systemctl reload caddy and it will automatically obtain a TLS certificate for your domain, provided DNS is already pointing to your server. Nginx works just as well if you are more comfortable with it – the proxy_pass directive pointed at http://127.0.0.1:2586 achieves the same result. Either way, after this step your Ntfy instance is reachable over HTTPS and your traffic is encrypted end to end.
Sending Notifications and Subscribing on Mobile
With the server running, sending a notification from any device or script is a one-line operation. The format is a POST request to https://ntfy.yourdomain.com/your-topic-name with the message content in the body. Using curl it looks like this: curl -d "Backup completed" https://ntfy.yourdomain.com/homeserver. For authenticated setups, pass the token as a header: -H "Authorization: Bearer tk_yourtokenhere". That single command is enough to fire a notification to every device subscribed to that topic.
The Ntfy Android app is available on F-Droid and Google Play. After installing it, go to settings and add your server as the default host by entering your domain in the server URL field. Subscribe to a topic by tapping the plus button and entering the topic name. The app supports notification priority levels, action buttons, and attachments, all of which you can set through HTTP headers on the POST request. Setting -H "Priority: high" bumps the notification to urgent delivery on Android. The iOS app works through the same mechanism but uses Apple’s push infrastructure to deliver notifications without requiring a persistent background connection.
For scripting use cases, Ntfy fits cleanly into cron jobs, backup scripts, CI pipelines, and home automation. A cron job that runs a database backup can append a curl call at the end to confirm success or alert on failure. Docker containers can POST to Ntfy using the host network. Even shell one-liners that monitor disk usage can pipe output directly into a notification. The entire interaction model is stateless HTTP, so there is no SDK to install, no library to import, and no vendor lock-in to navigate around.
One detail that catches new users off guard: Ntfy stores messages in memory by default, and they disappear on restart. If you need message history – useful when a notification fires while your phone is offline – enable the cache by setting cache-file: /var/cache/ntfy/cache.db in the config. Ntfy will then write messages to a SQLite database and serve cached notifications to subscribers who reconnect after missing them, configurable up to a retention window you define. Without this, a notification that fires during a network outage is simply gone.
