About Alphorn

Notification routing, the way I always wanted to build it myself.

Alphorn is an open-source, self-hostable notification router. One webhook endpoint receives events from your servers, products, or monitoring tools; filtering rules decide what matters; and messages go out on Slack, Element, Telegram, email, push, SMS, or any of the other 20+ channels — with retries, delivery logs, and no SDK tying your app down.

Read the backstory Browse the source

The backstory

I got tired of wiring Telegram bots, or connecting Matrix into every project I owned.

Alphorn started as a scratch-my-own-itch project. I run a handful of servers and side projects, and every single one of them needed notifications — uptime alerts, contact-form submissions, new signups, cron failures. Each time, the path was the same: register a bot, store another token, write the delivery code, handle the edge cases. After doing that loop enough times I built the thing I actually wanted: one endpoint, one place to change channels, running on my own infrastructure.

The uptime-monitoring problem

I'm involved in a bunch of projects, and every one of them eventually needs notifications of some kind — uptime alerts being the most obvious. The problem is that every monitoring tool wants its own setup: register a Telegram bot here, create a Slack app there, configure an Element integration somewhere else, store the tokens, fish out the chat IDs. It's the same dance each time, and I kept thinking the same thing: I don't want to wire up another bot — I just want the monitor to call a webhook and be done with it. Let something downstream figure out where the message actually goes.

Email was the wrong medium

The obvious fallback for all of this is email — and I rejected it early. Email is great for things you need to archive or read later, but it's the wrong shape for an operational signal. A server going down, a contact-form submission, a new signup, a failed cron — those are push-me-a-notification events. I want them to land in a chat client like Element, Telegram, or Slack, in a channel I already have open, alongside the context of whatever else I'm looking at. Not buried in an inbox between newsletters and receipts, competing with everything else email is already overloaded with.

Sales leads can't wait for the next inbox check

The same pattern showed up on the product side, and for sales it was even more obvious. When a lead fills out a contact form, starts a trial, or books a demo, the first few minutes matter — respond fast and you're in a conversation, respond an hour later and you're competing with three other tabs they have open. Email is simply too slow for that: it sits in an inbox until somebody gets around to refreshing it, fighting for attention with everything else. I wanted those events to land on a phone as a push, or in the team chat where someone is already paying attention — not queued up behind newsletters. And I wanted to do that without bolting a Telegram SDK (or any SDK) into the app, because notifications aren't a product feature, they're a side-channel for the operator. One HTTP POST out, and let something else deal with delivery.

The switching-cost problem

I ran into this one first-hand: you pick a channel, sprinkle it through every project, and a year later something changes. Maybe a team decides to move off Microsoft Teams onto Slack, or leaves Slack for Element/Matrix because they want self-hosted chat. When that happens, changing the notification endpoint isn't one change — it's finding every place across every repo and server where a webhook URL or a bot token is wired in, updating each one, rolling new credentials, and redeploying. It's tedious and easy to get wrong, and something always gets missed for weeks until someone notices the alerts stopped arriving. That was the point where I stopped working around it and started building Alphorn: one webhook URL in your code, any channel out, and swapping destinations is a dashboard change instead of a deploy.

Why open source, why self-hostable

Privacy and ownership matter to me. My notification payloads include uptime data about my servers, contact messages from real people, signup events with email addresses — not stuff I want sitting in a third-party vendor's logs just because routing is convenient there. Alphorn is AGPL-3.0-or-later and ships as a single container with a single PostgreSQL dependency, so it can live next to the apps it serves, on the same private network if you want. There's a hosted edition at app.alphorn.dev for people who don't want to run another service, but the self-hosted path is the first-class one, and it's the same binary.

What I care about

Self-hosting is the default path

I run Alphorn myself for my own projects. Every feature is designed so it works on a single-node Docker Compose setup first, and on the managed edition second — not the other way around.

Open source, readable code

AGPL-3.0-or-later. No hidden premium modules, no "enterprise" fork. The code is small and meant to be read — if something is surprising, that's a bug.

Privacy is not a feature flag

Your notification payloads can contain sensitive data. The self-hosted edition never phones home, and the managed edition keeps everything inside the EU with short retention.

Security shouldn't be a premium tier

Too many products gate SSO, 2FA enforcement, and audit logging behind an "enterprise" plan. Security is a baseline, not an upsell — SSO, TOTP, and organization-wide 2FA enforcement are available on every plan, including the free one and self-hosted.

Who's behind it

Alphorn is built and operated by Armin Reiter / a31 Labs, an Austrian sole proprietorship based in Vienna. Legal and billing information, sub-processors, and the EU point of contact are in the imprint. For questions or partnership enquiries, write to hello@alphorn.dev. Bug reports and feature discussions happen on GitHub.

Try the hosted edition Self-host instead