You found ntfy. You read the docs. You tried curl -d "done" ntfy.sh/my-topic and it worked. Then you realized ntfy.sh is a shared public server with no auth, and standing up your own ntfy instance means a VPS, a domain, a reverse proxy, TLS, and something watching all of it at 3am when it falls over.

For a lot of use cases, that’s the right tradeoff. For a lot of others, it isn’t.

Here’s what the real options look like.

#ntfy: the baseline

ntfy is genuinely good. Free, open-source, an Android app that works, iOS support that’s improved. The public server at ntfy.sh is usable for low-sensitivity notifications — anything you’d be comfortable making world-readable, since topics are just strings with no auth by default.

curl -d "Backup done" ntfy.sh/your-topic

Self-hosting gets you access control, persistence configuration, and attachment storage. The tradeoff is you’re running a service. That’s fine if you’re already running services. If you’re not, it’s a new thing to operate.

#Gotify: ntfy but more self-hosted

Gotify predates ntfy. It’s also open-source, also requires self-hosting, and also has decent apps. The API is slightly more structured — you create applications, get tokens, post to /message.

If you want something you can host on a home server with a Docker Compose file and mostly forget about, Gotify is solid. The Android app is fine. The iOS story is worse — no official iOS client, and third-party options are thin.

Choose Gotify if you’re already running home infrastructure and Android is your phone.

#Pushover: simple, paid, zero ops

Pushover charges a one-time $5 per platform (iOS, Android). You get an API key, you POST to their endpoint, notifications land. That’s it. No hosting, no TLS cert to renew, no server.

The API is slightly more verbose than ntfy — you need to pass your user key and app token — but it works reliably and the apps are polished. The iOS integration is native, not a web push hack.

The ceiling: $5 is cheap, but it’s a closed service with a modest feature set. No metadata filtering, no feed history that’s easy to query, no SDK.

Choose Pushover if you want zero ops and don’t mind paying $5.

#Bark: iOS-native, self-hostable

Bark is iOS-only by design — it’s built around APNs. You install the Bark app, get a device key, and send to it directly. You can self-host the Bark server or use their public one.

The limitation is obvious: one device, iOS only. If you want to notify a team or support Android, Bark doesn’t fit. If you want notifications on your own iPhone with no account, no email, and minimal setup, it’s elegant.

#trigger.fyi: zero setup, cloud, anonymous

trigger.fyi is the option if you want a working notification in under 60 seconds and no interest in operating anything.

npx trigger.fyi mints a key, subscribes your device, and starts showing events in a live TUI. Then from anywhere:

curl -X POST -d "Backup done" https://trigger.fyi/fyi_your_key

No topic param. The key is the channel — one key per service, one env var, done.

The SDK wraps this:

import fyi from "trigger.fyi";
await fyi("Backup done");

It never throws, never blocks the caller, and reads TRIGGER_FYI_SECRET_KEY at call time. On serverless, pass it to waitUntil or just await it — one edge roundtrip, can’t fail your request.

There are honest limits: iOS web push can’t break silent mode, so fyi.critical() degrades to a normal notification there. The feed keeps 30 days. Titles cap at 200 characters.

#Which one

If you want to own your infrastructure: ntfy or Gotify. ntfy if you’re starting fresh; Gotify if you’re already running Docker Compose services at home.

If you want iOS-native with no account: Bark.

If you want zero ops, don’t mind $5, and want rock-solid reliability: Pushover.

If you want zero ops, free, and notifications working before you finish your coffee: trigger.fyi.

The distinction isn’t which is better. It’s how much infrastructure you want to own.