Apprise vs ntfy for Homelab Notifications: One Library for Every Service or One Push App

Sooner or later every homelab grows a notification problem. The backup script wants to tell you it failed, the uptime checker wants to tell you a container is down, the media server wants to announce a new episode, and the UPS wants to scream about a power cut. Each tool has its own list of supported notification services, and none of the lists match.

Apprise and ntfy are the two names that come up most when people try to fix this, and they are often mentioned as if they were alternatives. They are not quite. Apprise is a translator that speaks to almost every notification service there is. ntfy is a notification service, one you can host yourself, with its own phone apps. I run both, and the useful question is not which one wins, but which job each one should do in your setup.

A translator and a destination

Apprise is an open-source Python library and command-line tool that sends a message to more than a hundred services through one consistent format. Each destination is written as a URL: one for Telegram, one for Discord, one for email, one for Pushover, one for ntfy, and so on. Your script calls Apprise with a message and a list of URLs, and Apprise handles each service’s API. It does not deliver anything to your phone by itself. It hands the message to services that do.

ntfy (pronounced “notify”) is a publish-and-subscribe notification server. You send an HTTP request to a topic, and every phone, browser or computer subscribed to that topic gets a push notification. It has apps for Android and iOS and a web interface, and you can use the public ntfy.sh server or run your own with a single binary or container. Sending a notification can be as simple as a curl command with the message as the body.

Why Apprise exists

The real value of Apprise is that many homelab tools already have it built in. Healthchecks.io, changedetection.io, several of the *arr media apps, and plenty of smaller projects accept Apprise URLs as their notification setting. Home Assistant has an Apprise integration. When a tool supports Apprise, it supports every destination Apprise supports, without the tool’s developers writing a single extra integration.

For your own scripts, Apprise saves you from writing code for each service. A backup script can notify you with one line, and moving from Telegram to Discord later means changing a URL, not rewriting the script. You can also send to several destinations at once, for example a chat channel for the record and a push app for anything urgent.

Apprise also has an optional API server, a small container with a web interface. It lets tools that only know how to make HTTP requests use Apprise, and it lets you store sets of destination URLs under a name, so a dozen scripts can say “notify the alerts group” without each holding the credentials.

Why ntfy exists

ntfy solves the other end: getting a message onto your phone reliably, without signing up for a commercial service. Self-hosted, it keeps your alerts on your own infrastructure. Its features are aimed squarely at alerting:

• Priorities. Messages carry a priority from 1 to 5. The highest can be set to make a louder sound or break through quiet settings on your phone, so a dead disk does not look like a finished download.
• Tags, titles and click actions. A notification can open a URL when tapped or show buttons that trigger HTTP requests, for example “restart container”.
• Attachments. Send a log file or a camera snapshot with the message.
• Access control. On your own server, users and per-topic permissions keep strangers from reading or sending to your topics. On the public server, anyone who guesses a topic name can subscribe, so use long, random names there or reserve topics on a paid plan.

The way ntfy delivers to phones differs by platform. On Android, the app can hold its own connection to your server for instant delivery, or use Google’s push service through ntfy.sh. On iOS, Apple only allows push through its own service, so a self-hosted server relays a wake-up signal through the public ntfy.sh instance, which then lets the app fetch the message from your server. That works well, but it means iOS alerts depend partly on ntfy.sh staying reachable.

I compared ntfy with commercial and self-hosted push apps in ntfy vs Pushover vs Gotify; the short version is that ntfy is the most flexible self-hosted option, and Pushover is the most reliable “just works” paid one.

They work best together

Since Apprise can send to ntfy, the two combine naturally. A tool that supports Apprise points at an ntfy URL, and your phone gets a proper push notification with priority and tags. Your own scripts call Apprise and fan out to ntfy for the phone, plus email for a permanent record. If you ever leave ntfy, you change one URL in Apprise instead of reconfiguring a dozen apps.

A layout that works well in a small homelab:

1. Run ntfy on a machine that stays up when the rest of the lab does not.
2. Run the Apprise API container next to it, with a stored configuration for “alerts” and one for “info”.
3. Point every tool that supports Apprise at those configurations, and every tool that only supports webhooks at ntfy directly.
4. Keep scripts simple: a single HTTP request to ntfy, or one Apprise call.

When ntfy alone is enough

If your notifications come mostly from your own scripts and from tools that support webhooks or ntfy directly, you may not need Apprise at all. Uptime Kuma, Home Assistant, Proxmox, Grafana, many backup tools and a long list of others can send to ntfy directly or through a generic webhook. A curl line at the end of a cron job covers the rest. Fewer moving parts means fewer things to break.

ntfy alone also suits households where several people need different alerts: each person subscribes to the topics they care about in the app, and nobody needs an account with a chat service.

When Apprise alone is enough

If you already live in a chat app, such as Discord, Telegram, Matrix or Slack, and you are happy for alerts to arrive there, Apprise can send straight to it without any notification server of your own. That is one less service to host. Many people send informational messages to a chat channel and only use a dedicated push app for alerts that must wake them up.

Apprise is also the better choice when the requirement is “notify these five different places”, such as email for the audit trail, a team chat channel and a family member’s push app, from a single call.

The alert that never arrives

The hardest notification problem is not formatting, it is the alert that never sends because the thing that sends it is down. If ntfy runs on the same server as the services it watches, a power cut or a crashed host takes the alert path down with everything else. I have written about that trap in ntfy on the same box as Kuma.

Neither Apprise nor ntfy fixes this on its own. The fixes are about placement and checks from outside:

• Put the notifier somewhere else. A cheap VPS, a separate low-power device on its own power supply, or the public ntfy.sh for critical alerts.
• Watch the watcher. An external heartbeat service, such as a free Healthchecks.io check, notices when your monitoring stops checking in and alerts you through a path that does not touch your lab.
• Test monthly. Send a test alert at the highest priority and confirm it reaches each phone, especially after app or OS updates that may change notification permissions.

Apprise helps here in one specific way: sending the same critical alert through two unrelated paths, for example your own ntfy and a commercial service, is a one-line change, so one failure does not silence you.

Setting up each in an afternoon

ntfy is quick to deploy: one container or binary, a configuration file with a base URL, authentication turned on with default access set to deny, and a reverse proxy with HTTPS in front. Create a user for yourself, give it access to your topics, subscribe in the phone app, and send a test with curl. Enable the cache and attachment settings if you want messages and files kept for phones that were offline.

Apprise is either a pip install on the machine running your scripts, or the Apprise API container if you want a central place for configuration. Write one URL per destination and test each with the command-line tool before wiring it into anything. Keep the configuration file private, since those URLs contain tokens and passwords for each service.

Picking the piece you are missing

Start from the problem you actually have. If alerts are not reaching your phone in a way you trust, ntfy is the missing piece: a self-hosted push service with priorities and apps. If your tools all speak different notification languages and you are tired of configuring each one, Apprise is the missing piece: one format that reaches everything.

Most homelabs that grow past a few services end up with both: Apprise as the router and ntfy as the phone’s front door. Put ntfy somewhere that survives the outage you are alerting about, and the combination covers almost everything a home setup needs.