Hookie
Overview
Hookie is an open-source, self-hosted webhook relay for local development. It gives developers one ingest surface for services like Stripe, GitHub, and internal APIs, then streams matching events to any machine running hookie listen against the relay.
Technical write-up
Read the relay architecture, gRPC protocol, HMAC passthrough, and backpressure design.
Hookie
Self-hosted webhook ingest, Redis-backed relay, Next.js dashboard, and Go CLI.
GitHub
View the source code, setup guide, and CLI documentation.
The Problem
Webhook development gets awkward once more than one person needs the same events. A sender usually accepts one destination URL per registration. Every new tunnel creates another URL, another shared secret, and another place to clean up when a developer changes projects.
Tunnels are fine for individual debugging. They get noisy when a team needs the same Stripe, GitHub, or internal webhook stream and each laptop has a different public endpoint. Missed events are hard to replay, visibility lives on one machine, and local code has to be reachable from the internet.
The betKeep the public webhook surface centralized, then let developers attach and detach their local machines without touching sender configuration.
What I Built
- A Go ingest service that accepts webhook HTTP requests and publishes events into Redis Streams
- A Go gRPC relay that streams events from Redis to connected clients in real time
- A Next.js app for apps, topics, auth, and the self-hosted UI, backed by Clerk and Supabase
- A Go CLI that can log in, list apps and topics, listen anonymously or by app/topic, and forward events to a local HTTP endpoint
The Tradeoff
Hookie is deliberately narrow: a self-hosted relay for local development, not a managed ingress platform with production delivery policy, operator dashboards, or commercial SLAs. That scope kept the project shippable as open source, but teams need to operate Clerk, Supabase, Redis, and the Go services themselves.
The relay inverts the ngrok model (one public URL, many local consumers), which solves team-scale webhook sharing. It does not yet solve replay for disconnected CLIs, rich observability, or production-grade retry semantics.
Where It Landed
I dogfooded the fan-out model with an incident response team using real PagerDuty and Slack traffic. My friend Cody collaborated on Hookie; I owned the design and operated the relay for that rollout. One ingest URL per source was enough for the whole team: everyone who ran hookie listen received the same payloads and headers without per-person tunnel URLs or extra webhook registrations in those products.
Webhook configuration
One URL per source
PagerDuty and Slack each pointed at one stable ingest URL
What we saw
Same events at every CLI
Local verification behaved like a direct delivery
I did not run formal benchmarks or keep publishable metrics for that rollout. The evidence was operational: shared registrations, less URL churn, and configuration that stayed O(platforms) as more developers joined instead of O(developers × platforms).
The deeper architecture notes live in the paired technical post.
technical notesI moved the relay architecture, protocol, and backpressure details into the article so this portfolio page stays focused on the product shape and outcome.
Where It's Going
Hookie is intentionally scoped as a self-hosted open-source project, not a hosted SaaS. The repository is useful as a working reference for webhook ingest, fan-out, and local delivery.
Hookie is paused for now. I may come back to it later, but I do not want to imply an active roadmap while the project is not moving.
statusHookie is open source under Apache-2.0. Issues are intentionally scoped to bugs and security reports.
- Developer tools
- gRPC
- Open source
- Webhooks
