Why AlertLoop ships self-hosted first
The most sensitive stream a team has is its own incidents. Here is why the first AlertLoop release runs on the customer's own infrastructure, and why that is the right engineering call at this stage.
Every notification tool eventually reaches the same fork: run it for people, or let people run it themselves. For AlertLoop the answer is self-hosted first, and it is a deliberate engineering decision rather than a fallback. The reasons are about where the data lives and what a single maintainer can responsibly promise.
Context
AlertLoop is a self-hosted event and notification center. An application sends it events (a failed payment, a stuck queue, a background job that died at 3am), and AlertLoop stores them, tracks their status, and delivers notifications through Email, HMAC-signed webhooks, and Telegram. When a delivery fails, it retries with exponential backoff, and whatever still fails lands in a dead-letter state you can inspect and replay instead of losing it. Events are classified into three families (incident, business_event, and audit) so business errors do not get buried in technical logs.
That is the shape of the product. The question this note answers is why it deploys onto the customer's own servers instead of a hosted service I operate.
Why self-hosted versus cloud is a real question
Framed as a business model, the cloud version looks appealing: easier onboarding, recurring revenue, usage data from day one. Framed as an engineering and trust problem, it looks different. AlertLoop sits on the exact stream of events a team is least willing to hand to an outside party, and it puts a solo maintainer on the critical path of other teams' incidents. Those two facts, not the revenue curve, decide the architecture at this stage.
Data control is the main argument
Look at what actually flows through this system. Incident events. Failed payments. Internal alerts that name customers, systems, and the ways they broke. Audit trails. This is close to the most sensitive operational stream a team produces, and it is exactly the content that turns a routine vendor evaluation into a long one.
Self-hosted means that stream, and the business logic wrapped around it, stays on the customer's own infrastructure. Nothing is routed through a service I run. That removes an entire category of questions before anyone has to ask them: no data-processing agreement to negotiate, no vendor security review, no discussion about what a third party can see, no cross-border data concerns. The team does not have to extend trust to a hosted component, because there is no hosted component in the loop. For a lot of teams, that is not a nice-to-have. It is the condition under which they will even try the tool.
A cloud product would have to earn that trust the hard way, with a SOC 2 report, a status page with history, and a track record that a v0.1.0 does not have. Self-hosting sidesteps the whole thing by keeping the sensitive data where it already sits.
Operational feasibility for a single maintainer
The second reason is about who runs the system when it matters. A hosted alerting service is a heavy, continuous commitment: uptime for other people's incidents, on-call rotations, a status page, infrastructure bills, and eventually the compliance apparatus that serious buyers expect. One person cannot promise, without real risk of breaking that promise, to be awake and responsive whenever someone else's critical alerting pipeline goes down.
Self-hosted removes that from the picture. The customer runs AlertLoop on their own infrastructure, and I am not on the critical path when their pipeline has a bad night. Support becomes something a single maintainer can actually sustain: help with deployment and bugs, not a 24/7 duty to keep a shared production service alive. Shipping alone is only viable if I do not own an operational promise I cannot keep, and self-hosting is what makes that true.
To make self-hosting a genuine option rather than a slogan, the deployment path has to be short. AlertLoop ships as a single CGO-free Go binary and as Docker Compose profiles. The admin console (a React app) is embedded in the binary and served at /admin, and the API is documented by an OpenAPI contract with an embedded Swagger UI, so there is no separate frontend or docs server to stand up. SQLite covers a local or demo run, PostgreSQL covers production, and migrations run automatically.
What this costs
This is a real tradeoff, not a free win, and the cloud-first argument is not wrong so much as premature for this product. Self-hosting means slower distribution: a hosted product can convert a curious visitor in a couple of minutes, while a self-hosted one asks them to allocate a container, a database, and a maintenance window first. It also means no usage telemetry. I do not get to watch which channels are used or which retry settings people change, so questions like "how many teams run it?" have no dashboard answer. Those are accepted costs, chosen on purpose, because the data-control and feasibility arguments matter more at the beginning than growth speed does.
There are also real boundaries inside the Community Edition itself, worth naming plainly so nobody is surprised. There is no per-event routing: every event is delivered to every configured channel. There are no user accounts or RBAC; the admin console and events are protected by a single admin token. Event retention is fixed at 30 days. AlertLoop serves plain HTTP and expects an external HTTPS reverse proxy in production. These are edition boundaries, and routing, roles, and configurable retention are on the roadmap for paid editions rather than shipped features I am going to describe as if they exist.
Result
AlertLoop Community v0.1.0 is released under AGPL-3.0-only. It ingests events over an HTTP API (idempotently, when clients provide a dedupe_key) and delivers notifications through Email, HMAC-signed webhooks, and Telegram. Failed deliveries are retried with exponential backoff and capped attempts, and attempt history is stored separately from event state. Whatever still fails is parked in a dead-letter state that can be inspected and replayed instead of being silently dropped. Built-in ingestion rate limiting (global and per-IP) is on by default. It runs as a single CGO-free Go binary or via Docker Compose, backed by SQLite for a local run and PostgreSQL for production, entirely on the team's own infrastructure.
Pro and Enterprise editions with additional operational capabilities (routing, RBAC and SSO, longer configurable retention, and more) are planned under a separate commercial license, and pricing is not decided. A cloud offering is a path for later, once the self-hosted tool has proven useful to teams running it. Pushing it now would be early. First, the job is to put a secure, self-contained tool in a team's hands and let it earn its place.