Apprise API

Last reviewed Sep 13, 2026 · 854 words

Here is the whole product in one command:

curl -X POST http://apprise:8000/notify/homelab \
  -d '{"title":"Backup finished","body":"restic completed in 14m"}' \
  -H 'Content-Type: application/json'

That request fans out to every service you have attached to the homelab key: a Telegram bot, a Discord webhook, an email, a Pushover token, a ntfy topic, whichever of the 100-plus destinations the Apprise library supports. Every script, container and monitor in your stack only ever needs to know that one URL. Apprise API is a 128 MB Python container that exists to make that sentence true, and understanding what it deliberately does not do is most of using it well.

Stateless or stateful: pick stateful with the lock on

The container, caronc/apprise, listens on port 8000 and offers two ways to work. Stateless: you post to /notify and include the destination URLs in the request body every time. That is fine for a one-off script, and it means the server holds no secrets, but it also means every caller carries your Telegram token. Stateful: you save a configuration under a key with /add/{key}, then callers post to /notify/{key} with only a title and body. The configuration lives in the /config volume, and the same key can be reused by 20 different services.

Two environment variables decide the security posture. APPRISE_STATEFUL_MODE can be hash (default, keys are hashed on disk), simple, or disabled. APPRISE_CONFIG_LOCK=yes prevents anything on the network from adding, changing or deleting configurations through the API once you have set them up, which I turn on the moment the keys are in place. Without it, anyone who can reach port 8000 can read back your notification URLs, tokens included. Keep the port on the LAN or behind your reverse proxy with authentication regardless.

Tags are the second trick. A configuration can label each destination, so /notify/homelab?tag=urgent sends to Pushover and SMS while an untagged call only goes to Discord. One key, several severities.

What it is not

The listing's cons are exact: it is a relay with no workflow logic. There is no scheduling, no conditions, no "only alert if this happens twice", no message templating beyond title and body, and no inbox to read messages later. If you want to route on content, delay, batch, or transform, that is n8n territory, and Apprise API becomes the last node in the n8n flow rather than the brain. It is also not a notification server in the sense of storing and displaying messages on your phone; that is the job of the destination.

Where it sits in a real stack

The pattern that works: everything that can emit an alert points at Apprise API, and Apprise API points at wherever you actually read alerts. Uptime Kuma has Apprise support built in, so a monitor going down triggers the same fan-out as your cron jobs. Home Assistant has an Apprise notify platform. Backup scripts, Watchtower, Diun, Sonarr's webhook, a CI pipeline, all end with the same curl. When you switch from Telegram to Signal next year, you change one configuration under one key and every producer follows without a redeploy.

The automation category is full of tools that each have their own notification settings page; Apprise API is the argument for filling those pages with a single URL.

ntfy and Gotify are destinations, not competitors

People compare Apprise API with ntfy and Gotify, and the comparison is a category error. ntfy and Gotify are self-hosted push services with their own phone apps: they receive a message and show it on your devices. Apprise API sends to them, and to 100 other places, from one entry point. The strongest homelab setup I know is Apprise API in front of ntfy for everyday alerts, with Pushover or email on a critical tag for the things that must wake you up. Running ntfy alone is fine until the third service that does not natively speak ntfy, at which point the relay pays for itself.

Running it

The compose block is short: the image, port 8000 mapped or proxied, a volume on /config, APPRISE_STATEFUL_MODE=hash and APPRISE_CONFIG_LOCK=yes once configured. The web UI on the same port is enough to build and test configurations. Back up the /config directory, since it holds every token you have entrusted to it, and treat that backup as a secret. Memory use sits in the low tens of megabytes, so it goes on the same host as everything else without a thought.

What I'd do

Deploy Apprise API on the LAN, create one key per household or team with tags for info and critical, attach ntfy for the former and Pushover or email for the latter, then lock the configuration. Point every monitor, script and container at it and stop configuring notification settings anywhere else. If you find yourself wanting rules or delays, add n8n in front rather than looking for those features here; they are not coming, and that restraint is why it is 128 MB.