How to Install ntfy in an LXC Container on Proxmox VE (Self-Hosted Push Notifications for Beginners)

You just kicked off a backup job on your Proxmox VE host and now you're stuck refreshing the Task log every few minutes to see if it finished. Or maybe a VM crashed at 3 a.m. and you didn't find out until you happened to open the web UI the next morning. Email notifications exist, but they're slow, they get buried, and half the time they end up in spam. If you want an alert on your phone the second something happens, you need a push notification service — and ntfy is one of the easiest ones to run yourself.

This guide walks through installing ntfy in its own LXC container on Proxmox VE, locking it down so strangers can't read your alerts, and wiring up your phone to receive a real notification. By the end you'll have a working alert pipeline you can point Proxmox, your backup jobs, or any script at.

What You Will Learn

• What ntfy actually is and how it's different from email or Gotify
• How to spin up an ntfy LXC container using the community-scripts helper
• How to secure the server so it isn't wide open to anyone on the internet
• How to send your first notification from the command line
• How to connect the mobile app and put HTTPS in front of the server
• Common errors people hit and how to fix them

What Is This Feature?

ntfy (pronounced "notify") is a small, open-source pub-sub notification server. You send an HTTP request to it — from curl, a shell script, a cron job, or an app — and it pushes that message straight to any device subscribed to the same "topic." There's no account system to sign up for and no message broker to configure. A topic is just a name in a URL, like https://ntfy.example.com/proxmox-alerts, and anything published to it shows up instantly on every phone or browser subscribed to that same address.

It runs as a single Go binary with almost no dependencies, which is exactly why it drops into a small LXC container so easily. An LXC container, if you haven't used one yet, is a lightweight form of virtualization that shares the host's Linux kernel instead of emulating its own hardware like a full VM does. That makes containers start in a second or two and use a fraction of the RAM a VM would need for the same job — ideal for a background service like this one that just needs to sit there and forward messages.

Why Would You Use It?

Proxmox VE already has a built-in notification system with mail and webhook targets, and it can even forward alerts to ntfy.sh (the public, hosted version of this same project) if you don't want to run your own server. So why bother self-hosting it?

A few reasons come up a lot in homelabs:

• You control the data. Alerts about your storage pools, VM names, and IP addresses never leave your network.
• It's not just for Proxmox. Once the server exists, every script, cron job, Home Assistant automation, or Docker container on your network can push to the same topics.
• No rate limits. The public ntfy.sh instance throttles free usage. Your own server doesn't.
• It's genuinely simple. Compared to setting up a message queue or a full monitoring stack, ntfy is a five-minute install with almost nothing to break.

Honestly, if all you want is "tell me when the backup job fails," ntfy is overkill in the sense that it can do a lot more — but it's also so light that running it just for that one purpose is perfectly reasonable.

Prerequisites

Before you start, make sure you have:

• A working Proxmox VE host — this guide was tested on 8.x and 9.2, and the steps are the same on both.
• Root or admin access to the Proxmox VE web interface, and access to the node's shell (Datacenter → your node → Shell).
• At least 2 GB of free space on the storage you plan to use for the container's disk.
• Internet access from the Proxmox host, since the install script downloads packages from GitHub and Debian's repositories.
• A phone with the ntfy app installed, or just a browser — either works for testing.

You don't need a domain name to get started. You'll want one later if you plan to reach the server from outside your home network, but for now a local IP address is fine.

Step-by-Step Tutorial

1. Open the Proxmox VE shell

Log into the web UI, click your node in the left-hand tree, and choose Shell from the top-right menu. This drops you into a root shell on the Proxmox host itself — not inside any container yet.

2. Run the community-scripts installer

Paste this command and hit enter:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/ntfy.sh)"

This is a helper script maintained by the community-scripts project (the successor to the well-known tteck scripts). It downloads a small setup wizard that creates a fresh Debian 13 LXC container, installs ntfy inside it, and enables the service — all without you touching a Debian install ISO or a container template manually.

You'll be asked a couple of questions in the terminal: whether to use the default settings or the advanced ones, how many CPU cores and how much RAM to give the container, and which storage to put the disk on. For a notification server, the defaults are more than enough — this is typically one CPU core, a few hundred megabytes of RAM, and a couple of gigabytes of disk. Pick Advanced only if you want to set a static IP right away or change the hostname; otherwise Default is fine and DHCP will hand it an address automatically.

3. Find the container's IP address

When the script finishes, it prints the new container's ID and IP address directly in the shell. If you missed it, click the new container in the left tree, open its Summary tab, and the IP shows up under the network section. Write that address down — you'll use it for the rest of this guide.

4. Confirm the service is running

Click the container, open its Console, and log in as root (the script sets a random password and prints it at the end of the install — save that too, or reset it with passwd once you're in). Then check the service:

systemctl status ntfy

You're looking for active (running) in green. If you see that, the server is already listening and you can reach it in a browser at http://<container-ip>.

5. Lock down public access

Out of the box, ntfy allows anyone who can reach the server to read and publish to any topic. That's fine for quick testing, but not something you want to leave running long-term, especially once it's reachable from outside your LAN. Open the config file:

nano /etc/ntfy/server.yml

Find the auth-default-access line (it may be commented out) and set it to:

auth-default-access: "deny-all"

This flips the default from "anyone can read or write any topic" to "nobody can do anything unless they're explicitly granted access." Save the file, then create an admin account and a topic-specific user:

ntfy user add --role=admin myadmin
ntfy user add proxmox-alerts-user
ntfy access proxmox-alerts-user proxmox-alerts rw

That last command grants the proxmox-alerts-user read-write access to a topic named proxmox-alerts, and nothing else. Restart the service to apply the changes:

systemctl restart ntfy

6. Send a test notification

From any machine that can reach the container, run:

curl -u proxmox-alerts-user:yourpassword -d "Backup job finished successfully" http://<container-ip>/proxmox-alerts

If you've got the mobile app open and subscribed to that topic (or a browser tab pointed at http://<container-ip>/proxmox-alerts with the web push option enabled), the message shows up within a second or two.

7. Put HTTPS in front of it

The ntfy mobile apps expect a valid HTTPS certificate before they'll accept a server as a subscription target — plain HTTP works fine on your local network, but not once you're reaching it from outside. If you've already set up Nginx Proxy Manager or an Nginx reverse proxy on Proxmox for another service, point a subdomain at the container's IP on port 80 and request a Let's Encrypt certificate the same way you would for any other app. Once that's done, subscribe to https://ntfy.yourdomain.com/proxmox-alerts from the app instead of the bare IP.

Commands Explained

Command	What it does
systemctl status ntfy	Shows whether the ntfy service is currently running, and prints its most recent log lines.
systemctl restart ntfy	Reloads the service after you edit /etc/ntfy/server.yml — config changes don't take effect until you do this.
ntfy user add [--role=admin] <name>	Creates a new ntfy user account. Admins can manage the server; regular users only get the topic access you grant them.
ntfy access <user> <topic> rw	Grants a user read-write permission on one specific topic, without opening up every other topic on the server.
curl -u user:pass -d "message" http://host/topic	Publishes a plain-text message to a topic using HTTP basic auth for the credentials.

Common Errors

"403 Forbidden" or a JSON error mentioning "not authorized to publish" — this shows up right after you switch auth-default-access to deny-all, if you forgot to grant a user access to the topic you're posting to, or forgot the -u user:pass flag on curl. Double-check the topic name in your ntfy access command matches exactly — topics are case-sensitive.

Container has no IP address / DHCP never assigns one — this usually means the bridge you selected during setup (commonly vmbr0) doesn't actually have DHCP available on that network segment. Check the container's network settings under Hardware → Network Device, and confirm the bridge matches whichever one your other VMs and containers successfully get addresses on.

Mobile app won't add the server — if you're using a plain http:// address from outside your home network, the app will refuse the connection. This is expected; it only accepts HTTPS for anything beyond localhost/LAN testing.

Troubleshooting

Start with the logs if a notification never arrives:

journalctl -u ntfy -f

This tails the service log in real time. Send a test message from another terminal and watch what shows up — you'll see the incoming request logged, along with any authorization failure.

If the container itself seems unreachable, confirm it's actually running from the Proxmox host:

pct status <container-id>

And if you changed the config and nothing seems different, check for a YAML syntax error — a missing colon or bad indentation in server.yml will stop the service from starting cleanly. systemctl status ntfy will usually point straight at the line number.

Best Practices

A few things worth doing before you rely on this for anything important:

• Never leave auth-default-access at its open default once the server is reachable outside your LAN.
• Pick topic names that aren't easy to guess — something like proxmox-alerts-7f2a rather than just alerts, especially if you ever loosen access controls for convenience.
• Take a Proxmox snapshot of the container before making config changes you're not fully sure about — it takes a few seconds and saves you from rebuilding the whole thing if something breaks.
• Run the same community-scripts command again later with the update option to pull in new ntfy releases; it detects the existing install instead of creating a duplicate container.
• Keep the container unprivileged (the default the installer uses) unless you have a specific reason not to.

Frequently Asked Questions

Is ntfy free to self-host?

Yes. The server and every client app are open source, and there's no license or subscription involved in running your own instance.

Do I need a domain name?

Not for local use. You'll want one, plus a reverse proxy and a certificate, once you want your phone to receive alerts while you're away from home.

How is this different from Gotify?

Gotify is another self-hosted push server and does a similar job, but ntfy uses plain HTTP topics instead of per-app tokens, works from a browser without installing anything, and supports things like message priorities and click actions out of the box.

Can I use this with Home Assistant or my backup scripts?

Yes — anything that can run a curl command or make an HTTP POST request can publish to your topics, which covers most home automation platforms, cron jobs, and CI pipelines.

Can more than one device subscribe to the same topic?

As many as you want. Every subscriber to a topic gets every message sent to it, which is useful if you and someone else in the house both want the same alerts.

Conclusion

You now have a self-hosted notification server that costs almost nothing in resources and can plug into just about anything on your network. Start with one topic for Proxmox alerts, get comfortable with the access controls, and expand from there — a lot of people end up running separate topics for backups, uptime checks, and home automation once they see how easy it is to fire off a curl command from a script. The hardest part of this whole setup was locking down that default access, and now that's done too.