Hook0 for self-hosted SaaS webhook delivery

Hook0's webhook lifecycle for SaaS products

Hook0 addresses a specific integration problem: a SaaS application needs to emit events to customer-controlled endpoints, but its product team does not want every application to build subscription storage, webhook delivery, retries, and operational records. The intended users are teams that expose webhook functionality as part of their own service. A customer can create a webhook through the management interface and choose which event types it should receive.

The event model has several control points. Fine-grained subscriptions determine which event types reach a particular destination. Event scoping adds a boundary within an application or customer context. Once an application submits an event, Hook0 records the event and the resulting webhook calls. According to the README, failed delivery attempts can be retried automatically when Hook0 cannot reach a destination.

This places Hook0 between a product's application code and remote subscriber systems. The product remains responsible for deciding that something happened and submitting the corresponding event. Hook0 takes responsibility for managing the destination, subscription selection, outbound request, retry behavior, and stored history. That division is useful when several applications need a shared webhook facility, although the README does not document event payload schemas or signing rules, so those details must be checked in the API documentation before implementation.

Hook0's API, output worker, and dashboard layout

The repository is a Cargo workspace rather than a single Rust binary. Its members include `api`, `cli`, `output-worker`, `clients/rust`, `clients/mcp`, and `protobuf`, alongside a separate `frontend` directory. This layout indicates a service architecture with an HTTP API, a distinct delivery worker, client libraries or generators, shared protobuf definitions, and a browser dashboard.

The README identifies a JSON REST API for management operations. It also describes persisted events and responses, which gives operators a history for debugging delivery behavior. The `output-worker` component is consistent with outbound webhook processing being separated from the API process, although the README does not publish a queue name, delivery schedule, concurrency limit, or worker-to-database interaction. It would be incorrect to infer those implementation details from the directory names alone.

The dashboard is intended for both technical and non-technical application users. That focus matters because customer-selected events, destination management, and response inspection require a usable interface if each customer is expected to configure their own webhook. The repository also contains API integration tests, end-to-end tests, smoke tests, documentation examples, and an MCP client, but the README does not explain their supported public workflows.

Self-hosting prerequisites and documented setup boundary

The README states that a self-hosted installation requires Rust at Active LTS and PostgreSQL 18 or later. It officially supports Ubuntu LTS, CentOS or RHEL 8, macOS Catalina or newer, Windows 10 or 11, and Docker. Other operating systems may work, but the project does not officially support them.

The repository provides an `api/Dockerfile` and a `docker-compose.yaml`. The Compose file starts PostgreSQL and Mailpit, then configures the API with a build argument, database connection, listening address, port, application URL, SMTP connection, sender address, and biscuit private key. The visible development configuration uses these exact database and API values:

services:
  postgres:
    image: postgres:18
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=hook0
  api:
    environment:
      - IP=0.0.0.0
      - PORT=8081
      - DATABASE_URL=postgres://postgres:postgres@postgres:5432/hook0
      - APP_URL=http://localhost:8001

The Compose file explicitly marks its biscuit private key as unsuitable for production. Mailpit is also part of the development stack, with ports 8025 and 1025 exposed by the file.

The README does not give a verified build or startup command, and the visible Compose excerpt does not expose the API service's port mapping. The documented starting point is the project documentation site, while the repository files show that container and Compose deployment paths exist.

A first Hook0 use through subscriptions and event history

A first use should begin by confirming how the application authenticates against the JSON REST API and how an application, event type, and destination are represented. The README names these concepts but does not publish request bodies, authentication headers, endpoint paths, or response schemas. Those omissions prevent a reliable code tutorial with an invented request example.

The operational sequence can still be stated without guessing at the API syntax. First, provision Hook0 and access its dashboard. Next, register or represent the application that will produce events. Define the event types that users may subscribe to, create a customer webhook destination, select the relevant event types, and submit an event through the application-facing API.

Afterward, inspect the persisted event and webhook-call records in the dashboard. If the destination cannot be reached, the documented behavior is automatic retry. An adoption test should deliberately include a successful destination and an unreachable destination so that normal delivery records and retry behavior can be separated. Before writing an SDK integration, however, the missing details need confirmation from `documentation.hook0.com`, particularly payload format, authentication, response handling, timeout behavior, and whether the database is the only supported store.

Delivery retries, persistence, and operational trade-offs

Automatic retries remove repetitive delivery code from a SaaS product. They also change the engineering responsibility placed on Hook0. Once destinations fail, operators need enough event and response history to determine whether a payload was accepted, retried, or rejected. The README says Hook0 retains both categories, but it does not define retention duration, deletion controls, backup expectations, or access permissions.

Persistence also imposes database requirements. PostgreSQL 18 is the only database vendor named as supported, despite the generic phrase that Hook0 supports multiple SQL vendors. For production adoption, that distinction matters. Teams standardized on another database cannot treat the README's database statement as confirmation of compatibility.

Retry policies are not documented in the README. There is no stated maximum attempt count, backoff schedule, timeout, delivery ordering, or treatment of permanently failing endpoints. A team with strict webhook ordering requirements cannot assume the service meets them. Likewise, the README's statement that requests cannot be reached covers delivery failure, but it does not explain how Hook0 interprets non-2xx responses. Those cases belong in acceptance testing rather than assumptions.

Hook0's SSPL v1 boundary for hosted deployments

Hook0 identifies itself as a premium open-source project under Server Side Public License v1, not a standard permissive software license. The README summarizes the stated permission to use, modify, create derivative works, and redistribute. It also states two limitations: the products may not be provided to others as a managed service, and users may not circumvent the license-key functionality or remove or obscure protected features.

That boundary is more restrictive than simply calling the repository open source. An organization evaluating Hook0 as an internal developer platform still needs to examine whether its planned use matches the license text. An organization considering resale as a hosted webhook platform must examine the managed-service restriction. The README also mentions license-key functionality, but it does not describe when keys are required or how online and offline operation behaves.

This is a licensing review point, not legal advice. The exact obligations should be read in `LICENSE.txt`. The custom classification also means that a simple scan for MIT, Apache-2.0, or BSD compatibility will not identify the license correctly. Commercial deployment models need an answer before development work begins because changing the service model can invalidate an otherwise technical fit.

Hook0 maintenance signals and component release work

The repository is not archived. Its last push was on 2026-10-15, so there is a recent maintenance signal based on repository activity. Component releases include `frontend/v1.2.1` on 2026-09-21, `mcp/v3.0.0` on 2026-08-26, and `output-worker/v1.0.7` on 2026-08-06. The releases are tracked separately rather than under one repository-wide version, which points to component-level versioning.

The Cargo workspace reinforces that structure. It includes the API, CLI, delivery worker, Rust client, MCP client, SDK generation components, dashboard examples, and protobuf package. Release configuration in `Cargo.toml` says only the API and output worker are released from that workspace, while SDKs have their own versioning. Upgrades therefore cannot be treated as a single version bump without checking each component's release notes.

The README does not provide an upgrade procedure, migration command, rollback instructions, database migration policy, or compatibility matrix for component versions. Recent activity establishes that work has occurred, not that a self-hosted operator can upgrade without reading migration and release documentation. Operators should also account for the custom license when redistributing a modified image.

Hook0 compared with a product-specific webhook module

A real alternative is to implement webhook destinations, event subscriptions, dispatch, and delivery history inside the SaaS product itself. That approach avoids adopting a separate service with its own API, dashboard, PostgreSQL instance, worker, license, and upgrade path. It also gives the product team direct control over payload formats, delivery ordering, timeout settings, and the data-retention model.

Hook0 takes a different approach. It centralizes webhook operations as a service and adds a customer-facing dashboard. Fine-grained subscriptions, event scoping, retries, and persisted responses are documented as built-in features. This is useful when several applications need the same capability or when customers should configure endpoints without product-specific UI changes.

The trade-off is control. A product-specific module can remain closely aligned with one codebase and one release cycle. Hook0 introduces an HTTP boundary and a separate deployment surface. It also states PostgreSQL 18 as its supported database, uses SSPL v1, and leaves important delivery policies undocumented in the README. Hook0 is therefore more attractive as shared webhook infrastructure than as a small library embedded into one application.

Editorial conclusion

Hook0 fits SaaS teams that want an application-facing webhook API, a user dashboard, retries, and delivery records without implementing that service themselves. It is a poor fit for an unsupported database, a managed webhook service that cannot use SSPL v1, or teams seeking an installation procedure documented entirely in the README. Before adoption, verify the self-hosting instructions, your database operations, and the license against the intended deployment model.

Frequently asked questions

Official sources

1. hook0/hook0 on GitHub
2. Issues
3. Project website
4. README
5. Releases