Both do the same thing at the core: POST text, get a push notification. Here’s where they actually differ.

#The API is almost identical

ntfy:

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

trigger.fyi:

curl -X POST trigger.fyi/your-key -d "Deploy done"

Both are a single curl command. The difference is what’s behind it.

#Topics vs keys

ntfy uses topics — strings that anyone can publish or subscribe to if they know the name. The public server (ntfy.sh) has no auth by default. Your topic my-deploy-notifications is world-readable and world-writable. That’s a deliberate tradeoff in ntfy’s design; the self-hosted version adds access control.

trigger.fyi uses keys — opaque random tokens. Knowing the key gives you send access. The PWA subscribes your device without a separate credential. The server only stores a hash of the key — it’s never recoverable.

ntfy: open by default, privacy through obscurity, self-host for real access control. trigger.fyi: private by default, key possession = send access.

#Infrastructure

ntfy offers two options: the public shared server (ntfy.sh) or self-hosting. Self-hosting gives you private topics, persistence configuration, and attachment storage. It also means you’re running a service — VPS, TLS, updates, uptime.

trigger.fyi is cloud-only. No self-hosting option. You don’t run anything.

ntfy: control and privacy at the cost of ops overhead. trigger.fyi: zero ops, no infrastructure decisions.

#iOS experience

ntfy’s iOS app exists and has improved, but has historically had reliability complaints — the iOS background push constraints are real and ntfy’s app-based delivery is subject to them.

trigger.fyi uses Web Push (PWA), which requires installing the app to the home screen on iOS 16.4+. The setup is slightly more friction, but once installed, delivery is direct through the Web Push stack. There’s a built-in troubleshooter that walks through the failure modes in order.

Neither is perfect on iOS. Native apps with APNs are the reliable path; both products are working within the same web constraints.

#Feed and history

ntfy has a message history in the app and a web UI. The history is per-topic, configurable retention.

trigger.fyi has a live feed TUI (npx trigger.fyi) and 30 days of history in the PWA. Metadata is filterable — filter by plan: pro or env: prod.

#SDK and levels

ntfy has a rich API with priority, tags, click actions, and attachment support.

trigger.fyi has three levels: fyi() (normal), fyi.log() (feed only, no push), fyi.critical() (urgency high). The npm SDK is fire-and-forget, never throws, serverless-safe.

ntfy’s priority maps roughly: min/low → fyi.log(); default → fyi(); high/urgent → fyi.critical().

#Onboarding

ntfy: install the app, pick a topic name, subscribe, send.

trigger.fyi: npx trigger.fyi — generates a key and subscribes the terminal. Scan QR to add phone. No app install required to start.

#Which to choose

Choose ntfy if:

• You want to self-host
• You need Android-first reliability
• You’re OK managing a service
• You want open-source everything

Choose trigger.fyi if:

• You want zero infrastructure
• You’re in a Node.js/edge codebase and want an SDK
• You want the fastest path to a first notification (one key, one curl)
• You want feed filtering and metadata

Both are honest products solving the same problem. The choice comes down to whether you want to own the infrastructure.

Related: trigger.fyi vs Pushover · ntfy alternatives · What is trigger.fyi?