[HN Gopher] Show HN: Outpost - OSS infra for outbound webhooks a...
___________________________________________________________________
Show HN: Outpost - OSS infra for outbound webhooks and event
destinations
Hey HN, we're launching Outpost, an open-source, self-hostable
component designed to handle outbound event delivery for SaaS/API
platforms. If you're building a platform, you eventually need to
send events to your users (think payment success, resource updates,
workflow changes). Implementing this reliably--handling retries,
monitoring, scaling, providing a decent dev experience for
consumers, and managing tenants--becomes a significant, recurring
engineering task that distracts from core product development. We
built Outpost to offload that complexity. Outpost delivers events
via traditional webhooks and also directly to event destinations
like message queues and buses. While webhooks are ubiquitous, they
have limitations at scale regarding cost, reliability patterns, and
security posture. We observed platforms like Stripe, Shopify, and
Twilio offering direct bus/queue integrations for these reasons--
it's often cheaper and more resilient. It offers a better DX for
consumers who prefer programmatic consumption. Outpost provides
this flexibility out of the box as a core feature. Key features:
- Multiple Delivery Methods: Webhooks + native Event Destinations
(SQS, Kinesis, GCP Pub/Sub, RabbitMQ, Hookdeck, etc.). -
Guaranteed Delivery: At-least-once guarantee with configurable
automatic retries. - Observability: Built-in event log &
OpenTelemetry support. - Management: API for destination
(endpoint) management; optional User Portal for end-user self-
service (debugging, destination management). - Multi-tenancy,
topics, webhook security best practices (signatures, timestamps),
etc. Given you most likely already have a system in place, Outpost
is backward compatible with your existing payload format, HTTP
headers, and signatures. It's written in Go and licensed under
Apache 2.0. It's still early days, and we'd love your feedback -
especially on the architecture, desired event destinations, or any
rough edges you find. GitHub: https://github.com/hookdeck/outpost
Docs: https://outpost.hookdeck.com/docs Thanks for checking it
out!
Author : alexbouchard
Score : 57 points
Date : 2025-05-06 12:50 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jonbo372 wrote:
| Really excited to try Outpost -- especially appreciate that it's
| open source. Looking forward to testing it in a real-world setup
| and sharing feedback!
| leggetter wrote:
| Looking forward to getting your feedback. We feel we've got a
| good baseline of features with a few key ones planned (Amazon
| EventBridge, GCP Pub/Sub, and Kafka destinations). But we need
| the additional feedback to drive the roadmap.
| ksajadi wrote:
| Looks great! how is this different from your commercial offering
| (Hookdeck)?
| alexbouchard wrote:
| I expect to have to answer that question a lot! Hookdeck is an
| event gateway, an unopinionated event log/message bus that
| operates over HTTP. It can be used to send webhooks, but 80%+
| of use cases are for inbound webhooks (consumer side).
|
| We think outbound is best served with an opinionated, purpose-
| built product, as the use case is very specific. The common
| feedback we got from event producers is that they are all
| annoyed by the complexity and costs of their current solution
| for sending webhooks. We think OSS / self-hosted is the
| solution to that. We drew from our experience handling 100
| billion events, but also kept the scope to the table stakes to
| be highly efficient and simple to operate.
|
| Event destinations' support is also crucial here because it
| means more efficient delivery with fewer errors, which can
| drastically reduce the overhead of event delivery.
| lylejantzi3rd wrote:
| Good answer.
| farbour wrote:
| Well done guys!
| simplesagar wrote:
| Congrats on the launch! This is really exciting and seems like an
| obvious progression on how companies can expose their event
| streams. Interfaces like kafka are so ubiquitous compared to
| webhooks. This seems to build on that with infrastructure to take
| care of all the failure points and tough devex. Anyone who's
| worked with webhooks knows how common failures are!
| leggetter wrote:
| A big +1 on the Kafka destination type being a priority.
| Thanks!
___________________________________________________________________
(page generated 2025-05-06 23:02 UTC)