ntfy Alternative: Hookfire vs ntfy

Hookfire vs ntfy

ntfy is open source, self-hostable and very cheap to run. That is a real answer, and here is when it is the wrong one.

Let us get the honest part out of the way first, because burying it would be the tell that this page is not worth reading: ntfy is free, it is open source, and you can run it yourself on hardware you already have. Hookfire is a hosted product you pay for. On cost and on control, ntfy wins, and no feature row changes that.

What it buys you is a pipe. `curl -d "Backup finished" ntfy.sh/your-topic` is about as short as a notification can get, and for alerts coming out of your own scripts and servers there is very little reason to want anything more elaborate. It also carries features Hookfire does not have: action buttons on a notification, attachments, and delayed delivery that holds a message until later.

The gap opens when the event is not yours. A topic accepts whatever is published to it, so somebody has to stand between the provider and the topic: receive the webhook, verify that it really came from Stripe, dig the amount out of the JSON, format it, and publish the result. That somebody is a small service you write, host and keep running, and it is running on the machine whose failures you were hoping to be alerted about.

Hookfire is that middle piece, already written, for 33 providers. Each one ships its event list, its signature scheme, a setup guide and a notification template per event. The honest framing is not "better than ntfy". It is that you are buying the translation layer and the hosting of it, and if you are happy to write and run that yourself, ntfy plus a hundred lines of your own code is a perfectly good system.

Where they differ

The shape of each tool rather than its price list, because that is the part that is still true next quarter.

	ntfy	Hookfire
Where it runs	The public instance, or your own server, since the code is open source	Hosted. Nothing of yours to run, patch or monitor
Licence	Open source	Proprietary, and not self-hostable
Cost	Free to self-host; the public instance is free to use, with a paid tier for higher limits	Paid, after a 7-day trial that includes every Max feature
What you publish to it	Any message, from curl or your own code, to a topic	Nothing: a provider posts its webhook and the source's template writes the notification
Who understands the provider	You do, in whatever sits between the webhook and the topic	The source definition does, for 33 providers
Verifying the sender	The topic name is the shared secret; access control on your own instance	Each provider's own signature scheme, checked against the raw body
Action buttons	view, http and broadcast actions on a notification	Not yet; there is a tap-through link to the payment or the pull request, but no buttons
Delayed delivery	A message can be held and delivered later	Not supported

What you would otherwise be writing and running yourself

33 providers already mapped

Including which events exist, how the provider signs its requests, and what each notification should say: the part that would otherwise be your code.

Filter rules on the payload

"Only charges over $500", "ignore test-mode events". A condition evaluated on the body before anyone is interrupted, with a missing value counting as false so an odd payload sends nothing.

Delivery history and replay

Every delivery recorded with its status, a view of just the failures, and a replay that re-runs one against the current templates.

Team routing

Per-person choice of push, inbox or email per integration, plus Slack, Discord and Teams channels on Max.

Silence alerting

An integration that was delivering and has stopped is itself an alert: the one failure nobody notices on their own, and the one a self-built pipeline almost never covers.

Choose ntfy if

ntfy is an open-source pub-sub notification service. You publish a message to a topic over HTTP and every subscriber to that topic gets it, on a public instance or on a server you run yourself.

You already run infrastructure and one more container is nothing. Self-hosting means no per-seat cost and no third party holding your payloads.

Your alerts come out of your own scripts and servers. Publishing to a topic with curl is the shortest path that exists and nothing here improves on it.

Open source matters to you on principle, or a policy requires the data to stay on machines you control.

Budget is the binding constraint. ntfy's cost is very hard to argue with and pretending otherwise would be dishonest.

You need action buttons or delayed delivery, both of which ntfy has and Hookfire does not.

Choose Hookfire if

33 providers already mapped and verified, turned into notifications a person can act on.

Nobody on the team wants to run, patch and monitor the service whose job is telling you when things break.

The events are third-party webhooks, and writing a verifying, parsing translator per provider is work you would rather not own.

You want the provider's signature checked properly rather than relying on a secret topic name.

You want to see afterwards whether an alert arrived, how long it took, and replay it if it did not.

Several people need different things from the same integration, including a team channel.

What self-hosting actually costs

Worth pricing honestly, because "free" is true of the licence and not always of the arrangement. Running ntfy is a server, a TLS certificate, upgrades, a push relay for iOS, backups of the config, and the question of who gets paged when the thing that pages people is down. For a team that already runs servers this is genuinely near zero. For a solo founder without infrastructure, it is a new small system to own.

The other cost is the translator. Every provider you want alerts from needs code that receives its webhook, verifies its signature correctly (the subtle part, including comparing digests in constant time and using the raw body rather than a re-encoded one), pulls out the fields that matter and formats them into a sentence worth reading. That is the work Hookfire has done 33 times, and it is the actual thing being bought here.

If you land on ntfy after reading this, that is a reasonable outcome. It is a good piece of software and a comparison page that could not say so would not be worth writing.

Common questions

Is Hookfire open source or self-hostable?

Neither. It is a hosted product. If either is a requirement, ntfy is the better fit and that is the end of the comparison.

Could I use ntfy as a destination for Hookfire?

Indirectly. Hookfire can forward a verified webhook on to any HTTPS endpoint you control, signed with a per-destination secret, so something of yours could receive that and publish to a topic. Hookfire does not publish to ntfy directly.

Does Hookfire have action buttons?

Not yet. Notifications carry a tap-through URL built from the payload (the Stripe payment, the GitHub pull request), which covers the common case of wanting to get to the thing itself, but there are no separate buttons.

What about scheduled or delayed delivery?

Not supported. What exists instead is the other direction: quiet hours, snooze and mute decide when an alert should not interrupt you, while still recording it.

Where are the webhook payloads kept?

They are stored so that deliveries can be replayed and the history read, and history retention depends on the plan. The privacy page sets out what is kept and for how long.