how did I NOT know about this?

Push notifications stop being “something for apps” and turn into a practical automation layer once ntfy is set up as a self-hosted notification server. The core payoff: long-running tasks—Nmap scans, large file downloads, package installs, backups, even server reboots—can trigger instant alerts to a phone (and more), so waiting becomes optional.

The walkthrough starts with the simplest mental model: ntfy runs as a Docker container, whether it’s hosted in the cloud, on a home Linux machine, or even on a Raspberry Pi. For cloud hosting, a virtual machine is provisioned quickly (the example uses Anode, with Ubuntu 20.04), then Docker is installed and the ntfy container is launched on port 80. For on-prem setups, the steps are essentially the same as long as the host is Linux-based. After the container is running, the ntfy web interface becomes reachable via the server’s public address (cloud) or local IP (home).

A key distinction follows: cloud instances are publicly accessible, but home servers usually aren’t. To make a home ntfy endpoint reachable from anywhere without opening router ports, the guide uses Cloudflare tunnels. A Cloudflare Zero Trust tunnel is created, a subdomain is mapped to the home machine’s internal IP, and the tunnel runs via a Docker command generated by Cloudflare—so the home ntfy service can be called from the internet securely.

With the server reachable, the next step is installing the ntfy mobile app on Android or iPhone and pointing it at the chosen ntfy server. Notifications are organized by “topics” (for example, a topic named “coffee”). Subscribing to a topic is done in the app, and messages are sent from any terminal using curl by POSTing a message to the topic endpoint (e.g., sending “Hey, the coffee is ready” to /coffee). The web interface also shows topic subscriptions and delivered messages, and the system supports access controls so not everyone can subscribe.

iPhone push delivery needs an extra configuration tweak. The container is stopped, an ntfy server.yml configuration file is created, and the base URL is set to the correct server address. Then an “upstream base URL” setting is adjusted to work around iOS’s quirks: iOS receives only message IDs and pulls the content from the user’s own ntfy server, enabling reliable push notifications.

Once notifications work, the use cases expand fast. Command output can be captured into variables and sent when a command finishes (including Nmap results). Conditional alerts are demonstrated with shell logic using success/failure operators around ping checks—sending “it’s up” or “it’s down” depending on reachability. Scheduling can be handled either by Linux cron/systemd or by ntfy’s built-in scheduling syntax (e.g., “in 10 seconds” or “next Tuesday”). The guide also shows monitoring-style patterns: repeatedly pinging a host until it returns after downtime, adding emojis to alerts, and integrating with Uptime Kuma via ntfy as a notification target. Finally, it’s applied to battery monitoring using a PowerShell script that triggers an ntfy message when battery drops below a threshold.

The result is a flexible, self-hostable notification system that turns routine automation and troubleshooting into something you can track in real time—without babysitting terminals.