ntfy Push Channel for Rocky Alerts

ntfy is a lightweight HTTP pub-sub service that works with the public ntfy.sh service or a self-hosted server. Hermes can subscribe for inbound prompts and publish replies, making it useful for mobile alerts, watches, scripts, and low-friction cron delivery.

Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/messaging/ntfy

Understand topic identity

ntfy does not provide a trustworthy sender identity in each message. Publisher-controlled titles cannot safely authorize a user. Hermes therefore treats the topic name itself as the logical identity.

Anyone who can publish to a topic may be able to trigger the agent. A long, unguessable topic helps, but real access control should use an authenticated ntfy server or token permissions. Do not place sensitive content on an unprotected public topic.

Setup checklist

Choose a long, unique topic name.
Decide between the public service and a self-hosted server.
Configure a token or server-side access policy when possible.
Run hermes gateway setup and select ntfy.
Set the topic as the allowed logical user for two-way chat.
Set a publish topic and home channel for notifications.
Decide whether the channel is two-way or outgoing-only.
Enable markdown only after checking target-client rendering.
Avoid private data in public or weakly protected topics.

One-way alert mode

Many Rocky workflows need notifications, not conversation. For an outgoing-only design, configure publishing but leave inbound authorization absent. Cron jobs and scripts can send summaries or alerts while inbound publications do not create agent turns.

That pattern is safer for operational status because a leaked subscription topic cannot automatically become a remote command channel. Use hermes send or the configured cron delivery target and verify the standalone sender path works outside the live gateway process.

Common pitfalls

Treating a message title as an authenticated username.
Publishing to a short, guessable topic on the public server.
Setting allow-all because the mobile app could not post during setup.
Sending secrets or customer data through an unauthenticated topic.
Configuring only live gateway replies and forgetting out-of-process cron delivery.
Assuming a 401 stream will recover without correcting the token and restarting.

Verification steps

Subscribe from a test phone or browser.
Publish a harmless test message and confirm Hermes receives it only when two-way access is intended.
Verify a different topic cannot trigger the agent.
Run one hermes send delivery to the configured topic.
Run or manually trigger a harmless cron notification.
Test an invalid token and confirm the adapter reports a fatal authorization state.
Restart the gateway and confirm subscription recovery.
Review the topic history and verify no sensitive payload was used during testing.

ntfy works best as a narrow notification pipe. Keep topic identity, authentication, and one-way versus two-way behavior explicit from the start.