Why Run Your Own Push Notification Server
Push notifications are everywhere – on your phone, your desktop, your smartwatch – but almost every service that delivers them routes your data through someone else’s infrastructure. Firebase, Apple Push Notification Service, OneSignal: all of them sit between you and your own alerts. Ntfy changes that equation entirely. It is an open-source, self-hosted notification server that lets you send and receive push messages over HTTP without handing your data to a third party.
The appeal goes beyond privacy. Ntfy is lightweight, runs on nearly any Linux server or NAS, and supports subscribers through a web interface, Android app, iOS app, and command-line tools. You can trigger notifications from shell scripts, cron jobs, monitoring tools, or home automation pipelines. If you already run self-hosted services – a NAS or app server, for example – ntfy fits right into that stack without adding significant resource overhead.
What You Need Before Starting
This guide assumes you have a Linux server or VPS running Ubuntu 22.04 or later, though Debian and other systemd-based distributions work just as well. You will need root or sudo access, a domain name pointed at your server’s IP address, and ports 80 and 443 open in your firewall. Certbot and Nginx will handle SSL termination, so have both installed before you begin. If you are running ntfy behind a reverse proxy on a home server, the domain step still applies – a local DNS entry or a subdomain from a service like DuckDNS will do the job.
Ntfy can also run in Docker, which is the fastest path if you already use containerized apps. The native binary approach covered here gives you more control over system integration and makes it easier to manage ntfy as a proper systemd service. Either way, the configuration file structure is identical, so switching between deployment methods later is straightforward.
Installing and Configuring Ntfy
Start by adding the ntfy apt repository. Run sudo mkdir -p /etc/apt/keyrings and then fetch the signing key with curl -fsSL https://archive.heckel.io/apt/trusted.gpg | sudo gpg –dearmor -o /etc/apt/keyrings/archive.heckel.io.gpg. Next, add the repository itself: sudo sh -c “echo ‘deb [arch=amd64 signed-by=/etc/apt/keyrings/archive.heckel.io.gpg] https://archive.heckel.io/apt debian main’ > /etc/apt/sources.list.d/archive.heckel.io.list”. Then run sudo apt update && sudo apt install ntfy to complete the install.
Once installed, the main configuration file lives at /etc/ntfy/server.yml. Open it with your editor of choice and set the base-url field to your domain, for example https://ntfy.yourdomain.com. This field is not optional – ntfy uses it to construct subscription URLs and, if you enable it, to populate links in the web interface. Set listen-http to :80 for now, since Nginx will handle HTTPS termination and proxy requests internally.
The cache and attachment directories also deserve attention. By default, ntfy stores message history in memory only, meaning a server restart wipes your notification log. Add cache-file: /var/cache/ntfy/cache.db to your config to enable persistent SQLite caching. If you want to allow file attachments in notifications – useful for sending screenshots from monitoring scripts – set attachment-cache-dir: /var/cache/ntfy/attachments and define an attachment-total-size-limit that fits your storage budget. Create those directories with sudo mkdir -p /var/cache/ntfy/attachments and give the ntfy user ownership.
Enable and start the service with sudo systemctl enable ntfy && sudo systemctl start ntfy. Check that it is running cleanly with sudo systemctl status ntfy. At this point, ntfy is serving on port 80 locally, but it is not yet accessible over HTTPS and – unless you have deliberately skipped it – not yet protected by authentication.
Setting Up Nginx and SSL
Create a new Nginx server block at /etc/nginx/sites-available/ntfy. The block should listen on ports 80 and 443, redirect HTTP to HTTPS, and proxy all requests to http://127.0.0.1:80 where ntfy is listening. Include proxy_pass http://127.0.0.1:80; along with standard proxy headers: proxy_set_header Host $host;, proxy_set_header X-Real-IP $remote_addr;, and proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;. Ntfy uses long-lived HTTP connections for its subscription model, so also add proxy_read_timeout 3600; and proxy_buffering off; to prevent Nginx from cutting connections prematurely.
Run sudo certbot –nginx -d ntfy.yourdomain.com to obtain a Let’s Encrypt certificate and let Certbot modify your Nginx config automatically. Symlink your config with sudo ln -s /etc/nginx/sites-available/ntfy /etc/nginx/sites-enabled/ntfy, test the configuration with sudo nginx -t, and reload Nginx. Your ntfy instance is now reachable over HTTPS at your domain.
Enabling Authentication and Sending Your First Notification
By default, ntfy allows anyone who can reach your server to publish and subscribe to any topic. That is fine on a private LAN, but on a public-facing server it is an open relay. To enable authentication, return to /etc/ntfy/server.yml and add auth-file: /var/lib/ntfy/user.db and auth-default-access: deny-all. The deny-all setting means no topic is accessible without credentials, which is the correct default for an internet-exposed instance. Restart ntfy after saving.
Create your admin user with sudo ntfy user add –role=admin yourname and follow the password prompt. You can then create additional users with read or write permissions scoped to specific topics using sudo ntfy access yourname topicname rw. This granular access model makes ntfy practical for multi-user setups – a home automation system might get write access to one topic while a monitoring tool gets its own separate topic and credentials.
Sending a notification is a single curl command: curl -u yourname:yourpassword -d “Backup completed successfully” https://ntfy.yourdomain.com/your-topic-name. The topic name is arbitrary – ntfy creates it on first use. To receive notifications, install the ntfy Android or iOS app, add your server URL under settings, and subscribe to the same topic name. Priority levels, notification titles, click-through URLs, and action buttons are all settable via HTTP headers. For example, adding -H “Title: Disk Alert” -H “Priority: urgent” to your curl command will trigger a high-priority notification with a custom title. That single pattern – a curl call from any script or service pointing at your own domain – is what makes ntfy useful as a universal notification layer across an entire self-hosted stack.
