I’ve been running ntfy for a while — it handles notifications in my home lab without much fuss. When I started moving more of my automations into n8n, connecting the two felt like a natural next step. That’s when things got interesting.
Wait, ntfy?
ntfy is a simple push notification service built on HTTP and pub-sub. You subscribe to a topic, something publishes to it, and you get a notification — on your phone, in a browser, in a script. No accounts, no registration, plain HTTP. You can use the public ntfy.sh or run your own instance for full control.
Is it better than Gotify or similar tools? Honestly, I don’t know. It works for me — and that’s enough.
Sending — trivial
Publishing a notification from n8n is a single HTTP Request node:
POST https://your-server/topic
Content-Type: text/plain
Notification bodyTwo minutes of setup, works immediately. You don’t need any dedicated node just for sending.
Subscribing — that’s where it gets tricky
Triggering a workflow on every incoming notification is a different story. ntfy exposes a persistent JSON stream — you subscribe to an endpoint and wait for messages. The problem is that n8n can’t consume that natively with a standard HTTP Request. You need a dedicated Trigger node.
I checked what was available in community nodes…
State of existing solutions
Some packages cover only Send — you’re on your own for triggering. The ones that include a trigger often don’t handle authentication correctly: they either skip headers entirely or implement them in ways that don’t match the ntfy spec. Sometimes the package simply fails to connect to a self-hosted instance with no clear reason why.
No blame to the authors — community integrations run on personal time, not SLAs. But a gap is a gap, and that’s signal enough to build your own.
Own implementation
The result: n8n-nodes-ntfy-client — two nodes plus a credential type:
Ntfy Send — publishes a notification to a topic. Supports title, priority (Min to Urgent), and tags/emoji.
Ntfy Trigger — subscribes to one or more topics via persistent JSON stream. Fires the workflow for each incoming message. On connection loss — automatic reconnect with exponential backoff.
Ntfy API credential — Server URL, auth type (None / Basic Auth / Access Token), following how n8n manages credentials. Validates the connection on save via GET /v1/health.
How it fits my setup
The main use case is home lab + AI. A monitoring system sends an event to an ntfy topic, a workflow picks it up, passes it to a local AI model, which analyzes it and sends back a summary with a suggested action — again through ntfy, this time to my phone.
Local AI model in an isolated environment + self-hosted ntfy server = zero data leaving the network. For that kind of setup, it’s a natural fit.
Installation
In your n8n instance: Settings → Community Nodes → Install, enter:
n8n-nodes-ntfy-clientRepository and docs: github.com/ximot/n8n-nodes-ntfy-client