How I built a Pushover plugin for Hermes
I run Hermes as my AI agent. It answers questions, manages my infrastructure, keeps my wiki updated, and does a lot of the heavy lifting around here. But there's one thing an AI agent can't do well — get your attention. When a backup fails at 3am, or a cron job detects something wrong, or my VPN drops, I need a notification on my phone. Not an email I'll ignore. A push notification that actually interrupts me.
That's where Pushover comes in. Simple API, reliable delivery, been around forever. I had already been using Pushover for years but that was disconnected from Hermes entirely.
I had an idea why not integrate pushover with hermes. Let's create a proper pushover integration into hermes, which I did, but later I realized that others could use it. I moved it out of hermes core into a proper plugin that anyone can install.
Starting from nothing
Hermes had no Pushover integration at all and no plugin at that time. No adapter, no tool, no way to send a notification. The platform system supports adapters — Telegram, Discord — but Pushover wasn't one of them.
But there was a problem.
The fork problem
Hermes is an open-source project by Nous Research. I run a fork with my own customizations, and I try to keep it as close to upstream as possible. Every time I modified core files to add or adjust Pushover behavior, I was creating merge drift. The more I customized, the harder it became to pull in upstream changes. At some point in time they added a plugin system.
And there was a practical issue too: other Hermes users might want Pushover support, but they can't use it if it's only in my fork. A community plugin that anyone can pip install is a different story.
This isn't a unique situation, by the way. I have been monitoring the hermes source code on github as one does. The Hermes team themselves just today did the same thing with ntfy — they had ntfy support baked into core, then moved it into a plugin for the same reasons I assuming. When the project maintainers extract their own platform adapter into a plugin, that's a pretty good signal that the plugin pattern is the right architecture.
So the decision was clearer — take the Pushover integration I had built into core and extract it into a standalone plugin package. The goal: zero deletions from core. The built-in Pushover adapter stays as a fallback. The plugin overrides it when installed.
Why a plugin and not a fork feature
I could have kept Pushover in my fork forever. But a few things pushed me toward the plugin approach:
Upstream compatibility. The closer my fork stays to upstream, the easier it is to merge changes. A 10-line hook in core is a clean, reviewable PR. An 11-file diff is not.
Shareability. Other Hermes users want push notifications too. A pip install hermes-plugin-pushover that anyone can use is better than a feature buried in someone's fork.
Precedent. The Hermes team already did this with ntfy — same pattern, same reasoning. When the upstream project extracts its own platform adapter into a plugin, you know the plugin architecture is solid.
Separation of concerns. The core gateway handles message routing. The Pushover API is an external dependency with its own rate limits, error handling, and evolution. Keeping that in a plugin means it can be versioned, updated, and tested independently.
Graceful degradation. If I mess up a plugin update, I uninstall it and the built-in fallback works. If Pushover integration is baked into core, a bad update bricks the whole gateway which I did multiple time, thanks Claude.
What's next
If you're running Hermes and want push notifications, my github repo is and the plugin will be installable with:
pip install hermes-plugin-pushover
Set PUSHOVER_APP_TOKEN and PUSHOVER_USER_KEY in your environment, restart the gateway, and you're sending notifications from AI conversations and cron jobs. Ask your hermes-agent to help you install it.
Find me on mastodon at if you have questions.