Gotify Alternative: Hosted Push Without Running the Server
Gotify is a good self-hosted notification server. This is an honest look at what running it costs you, and when a hosted API is the better trade.
Gotify is a genuinely nice piece of software. A single Go binary, a small web UI, an Android app, a clean REST API, and no account with anybody. You run it, you own it, and it does exactly what it says.
So this is not a post about Gotify being bad. It is a post about the specific bill that self-hosting your alerting sends you, which is easy to underestimate at setup time and obvious eighteen months later.
Full disclosure before anything else: TheNotificationApp is ours. Read the rest knowing that, and note that the honest limitations are two sections from the end, not buried.
The thing that makes Gotify good is the thing that costs you
Gotify has no dependency on anyone. No account, no third party in the path, no company that can change its pricing or disappear. For a lot of people that alone settles it, and if it settles it for you then you should run Gotify and this post is not for you.
The cost is that your alerting is now infrastructure. Specifically:
- A server that has to be up. Alerting that is down when your infrastructure is down is not alerting. If Gotify runs on the same box as the thing it monitors, a hardware failure takes out both, silently.
- A domain and a certificate. The Android app needs to reach it from outside your network, which means a public hostname, TLS, and a renewal that must not fail.
- Updates. An internet-facing service you have not patched in a year is a liability, not a convenience.
- Its own monitoring. The genuinely awkward one. Who tells you when Gotify stops? You need a second channel to watch your first channel, and most self-hosted setups quietly never build it.
None of that is hard. It is about an afternoon to set up and then a low, permanent background cost that never quite goes away.
The iPhone problem
This is the practical dealbreaker for a lot of people, and it deserves to be stated plainly rather than discovered.
Gotify's official app is Android. There is no official iOS client. iPhone users end up with third-party apps of varying maintenance status, or a web app that cannot deliver a real background push notification, because iOS does not let arbitrary apps hold an open socket waiting for messages the way Android does.
That is not a gap Gotify can close by trying harder. Delivering a background notification to an iPhone means going through Apple's push service, which requires an Apple developer account, a certificate, and a server holding a persistent connection to Apple. A self-hosted-by-anyone architecture cannot do that on your behalf.
So if your phone is an iPhone, Gotify is fighting the platform. If your phone is an Android, this section does not apply to you and Gotify is in good shape.
The other approach
TheNotificationApp takes the opposite trade: it is hosted, it is iPhone only, and there is nothing to run.
curl -X POST https://thenotification.app/api/sendNotification \
-H "app_key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"title": "Backup failed",
"body": "db-01 exited 1 at 03:14",
"link": "https://logs.example.com/backup"
}'One endpoint, one header, four fields, two of them optional. Compare that with the Gotify equivalent, which is genuinely similar:
curl -X POST "https://gotify.example.com/message?token=YOUR_TOKEN" \
-F "title=Backup failed" \
-F "message=db-01 exited 1 at 03:14" \
-F "priority=8"The APIs are about equally pleasant. That is not where the difference is. The difference is that the second URL is a hostname you are responsible for.
Side by side
| Gotify | TheNotificationApp | |
|---|---|---|
| Hosting | You run it | Hosted |
| iPhone | No official app | Native, the only target |
| Android | Official app, good | Not supported |
| Cost | Free, plus your server | Free tier, then $2.99 a month |
| Auth | App tokens you manage | App key, or Sign in with Apple for MCP |
| Data location | Wherever you put it | Switzerland |
| Priority levels | Yes, 0 to 10 | No |
| Message history | Yes, stored and browsable | No, notifications are not stored |
| Works if your server dies | No | Yes |
Two features Gotify has that we do not
Worth naming clearly, because they are real and they might decide it for you.
Priority levels. Gotify messages carry a priority from 0 to 10, and the Android client maps that to how intrusive the notification is. A priority 2 informational message and a priority 8 alert behave differently on the device. There is no equivalent here: every notification arrives the same way, and separating urgent from routine is something you do by choosing what to send rather than by tagging it.
Message history. Gotify stores messages and you can browse them in the web UI, which is genuinely useful for going back and reading what fired overnight. We deliberately do not store notification content at all. That is a privacy decision and it is a real tradeoff: you get no archive, and there is nothing on our side to leak or subpoena. Which of those you want depends on whether your notification bodies contain things like customer emails and error strings.
What you get in exchange
Nothing to keep alive. No server, no certificate renewal, no update cadence, and no need for a second system to watch the first one.
It works when your infrastructure does not. The case that matters most and is easiest to overlook. If your alerting runs on your own hardware, a power cut takes out the alerting and the thing it was watching, at the same moment, silently. A hosted endpoint is unaffected by your rack.
Sign in with Apple, not a token in a config file. For the MCP connector there is no key to generate or paste. Details in why Sign in with Apple beats API keys for MCP connectors.
Swiss hosting. Data sits under Swiss law and notification content is not stored. The reasoning is in why Swiss-hosted push notifications matter for developer privacy.
The honest limitations
iPhone only. No Android, no desktop, no web client. If you carry an Android phone, this is not a Gotify alternative for you, it is a different product for different people, and Gotify is the right answer.
You depend on us. That is the deal you are making, and it is precisely the thing self-hosting exists to avoid. If you would rather own the entire pipe, that is a legitimate engineering position and Gotify serves it well.
The free tier is a trial, not a budget. 100 notifications for the lifetime of the account, not per month. Enough to wire up a couple of real alerts and see whether you like it. Pro is $2.99 a month for 1,000 notifications, which is a real cost against Gotify's zero, offset against a server you no longer run.
No priorities, no history. Covered above. If either is load-bearing for you, Gotify wins on features.
Which to pick
Stay on Gotify if: you carry an Android phone, you already run a homelab with a domain and TLS and monitoring, you want message history, or you have a firm position on not depending on third parties. All good reasons.
Switch if: your phone is an iPhone and you have been fighting third-party clients, or your Gotify instance runs on the same infrastructure it is supposed to be watching, or you set it up two years ago and have not updated it since, which is the honest state of most self-hosted alerting.
The migration is one URL. Wherever you POST to Gotify, POST the JSON body above instead. There is no data to move, because there is no state to move, which is the one nice thing about a system that only ever forwards messages.
The full field list is in the API reference, and if you are weighing several options rather than these two, there is a wider survey in the best push notification APIs for developers.
