Self-hosted vs hosted push notifications: which should you use?

There are two ways to get a notification from your code to your phone. Run the infrastructure yourself, or pay someone to run it. Both are legitimate. Which one is right depends less on the technology and more on how you value your time, how much control you need, and whether you're prepared to be on-call for your own notification server. Let's break it down by what actually matters.

What "self-hosting" really involves

Self-hosting usually means one of two things. The common, sane version is running an open-source relay like ntfy on a VPS: you get pub-sub over HTTP, published messages fan out to subscribed devices, and there are polished mobile apps so you don't have to build one. The heroic version is rolling your own — talking directly to Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM), managing device tokens, and shipping your own app to hold them.

The first is very doable for a hobbyist. The second is a real project. It's important not to conflate them when someone says "self-hosting is easy" — they almost always mean running ntfy, not implementing APNs from scratch.

Cost: cheaper in dollars, not in hours

On paper self-hosting wins. A small VPS is a few dollars a month, ntfy is free and open source, and there's no per-message pricing. If you already run a server for other things, the marginal cost rounds to zero.

But dollars aren't the whole bill. Count the hours: initial setup, DNS, TLS certificates and their renewals, OS and package updates, the occasional "why did it stop delivering" debugging session, and the migration when your VPS provider deprecates something. None of it is hard individually; collectively it's a small standing tax on your attention forever. A hosted service folds all of that into a subscription — Lert's Pro is $2.99/mo — and the honest question is whether your time is worth more than the difference.

The cheapest server is the one you don't run. "Free" self-hosting is free the way a puppy is free.

Maintenance and reliability: who gets paged when it breaks?

This is the pivotal question and it's easy to skip past. When you self-host your notifications, you are the reliability engineer for the very system whose job is to tell you when things break. If your VPS goes down at 2am, your alerting is down at 2am — precisely when you'd want it. There's a grim irony in the monitoring server needing monitoring.

A hosted provider runs redundancy, handles APNs/FCM connection management, absorbs Apple's periodic changes, and — critically — is not something that pages you when it hiccups. You're trading control for the guarantee that maintaining the pipe is someone else's job. For personal and indie use, that trade is usually the right one, because your notification channel failing silently is a worse outcome than almost anything else it could do.

Privacy: real, but read the iOS asterisk

Privacy is the strongest honest argument for self-hosting. Your server, your logs, your data-retention policy, no third party in the loop. For sensitive alerts where the content matters, that control is genuinely valuable, and if it's a hard requirement it can settle the decision on its own.

But there's an asterisk everyone should know: on iOS, a real push notification always transits Apple's APNs, no matter who runs the server. Apple is structurally in the delivery path for every iOS push in existence. So "the notification never touches anyone else's infrastructure" is not fully achievable on an iPhone — self-hosting gets you control over everything except that final Apple hop. If you need content secrecy end to end, the answer isn't self-hosting the relay; it's not putting secrets in the notification body in the first place.

The iOS reality nobody warns you about

Here's where a lot of "I'll just self-host" plans hit a wall. Getting a true push to a locked iPhone — one that wakes the screen and buzzes a paired Apple Watch — requires going through APNs, and APNs requires:

• An Apple Developer account ($99/year).
• Push keys or certificates, correctly configured and periodically maintained.
• A compiled iOS app installed on the device to receive the token and register for pushes.

That last one is the kicker: you can't get a native iOS push without an app on the phone. This is exactly why self-hosters use ntfy's app rather than rolling their own, and why a raw "APNs from my server" project is far bigger than it first looks. A hosted service like Lert exists to eat this entire problem — its app holds the token, its backend talks to APNs, and you just POST a URL. The simplest way to send yourself a push is largely simplest because someone else already solved the iOS delivery path.

A straight recommendation

No hedging — here's who should pick what.

Self-host if…

• Data control is a genuine requirement, not a preference — regulated content, strict residency rules.
• You already run servers and enjoy it; the marginal effort is low and the tinkering is a feature, not a chore.
• You want to own the whole stack on principle and accept the on-call reality that comes with it.
• ntfy's model fits and you're happy self-hosting the relay while still riding Apple's APNs on iOS.

Use a hosted service if…

• Your goal is to get notifications working and never think about them again.
• You're a solo dev or indie maker whose time is better spent on your actual product.
• You want native iOS pushes without touching Apple Developer accounts, certificates, or app-building.
• You'd rather your notification channel not be one more thing that can page you at 2am.

If you land on hosted, we obviously think Lert is a strong pick — one URL, no keys, native iOS delivery, and honest pricing — but we'd rather you choose well than choose us. We even maintain a Lert vs ntfy comparison that's fair to ntfy, because ntfy is genuinely good and the right answer for a lot of people. The worst outcome is picking self-hosting for the romance of it, letting the server rot, and discovering your alerts stopped working three weeks ago. Choose the option you'll actually maintain — for most individuals, that's the one they don't have to.