Hookdeck Outpost — Egress Gateway

Platform 4 of 12·OS Layer 8 (Event Layer)·Required in all deployment modes

Scope of this page. Reference material for the Hookdeck Outpost platform: what it is, what it is normally used for, and how and why Synedrix OS uses it. It is descriptive, not normative — where this page and a canonical spec in docs/os/ disagree, the canonical spec wins. Platform responsibilities are set by Tech Stack §3.

Not the same product as Hookdeck. Hookdeck Outpost is the outbound delivery product and is a separate codebase from the Hookdeck Event Gateway, the inbound ingress platform that Synedrix OS runs as Platform 3. Hookdeck’s own documentation navigation splits them as “Receive webhooks” (Event Gateway) and “Send webhooks” (Outpost). Licensing and self-hosting differ between the two — see Deployment and licensing.

What Hookdeck Outpost is link

Outpost’s documentation describes it as “outbound webhooks infrastructure and an open-source implementation of Event Destinations that enables delivery of your platform events directly to your users’ preferred event destinations.” The README leads with the same claim in product terms: “Production-ready infrastructure for sending webhooks and delivering events from your platform to your customers’ systems. Self-host it anywhere, or use Hookdeck Outpost as a managed service.”

It is a self-hostable Go service. The model is small and consistent:

Delivery semantics. Outpost states a hard guarantee: “At least once delivery guarantee: Messages are guaranteed to be delivered at least once and never lost.” The boundary of that guarantee is documented precisely — “once an event is ingested by Outpost, delivery to eligible destinations has an at-least-once guarantee”, while the publisher remains responsible for getting the event into Outpost. Publish idempotency is supported by supplying a stable event id: “Providing a stable ID enables publish idempotency (duplicate publishes are not re-queued while the key is remembered).”

Fanout. On publish, “Outpost evaluates it against all tenant destinations. Events matching multiple destinations are independently delivered to each — modifications to one delivery do not affect others.”

Retries. Outpost provides “automatic retries with exponential backoff or a custom retry schedule”, plus manual retry through the API or the tenant portal. The behaviour is configuration, not code: MAX_RETRY_LIMIT (“Max retry attempts before giving up”, default 10), RETRY_INTERVAL_SECONDS (“Base interval for exponential backoff retries”, default 30), and RETRY_SCHEDULE for an explicit comma-separated delay list. Per-event opt-out is available at publish time via eligible_for_retry (“Whether to automatically retry failed deliveries. Defaults to true”). Sustained failure is handled by alert configuration — ALERT_CONSECUTIVE_FAILURE_COUNT, ALERT_AUTO_DISABLE_DESTINATION, ALERT_EXHAUSTED_RETRIES_WINDOW_SECONDS.

Destination types. A destination is not necessarily a webhook. Outpost “delivers events to any of the following destination types”: Webhook, Hookdeck Event Gateway, AWS Kinesis, AWS SQS, AWS S3, Azure Service Bus, GCP Pub/Sub, RabbitMQ (AMQP) and Kafka. For the webhook type, Outpost ships “webhook signatures and best practices (Standard Webhooks compatible)” and webhook secret rotation, and publish-time metadata is “arbitrary key-value pairs. For webhooks, translated to HTTP headers.”

How it differs from the inbound Hookdeck product. They are opposite directions of the same problem. The Event Gateway is documented as “your webhook management and queueing infrastructure” for receiving events; Outpost sends them. They also compose rather than compete — Hookdeck Event Gateway is itself one of Outpost’s destination types, listed as “advanced delivery with retries, transformations, and observability”.

What Hookdeck Outpost is normally used for link

The cases Outpost’s own documentation and product page lead with:

• Shipping a webhooks product to your customers — the headline case. A platform publishes events; each customer configures where their events go.
• Letting customers choose a non-webhook destination — the “Event Destinations” idea. A customer who would rather receive events on a queue or bus (SQS, Pub/Sub, Kafka, RabbitMQ, Service Bus, Kinesis) or into object storage (S3) configures that instead of an HTTP endpoint, with no work from the publishing platform.
• Multi-tenant delivery with a self-service surface — “Create multiple tenants on a single Outpost deployment” plus a user portal that lets customers “view delivery metrics, manage destinations, debug delivery issues, and observe their event destinations.”
• Guaranteeing delivery across an unreliable downstream — at-least-once semantics, automatic and manual retries, and delivery-failure alerts so the publisher learns before the recipient complains.
• Fanning one event out to many endpoints — “a message sent to a topic is replicated and delivered to multiple endpoints for parallel processing and asynchronous event notifications.”

The common thread is that Outpost owns the last mile out of the platform: whether a message left, whether it arrived, how many times it was tried, and where a customer wants it — not what the message means.

How Synedrix OS uses it link

Hookdeck Outpost is the egress gateway of Synedrix OS and sits at Layer 8 (Event Layer) of the twelve-layer taxonomy. It is required in all three deployment modes.

flowchart LR
  n1([Hookdeck Outpost]):::term
  subgraph What it owns
    n2[Durable outbound event and webhook delivery from Synedrix OS workflows to external systems]:::agent
    n3[Delivery guarantees for outbound notifications regardless of downstream availability]:::agent
  end
  n1 --> n2
  subgraph What it does not own
    n4[Canonical record that the notification happened]:::warn
    n5[Supabase PG17]:::term
    n4 --> n5
    n6[Reasoning that produced the payload]:::warn
    n7[LangGraph]:::term
    n6 --> n7
  end
  n1 --> n4
  subgraph Why Hookdeck Outpost
    n8[Delivery guarantees are infrastructure not workflow logic]:::term
    n9[It is genuinely open source]:::term
    n10[Its dependencies are already in the stack]:::term
    n11[Destination-agnostic egress is a governance asset]:::term
    n12[OpenTelemetry-native]:::term
    n13[It pairs with the ingress gateway]:::term
  end
  n1 --> n8

What it owns link

Per Tech Stack §3, 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

Its access pattern is write from workflows, at a sub-second latency profile. It is the paired half of the ingress gateway: Hookdeck (Platform 3) is where events enter Synedrix OS, Outpost is where they leave.

This matters for the Workflow Contract Spec. A workflow’s declared side_effects — external writes and persistent changes — are exactly what crosses this boundary, and the contract’s idempotency_strategy, retry_policy and error_policy fields have direct counterparts in Outpost’s publish id, its retry configuration and its alerting. Where the OS declares an intent to notify an external system, Outpost is the component that makes the declaration true rather than aspirational.

The Event Taxonomy Standard envelope survives the crossing. correlation_id is defined as “preserved unchanged across async steps and runtime-engine boundaries”, and egress is such a boundary: publish-time metadata is the carrier for correlation_id and causation_id, translated to HTTP headers on webhook destinations. Outbound notification of an Outcome Envelope — os.outcome.succeeded, os.outcome.failed, os.outcome.escalated — is the canonical example of what this platform carries.

What it does not own link

Layer 8 standardises “event production, transport, and consumption” and must not own “domain-specific policy logic”. The boundary follows from that:

Outpost is deliberately downstream of governance, never a way around it. An agent does not publish to Outpost to escape the approval gate; the workflow reaches the publish step only after policy has cleared it. Outpost’s topics are a transport categorisation and do not replace the OS event_type taxonomy — the envelope inside the payload remains canonical.

How it is operated link

Outpost self-hosts as three services that “can either be run as a single deployment or as separate deployments”: the API service (accepts events, exposes tenant and destination configuration), the delivery service (delivers events to destinations) and the log service (stores and retrieves events, their status and their responses).

Its infrastructure dependencies are the ones Synedrix OS already runs or can run locally: Redis for KV and entity storage, PostgreSQL for log storage (POSTGRES_URL, with ClickHouse as an alternative via CLICKHOUSE_ADDR), and a message queue — RABBITMQ_SERVER_URL, or AWS SQS, GCP Pub/Sub or Azure Service Bus. The documented Kubernetes quickstart installs Outpost’s services alongside Redis, PostgreSQL and RabbitMQ into a single outpost namespace, with no components outside the cluster.

As with n8n’s queue mode, note that Outpost’s Redis and message queue are its own infrastructure. They are not the Layer 7 coordination bus, and collapsing them onto one logical Redis is a deliberate decision to be taken explicitly, not a default.

Observability is native: Outpost emits “OTel standardized traces, metrics, and logs”, enabled through OTEL_SERVICE_NAME. That is the supported path for feeding egress telemetry into the Layer 10 platforms rather than reading it out of Outpost’s own portal.

Why Hookdeck Outpost link

• Delivery guarantees are infrastructure, not workflow logic. Retry-with-backoff against a downstream that is down is a solved problem that should not be re-implemented in every workflow. Outpost’s at-least-once guarantee is what lets a workflow declare a side_effect and treat it as durable.
• It is genuinely open source. Apache 2.0, with the product page stating the same codebase is used whether managed by Hookdeck or self-hosted — “no private forks or proprietary versions.” This is what Principle 11 (Open by default, sovereign by design) asks for.
• Its dependencies are already in the stack. Redis, PostgreSQL and a queue. Adding the egress gateway does not add a new class of infrastructure to operate.
• Destination-agnostic egress is a governance asset. Because a destination is configuration rather than code, changing where a tenant’s notifications go is an operator action with an audit trail, not a workflow edit and redeploy.
• OpenTelemetry-native. Egress is the point where the OS stops being able to observe what happens next. Native OTel means the last observable hop is still on the same trace as the rest of the workflow.
• It pairs with the ingress gateway. Running Hookdeck inbound and Outpost outbound gives the Event Layer one operating model at both edges.

Deployment and licensing link

Self-hosting. Documented install paths are Docker, Kubernetes (with a Helm chart at deployments/kubernetes/charts/outpost) and Railway; the software is distributed as a Go binary or a Docker image. Hookdeck also offers Outpost as a managed service.

Licence. Outpost is open source under the Apache License 2.0. The LICENSE file in github.com/hookdeck/outpost is the standard Apache License 2.0, copyright “Hookdeck Technologies Inc.” The README states: “This repository contains Outpost, covered under the Apache License 2.0, except where noted (any Outpost logos or trademarks are not covered under the Apache License, and should be explicitly noted by a LICENSE file.)” The product page repeats “open source under Apache 2.0”. No Enterprise-only source files, licence key, or fair-code carve-out is documented — unlike n8n, and unlike the inbound Hookdeck Event Gateway, which is a proprietary managed cloud service with no self-hosted deployment at all (see Hookdeck platform reference: Deployment and licensing).

Air-gapped Mode 3 — can it run with zero external dependencies? On the evidence of the official documentation, the core delivery path can, with caveats that must be stated honestly:

• Yes for the deployment itself. All three Outpost services plus Redis, PostgreSQL and RabbitMQ are documented as running together in one Kubernetes namespace with nothing outside the cluster. Nothing in the self-hosting path requires a Hookdeck account or a licence key.
• Yes for telemetry. Outpost sends anonymous usage telemetry to Hookdeck by default, but documents an explicit opt-out: DISABLE_TELEMETRY “disable[s] anonymous usage telemetry to Hookdeck.” Setting it is a hard requirement for a Mode 3 instance, in the same class as the isolation configuration required for n8n.
• Qualified for destinations. This is the honest caveat, and it is not really Outpost’s. Only the webhook, RabbitMQ and Kafka destination types can terminate inside a customer’s own network. AWS SQS/S3/Kinesis, GCP Pub/Sub, Azure Service Bus and the Hookdeck Event Gateway destination are by definition external services. That is a constraint on which destinations a Mode 3 business instance may configure, not on whether Outpost can be deployed air-gapped — and it belongs in the air-gapped deployment checklist alongside the existing rule that network egress rules block outbound traffic from platform components.
• Note on the managed publish endpoint. The published API reference documents https://api.outpost.hookdeck.com/…/publish; that is the managed service’s host. A self-hosted deployment publishes to its own API service.

Official documentation link

• Outpost documentation home
• Concepts — tenants, destinations, topics, events, delivery attempts
• Publishing events — publish API, idempotency, fanout, delivery semantics
• Destinations — the supported destination types
• Configuration reference — storage, queue, retry, portal, alert and telemetry keys
• Deploy with Docker
• Deploy on Kubernetes
• Outpost product page — positioning, feature list, licence statement
• hookdeck/outpost on GitHub — README and source
• hookdeck/outpost LICENSE — Apache License 2.0
• Hookdeck Event Gateway documentation — the separate inbound product

Related Synedrix OS documents link

• Synedrix OS Tech Stack — normative platform responsibilities; §3 covers Hookdeck Outpost, §2 covers the inbound gateway.
• Event Taxonomy Standard — the envelope that outbound events carry, and the correlation rules that survive egress.
• Layer Taxonomy Table — Layer 8 (Event Layer) definition and exclusions.
• Workflow Contract Spec — side_effects, idempotency_strategy, retry_policy and error_policy, which this platform implements.
• Outcome Spec — the outcome envelope most commonly delivered outbound.
• Core Principles — Principle 11, the open-source and sovereignty commitment this platform satisfies.
• Deployment Model Spec — the three modes, the component inventory, and the air-gapped checklist.

Synedrix OS · Platform reference · Hookdeck Outpost