Self-hosted push notifications, honestly reviewed. No marketing fluff, just what you get when you run your own instance.

TL;DR

What it is: Open-source (Apache 2.0) HTTP pub-sub notification service — send alerts to your phone or desktop with a single curl command, no account required [README][2].
Who it’s for: Developers, homelab operators, and self-hosters who want to receive push notifications from scripts, cron jobs, CI pipelines, or monitoring tools without routing everything through a paid SaaS service [1][2].
Cost savings: ntfy.sh’s paid Pro plan starts at $10/mo. Self-hosted runs free on any VPS you already own, or on the same $5–6/mo droplet running your other services. The entire stack is a single Go binary [README].
Key strength: Absurd simplicity. Publishing is a curl -d "message" ntfy.sh/mytopic. No SDK, no account, no API key for basic use. 29,270 GitHub stars says this resonated [README].
Key weakness: The iOS app is acknowledged by the author himself as “bare bones and quite frankly a little buggy” [3]. Firebase Cloud Messaging is baked into the hosted service for Android delivery — if that matters to you, self-hosting with the F-Droid app is the privacy-preserving path [3].

What is ntfy

ntfy (pronounced “notify”) is an HTTP-based pub-sub notification service. You publish a message to a topic — a URL path like ntfy.sh/mybackups — and any subscriber (phone app, browser, or another script) instantly receives it. That’s the whole model [README].

What makes it different from every other push notification service is that there’s no required account, no SDK to install, and no proprietary protocol. The API is HTTP. Publishing is a POST request. Subscribing is a GET request with Server-Sent Events or WebSockets [README][2]. Any tool that can make an HTTP request — curl, wget, Python’s requests, a GitHub Actions step — can send a notification.

The project is the work of a single developer (Philipp Heckel), has been running since 2022, and has accumulated 29,270 GitHub stars while staying genuinely simple [README]. The hosted service at ntfy.sh runs on a DigitalOcean droplet with no scale-out strategy and best-effort uptime guarantees — the author says so explicitly in the FAQ [3]. That’s honest. For self-hosters, it doesn’t matter because you run your own.

The Apache 2.0 license means you can deploy it, embed it, and build on it without restrictions.

Why people choose it

The reviews tell a consistent story: ntfy wins because it gets out of your way.

The friction problem with other solutions. The alternatives — Pushover, Pushbullet, Gotify, Firebase directly — all require some combination of account creation, API key management, SDK integration, or platform-specific setup before you can send your first notification. ntfy’s answer is curl -d "Backup done" ntfy.sh/mytopic. Akash Rajpurohit’s review [2] opens with exactly this: months of successful use in a homelab monitoring setup, alerting on disk space, memory pressure, and backup completion. The value is in the zero-friction integration path.

Homelab and self-hosted infrastructure use case. Both detailed reviews [1][2] describe the same pattern: ntfy as the notification backbone for a self-hosted stack. William Donze’s guide [1] covers SSH login alerts, Minecraft server backup notifications with disk space checks, and Uptime Kuma integration — all via simple bash scripts that POST to a local ntfy instance. Rajpurohit [2] echoes this: monitoring scripts that only fire on problems, not on every healthy check. The philosophy he articulates — alert only when something is wrong, not on every successful run — fits ntfy’s model well because the tool doesn’t push you toward dashboards or aggregation. It pushes you toward targeted, actionable pings.

The “just works” testimonials. The homepage quote that the ntfy author chose to headline the site: “Hands down the best notification service I’ve ever used, and I have used them all.” That’s from a real user and reflects the pattern: people who’ve tried Pushover, Gotify, and Firebase-based solutions end up here because the setup is simpler and the self-hosted path is cleaner [website].

Privacy angle. The FAQ [3] doesn’t oversell this, which is refreshing: “If you don’t trust me or your messages are sensitive, run your own server. It’s open source.” The hosted ntfy.sh does log topic names and IP addresses for troubleshooting and rate limiting. If you’re sending sensitive alerts (unauthorized login attempts, internal system states), self-hosting is the right call — and the tool supports it fully.

Features

Core notification model:

Publish via HTTP PUT or POST — any HTTP client works [README][2]
Topics are created on the fly by publishing or subscribing; no pre-registration needed [website]
Server-Sent Events and WebSockets for real-time delivery [README]
Message polling for clients that can’t maintain persistent connections [3]
Messages cached server-side (12h default) to survive restarts and network interruptions [3]

Message richness:

Priority levels (min, low, default, high, max) that map to different sounds and vibration patterns [website][2]
Tags and emojis for classification [website]
Action buttons — react to a notification directly from the phone without opening an app [website]
File attachments: images, videos, documents up to the plan/config limit [website]
Phone call delivery (Pro plan on ntfy.sh) [website pricing]
Email delivery (Pro plan on ntfy.sh) [website pricing]

Client apps:

Android app on Google Play and F-Droid (F-Droid build excludes Firebase, maintains constant connection instead) [README][3]
iOS app on App Store — functional but limited and acknowledged as lagging behind Android [3][README]
Web app for desktop notifications via browser [website]
ntfy CLI for sending from the command line [README]

Self-hosting features:

Single Go binary — no runtime dependencies [README]
Docker deployment with a straightforward config [1][2]
Authentication: per-topic access control, admin users, password protection [1]
SMTP integration for email-triggered notifications [website]
Web push support for browsers [README]
Instant delivery mode on Android (constant connection, no Firebase dependency) [3]

Integrations ntfy plugs into:

changedetection.io, healthchecks.io (mentioned on homepage)
GitHub Actions (POST step after build)
Cron jobs (any crontab can curl)
Uptime Kuma [1]
Anything with a webhook or HTTP output

What the hosted ntfy.sh adds:

Reserved topic names (topics are otherwise first-come, effectively a shared namespace) [website][3]
Higher message limits
Phone calls and email delivery
Larger attachment limits

Pricing: SaaS vs self-hosted math

ntfy.sh paid plans (monthly/annual):

Supporter: $6/$5/mo — 2,500 daily messages, 3 reserved topics, 3 phone calls, 50 daily emails, 25MB attachments [website pricing]
Pro: $12/$10/mo — 20,000 daily messages, 10 reserved topics, 20 phone calls, 250 daily emails, 250MB attachments [website pricing]
Business: $25/$20/mo — 50,000 daily messages, 50 reserved topics, 50 phone calls, 500 daily emails, 1GB attachments [website pricing]

Self-hosted:

Software: $0 (Apache 2.0)
Server: whatever you already run your homelab on, or $5–6/mo on a shared VPS
Reserved topics: your entire server is yours, no sharing
Message limits: set by your own config

Pushover for comparison (the most common paid alternative for developers):

One-time $4.99 per platform (iOS or Android) — no subscription
10,000 messages/month free, then $0.99 per additional 10,000
No self-hosting option

PagerDuty / OpsGenie (the enterprise alerting tier):

Free tiers exist but paid plans run $19–$59/user/month, clearly overkill for personal infrastructure [data from general knowledge — specific pricing not in provided sources]

Concrete math for a homelab operator:

Say you run 10 self-hosted services and want alerts for backups, health checks, and login events — roughly 500–1,000 messages per day. On ntfy.sh’s free tier (no account, shared namespace), that’s $0 but with no reserved topics and a shared server. On the Pro plan ($10/mo), you get reserved topics and large attachments. Self-hosted on a VPS you already pay for, it’s $0 in additional cost with no limits other than your own disk and bandwidth.

Over a year: ntfy.sh Pro ≈ $120. Self-hosted on existing infrastructure ≈ $0. The only cost of self-hosting is the 30–60 minutes to set it up once.

Deployment reality check

Both detailed setup guides [1][2] describe Docker as the standard path, and neither reports unusual pain. The setup is genuinely simple by self-hosted software standards.

What you need:

Any Linux server (the one you’re already using works fine)
Docker and docker-compose, or just the Go binary if you prefer
A reverse proxy (Nginx, Caddy, Nginx Proxy Manager) if you want HTTPS and an external domain [1]
Optional: SMTP config for email-triggered notifications

What the setup actually looks like:

Donze’s guide [1] walks through creating a Docker container, exposing it via Nginx Proxy Manager, adding authentication (an admin user, topic-level access controls), and then wiring it to a bash script that fires on SSH login. The whole thing is documented clearly and works. Rajpurohit [2] describes a similar path: Docker setup, authentication, then a monitoring script that checks disk and memory and POSTs to ntfy when thresholds are crossed.

Where things get more nuanced:

iOS delivery requires going through Apple’s push infrastructure, which means either using ntfy.sh (their hosted service routes through APNs) or running your own server with certificates and a UnifiedPush provider or WebPush for the browser fallback [3]. The iOS app is the weakest link — the author’s own FAQ [3] states: “The iOS app is very bare bones and quite frankly a little buggy. I wanted to get something out the door to make the iOS users happy, but halfway through I got frustrated with iOS development and paused development.” That’s unusually honest documentation of a known gap.

Android with F-Droid (no Firebase) requires instant delivery mode, which keeps a persistent connection to your server and consumes roughly 0–1% battery per 17 hours [3]. For most people on most phones, that’s fine. For battery-critical devices, worth knowing.

Authentication model: without auth, topics are essentially shared namespaces. If someone guesses your topic name, they can subscribe to it. Donze [1] covers the solution: enable auth in the config and create an admin user. For internal use with predictable-but-unguessable topic names, skipping auth is common practice. For anything sensitive, enable it.

Realistic time estimate for someone comfortable with Docker: 20–40 minutes to a working HTTPS-accessible instance. For someone setting up a reverse proxy for the first time: add another hour.

Pros and Cons

Pros

Zero friction publishing. A curl command to a URL is the entire API for basic use. No account, no API key, no SDK. This is the right design for developer tools [README][2].
Single binary. The server is a single Go binary. No runtime, no dependency hell. Runs on anything [README].
Apache 2.0 license. Actually free, no commercial use restrictions, no “Fair-code” gotchas [README][3].
Honest, minimal documentation. The FAQ [3] tells you the server runs on one DigitalOcean droplet, iOS is buggy, and if you don’t trust the operator, self-host. That’s a developer writing for developers.
Firebase-free path. F-Droid build + self-hosted server = no Google infrastructure in your notification stack [3].
Richness when you need it. Priority levels, action buttons, attachments, tags — most simple alerting scripts will never touch these, but they’re there when you build something more sophisticated [website][2].
29,270 GitHub stars. This isn’t a solo weekend project that’ll be abandoned. The community is large and active [README].
Integrates with everything. If it can make an HTTP request, it can send an ntfy notification. Uptime Kuma, healthchecks.io, GitHub Actions, cron — all work [1][2][website].

Cons

iOS app is explicitly incomplete. The developer’s own words: “bare bones and quite frankly a little buggy” [3]. If iOS is your primary mobile platform, set expectations accordingly. The web app works as a fallback for desktop notifications.
Shared namespace on public ntfy.sh. Topics aren’t private — they’re security-by-obscurity without auth. For public-instance use without authentication, pick long random topic names and treat them as weak secrets [3][website].
Single-developer project. No company behind it, no SLA, no support contract. The hosted ntfy.sh runs on a single droplet with “best effort” uptime [3]. For personal use this is fine; for production infrastructure alerting at a company, document the dependency clearly.
No built-in aggregation or history UI. ntfy is a notification pipe, not a monitoring dashboard. You don’t get trend views, alert silencing, escalation policies, or on-call routing. If you need those, look at Grafana + Alertmanager or PagerDuty [general knowledge].
Firebase in the default Android path. The Google Play build uses FCM for delivery efficiency. If you want to avoid Firebase entirely, you need the F-Droid build and a self-hosted server — that’s two extra steps [3].
Rate limits on ntfy.sh without auth. The free tier has daily message limits. High-volume alerting (thousands of messages per day) requires a paid plan or self-hosting [website pricing].
No persistence by default beyond cache window. Messages are cached 12h by default and then gone. This is by design, but if you want a searchable alert history, you’re building that yourself [3].

Who should use this / who shouldn’t

Use ntfy if:

You run a homelab, a VPS, or any self-hosted stack and want to know when things break without checking dashboards.
You write scripts, cron jobs, or CI pipelines and want them to ping your phone when they finish or fail.
You value a tool that does one thing and has a clean API over one that tries to solve every monitoring problem.
You want push notifications to your phone without a Google or Apple account baked into the critical path.
You’re comfortable with Docker and a reverse proxy — or willing to spend an afternoon learning.

Skip it (stay on the free ntfy.sh tier without self-hosting) if:

You send fewer than a few hundred messages per day and don’t need reserved topics.
You don’t need file attachments larger than 25MB.
You’re willing to use a non-guessable topic name as your security model.

Skip it (use Pushover instead) if:

You want a polished, stable iOS app with no caveats.
You’re a non-developer who doesn’t want to think about topics, pub-sub, or auth configs.
You’re okay paying a one-time $4.99 per platform for something that just works on both platforms reliably.

Skip it (use PagerDuty / OpsGenie) if:

You need on-call scheduling, escalation policies, alert deduplication, and team routing.
This is production infrastructure with SLA obligations.
ntfy’s “best effort, single droplet” documentation would keep your on-call engineer up at night.

Skip it (use Gotify instead) if:

You want a self-hosted notification server with a cleaner Android-first experience and no Firebase dependency at all, even in the default install.

Alternatives worth considering

Gotify — the most direct self-hosted alternative. Also open source, also a single binary, also has Android and web apps. Gotify is more opinionated about being Firebase-free by default; ntfy has a broader feature set and much larger community.
Pushover — the paid personal notification service most developers used before ntfy existed. $4.99 one-time per platform. Polished iOS and Android apps. No self-hosting. Good choice if you want something you pay for once and never touch again.
Alertmanager + Grafana — the right stack if you’re already running Prometheus and need routing, grouping, silencing, and escalation. Massive overkill for “curl me when my backup finishes.”
PagerDuty / OpsGenie — enterprise on-call management. Appropriate when your alerting problem is “who’s awake at 3am and how do we escalate,” not “ping me when the disk is full.”
Apprise — a notification library (not a server) that supports 80+ notification services including ntfy, Slack, Telegram, Pushover, and others. Use it when you want to send to multiple destinations from one script without picking sides.
Telegram bots — a common DIY alternative. Free, reliable delivery, Telegram’s infra. Requires a Telegram account and a bot token. Less clean API than ntfy but more people already have Telegram on their phone.
UnifiedPush — the open protocol for push notifications without vendor lock-in. ntfy supports UnifiedPush as a distributor, so self-hosted ntfy can power other UnifiedPush-compatible apps. Worth understanding if you’re building something others will self-host.

Bottom line

ntfy solves one problem — getting a message from a script to a phone — and solves it better than anything else in the space. The API is a curl command. The server is a binary. The license is Apache 2.0. The author documents the limitations honestly, including the iOS app being unfinished and the hosted server running on a single droplet with no redundancy. That honesty is itself a feature: you know exactly what you’re depending on.

The trade-offs are real. iOS users get a second-class experience. The public hosted service has no uptime guarantees. There’s no alert history, no escalation, no on-call routing. If you need those things, ntfy isn’t your tool.

But for the target user — a developer or homelab operator who wants their phone to buzz when a backup finishes, a server reboots unexpectedly, or an unauthorized SSH login happens — the self-hosted path is genuinely simple, costs nothing beyond infrastructure you already run, and has no vendor dependency. That’s the pitch, and for that use case it’s hard to argue with.

If standing up Docker and a reverse proxy is the blocker, upready.dev deploys this kind of self-hosted infrastructure for clients. One-time setup, you own the server.

Sources

William Donze, Medium — “Ntfy: self-hosted notification service” (January 8, 2024). https://medium.com/@williamdonze/ntfy-self-hosted-notification-service-0f3eada6e657
Akash Rajpurohit — “Ntfy — Self-hosted push notification server for all your services” (January 2, 2025). https://akashrajpurohit.com/blog/selfhost-ntfy-for-push-notifications/
ntfy FAQ (community instance) — “FAQs - ntfy”. https://ntfy.annaaurora.eu/docs/faq/

Primary sources:

GitHub repository and README: https://github.com/binwiederhier/ntfy (29,270 stars, Apache 2.0 license)
Official website: https://ntfy.sh
Pricing page: https://ntfy.sh (pricing section on homepage)

Features

Integrations & APIs

Plugin / Extension System

Mobile & Desktop

Mobile App

Replaces

Related Communication & Messaging Tools

View all 128 →

LobeChat

74K

An open-source AI chat platform with multi-model support, agent building, MCP integration, and plugin ecosystem — a self-hosted alternative to ChatGPT.

communication

Rocket.Chat

45K

Rocket.Chat is an open-source team communication platform that combines messaging, video conferencing, and omnichannel customer engagement in a single self-hosted deployment.

communication