Tip: select any text on this page to bring up the Ask tooltip and question the Synedrix OS assistant about it.
What Hookdeck Outpost is
Outpost is described as outbound webhooks infrastructure and an open-source implementation of Event Destinations, enabling delivery of platform events directly to users' preferred destinations. The README frames it as production-ready infrastructure for sending webhooks, self-hostable anywhere or available as a managed service.
It is a self-hostable Go service composed of an API, a delivery service, and a log service, backed by Redis, PostgreSQL, and a message queue, all of which the Synedrix OS stack already runs.
Destinations are configuration rather than code: webhooks, message queues, and event buses are all destination types over the same publish and topic model.
What it is normally used for
How Hookdeck Outpost is used generally, before Synedrix OS enters the picture.
- Shipping a webhooks product to customers, where each customer configures where their events go
- Letting customers choose a non-webhook destination such as a queue or bus
- Multi-tenant delivery with a self-service portal for delivery metrics and destination management
- Guaranteeing delivery across an unreliable downstream with at-least-once semantics and retries
- Fanning one event out to many endpoints for parallel processing
What it owns, and what it does not
Every platform in the stack has a non-overlapping responsibility. The boundary is as much a part of the design as the capability.
Owns
- Durable outbound event and webhook delivery from Synedrix OS workflows to external systems
- Delivery guarantees for outbound notifications regardless of downstream availability
Does not own
- Whether an outbound action is permitted at all
- → Policy Guard (os-agt-002, Layer 9)
- The decision to notify, and the sequencing around it
- → n8n (Layer 3)
- Canonical record that the notification happened
- → Supabase PG17 and Neo4j (Layer 7)
- Reasoning that produced the payload
- → LangGraph (Layer 4)
Why Hookdeck Outpost
Retry logic doesn't need to be rebuilt every time
Automatically retrying a failed delivery, with increasing delays between attempts, is a well-understood problem. Outpost handles it once, as infrastructure, instead of every workflow that sends a notification having to solve it again.
It is genuinely open source
Outpost is Apache 2.0 licensed, and the exact same code runs whether Hookdeck manages it or it's self-hosted. There's no separate paid version, no private fork, and no licence to unlock.
Its dependencies are already in the stack
Outpost needs Redis, PostgreSQL, and a message queue, all of which Synedrix OS already runs for other reasons. Adding it doesn't mean operating a new kind of infrastructure.
The system can still see what happens after delivery
Once an event leaves the platform, that's normally where visibility ends. Because Outpost speaks OpenTelemetry natively, that last hop still shows up in the same trace as everything that led up to it.
Licence position
Hookdeck Outpost questions, answered
Short, citable answers drawn from this page.
What role does Hookdeck Outpost play in Synedrix OS?
Hookdeck Outpost (Egress gateway) is mapped to Layer 8: Event in Synedrix OS. The last observable hop. Delivery guarantees as infrastructure, not workflow logic.
What does Hookdeck Outpost own in Synedrix OS?
Hookdeck Outpost owns: Durable outbound event and webhook delivery from Synedrix OS workflows to external systems; Delivery guarantees for outbound notifications regardless of downstream availability.
What does Hookdeck Outpost not own in Synedrix OS?
Hookdeck Outpost does not own: Whether an outbound action is permitted at all (owned by Policy Guard (os-agt-002, Layer 9)); The decision to notify, and the sequencing around it (owned by n8n (Layer 3)); Canonical record that the notification happened (owned by Supabase PG17 and Neo4j (Layer 7)); Reasoning that produced the payload (owned by LangGraph (Layer 4)).
The full reference page, with the operating model, deployment detail, and links to every canonical specification this platform touches, lives in the documentation repository, which is private while the platform is being built.