ideas.
May 16, 2026 3 min read self-hosteddev-toolsautomation

Self-hosted webhook inspector for local development

A lightweight self-hosted service that captures, stores, and replays inbound HTTP webhooks so developers can debug third-party integrations without exposing localhost or paying for managed tunnels.

The idea

Run a small HTTP server on your VPS that accepts incoming webhook requests from Stripe, GitHub, Twilio, or any other service, logs every request body and headers to SQLite, and exposes a simple web UI for browsing and replaying them. Developers configure the third-party service to point at https://hooks.yourdomain.com/inspect/<token> instead of fighting ngrok sessions or reverse SSH tunnels. No data leaves your infrastructure.

Why build this

Every developer who works with webhooks eventually hits the same wall: the service sends a POST to your localhost, your tunnel has expired, and you have no record of what was sent. Managed services like webhook.site and ngrok's paid tiers solve it, but they involve third-party data custody and recurring cost. The open-source alternatives (RequestBin self-hosted, Hookdeck's older OSS version) are either abandoned or bloated for solo use. A minimal, self-hostable inspector that stores and replays requests is a clean gap in the tooling landscape and straightforward to ship.

The trend toward API-first SaaS means more developers are spending time on webhook plumbing. A tool that fits into a Docker Compose stack (which most developers already run on a cheap VPS) is immediately deployable without any cloud account.

Stack sketch

  • Runtime: Go, single binary, no framework overhead
  • Storage: SQLite via mattn/go-sqlite3 — one file per endpoint token, easy to wipe
  • Web UI: HTMX + plain HTML served from embedded FS — no build step
  • Auth: Static bearer token per endpoint, generated on first use, stored in the DB
  • TLS/routing: Sits behind Traefik (or any reverse proxy); exposes plain HTTP internally
  • Replay: Outbound HTTP client in Go that re-posts the stored body + headers to a configurable target URL

Scope for v1

  • Accept POST/GET/PUT/PATCH to /inspect/<token> and store request method, path, headers, body, and timestamp
  • Web UI listing the last 500 requests per token with raw body viewer and header table
  • One-click replay: resend the stored request to a developer-supplied target URL
  • Token management page: create and revoke tokens
  • Retention policy: auto-delete requests older than 7 days via a background ticker
  • Docker image and a docker-compose.yml snippet for drop-in deployment
  • Deliberately out of v1: streaming/live push to UI (polling every 3 s is fine), multi-user auth, request transformation, team sharing

Where it could go

If v1 proves useful, the obvious next step is live-push via Server-Sent Events so the UI updates as requests arrive — useful when you're actively triggering events and watching them land. That's an afternoon of work on top of the existing Go server.

The second expansion path is a local CLI companion: inspector forward <token> <local-port> that long-polls the stored requests and replays them against localhost. This turns the hosted inspector into a proper ngrok alternative without requiring a persistent tunnel, and it works even when the developer's machine is behind a strict firewall.

Watch out for

Webhook payloads regularly contain secrets — Stripe signing keys in headers, GitHub event tokens, SMS content from Twilio. Make sure the UI enforces HTTPS (Traefik handles this, but document it clearly), and consider adding an optional at-rest encryption flag for stored bodies. The security story needs to be front and center in the README, not an afterthought.