Gotify vs ntfy

Gotify and ntfy solve the same small but genuinely useful problem: getting a push notification to your phone the moment a backup finishes, a server reboots, or a cron job falls over — without routing any of it through a third-party push service. Both are tiny Go servers you run yourself, both are light enough to forget about, and both do the job well. The decision comes down to how you want to send alerts and how many devices you want to receive them on: a tidy, token-based web app, or a curl-and-topics model that plugs into anything that can make an HTTP request.

The core difference: tokens vs. topics

Gotify is built around applications and tokens. You log into its web UI, create an "application," and it hands you a token; anything that wants to send a notification posts to Gotify with that token. It is a clean, self-contained model — every source of alerts is a named app with its own credential, and the web dashboard shows them all in one place.

ntfy is built around topics. A topic is just a name in a URL, and you publish to it with a one-line request — curl -d "backup done" http://your-server/mytopic is a complete, working notification. There is no app to create first and no token to mint for the basic case (you can add access control and auth when you want it). That difference sounds cosmetic but it is the whole personality of each tool: Gotify wants you to register a sender, ntfy wants you to just publish.

For anyone wiring alerts into shell scripts, cron jobs, or CI, ntfy's model is simply less friction — it turns curl into a notification pipeline you can drop into a one-liner anywhere.

Subscribing: one app vs. anything

The send side is only half the story; the receive side is where ntfy stretches its lead. Gotify delivers to its own Android client (and the web UI) via a persistent WebSocket connection. It works reliably, but you are subscribing through Gotify's app on Gotify's terms.

ntfy is designed to be subscribed to from almost anywhere: its own Android and iOS apps, any web browser pointed at the topic URL, or a plain curl holding the connection open for scripting. Because a subscription is just an HTTP stream on a URL, you can consume notifications programmatically as easily as you send them. If you want alerts on multiple platforms — including an iPhone — or want to react to them in code, ntfy reaches further out of the box.

Where Gotify pulls ahead: the admin UI

This is the one column that goes the other way, and it is a real point in Gotify's favor. Gotify ships a full web UI: log in, see every application, read message history, manage clients and tokens, all from a polished dashboard. It feels like a finished little product for managing your own alerts.

ntfy's web interface is deliberately minimal — it is excellent for subscribing to a topic and firing test messages, but it is not an administrative console in the same way. Management leans on a config file and the command line rather than a point-and-click dashboard. If you specifically want a graphical place to see and organize everything, Gotify is the nicer home; if you treat notifications as plumbing you configure once and forget, ntfy's sparseness is a feature rather than a gap.

Resources and stack

Here the two are effectively identical, and that is the easy part of the choice. Both are single Go binaries with no external database to run — Gotify uses SQLite by default, ntfy stores to a small local cache and config — so both are rated at a 256 MB RAM floor and 2/5 difficulty. Either one starts in a single container in a couple of minutes and then sits quietly using almost nothing. Licensing differs only slightly and permissively: Gotify is MIT, ntfy is Apache-2.0. Neither the footprint nor the license should tip your decision — this is genuinely a choice about the sending and receiving model, not the runtime.

Which should you self-host?

Pick ntfy if…

• You want to fire notifications straight from scripts, cron, or CI with a one-line curl to a topic, with no app to register first.
• You want to subscribe from many places — Android, iOS, the web, or another script — rather than through a single vendor app.
• You like the pub/sub model and are happy managing the server from a config file instead of a heavy dashboard.

Pick Gotify if…

• You want a tidy web UI to see every application, token, and message in one place.
• The per-app token model — one named credential per source — fits how you think about organizing alerts.
• You mainly notify your own Android device and value a polished, self-contained little server over maximum flexibility.

Running either on a VPS

Both run comfortably on the smallest server you can rent — a single Go binary in 256 MB, no database daemon to feed, and next to nothing to maintain once it is up. There is no meaningful resource gap between them, so let the send-and- receive model decide rather than the spec sheet: ntfy for curl-friendly topics you subscribe to from anywhere, Gotify for a token-based server with a proper dashboard. The step-by-step setups are linked below, and any of the VPS options here has ample room to run either alongside the other services you are already hosting.