smee.io alternatives

smee.io is the webhook-proxy the Probot/GitHub Apps world standardised on: create a channel, point GitHub at it, run the Node smee-client, and events stream to your localhost. It's free and it works — until you hit its structural limits. If you're searching for an alternative, it's probably one of these:

• Dropped deliveries. smee pushes events over a live connection. If your client isn't running — laptop asleep, connection silently dropped, you just hadn't started it yet — those webhooks are gone. There's no durable queue to catch up from.
• No real inspection or history. You get the payload forwarded, but there's no persistent capture log to search, diff, replay, or export later.
• Channels are unauthenticated. Anyone who has (or guesses) your channel URL can subscribe to your payloads. Fine for toy repos; uncomfortable for anything real.
• It needs Node. The official client is an npm package — annoying in a Go/Python/Rust project or a slim container.

1. Hookden relay (this site)

$ curl -s https://hookden.pages.dev/cli -o hookden && chmod +x hookden
$ ./hookden new                              # prints your webhook URL
$ ./hookden relay YOUR_BIN http://localhost:3000

• Nothing is ever dropped. The capture URL is a durable bin: webhooks land and persist whether or not the relay is running. Start the relay after lunch and pick up where you left off — or relay --all to re-deliver the whole history.
• Full inspection for free: every delivery is also in the web dashboard — headers, JSON pretty-printed, ✓/✗ HMAC signature badges (GitHub/Stripe/Shopify/generic), diff two deliveries, copy as curl, replay, HAR/JSON export.
• No Node, no npm. The client is a POSIX shell script that needs only curl and sed. Works in any container that has curl.
• Signatures still verify: bodies are re-delivered byte-exact, so X-Hub-Signature-256 checks pass in your local handler. Full walkthrough.

Trade-offs, honestly: relay polls, so deliveries reach localhost within a couple of seconds rather than push-instantly; bodies over 100 KB are truncated on relay (the CLI warns you, since a truncated body breaks signature checks); and it's hosted — if payloads can't leave your network, self-host instead.

2. Self-host smee

Good: the smee server is open source; running your own instance fixes the public-channel concern.
Trade-offs: you still have the no-persistence, drop-on-disconnect model, the Node client, and now a service to operate.

3. A tunnel (ngrok, cloudflared, localtunnel)

Good: real-time, works for any HTTP traffic, not just webhooks.
Trade-offs: a daemon exposing a port on your machine, random URLs on most free tiers, auth walls and monthly quotas. If the traffic is only webhooks, a tunnel is more machinery than the job needs — honest tunnel comparison here.

Quick chooser

• Webhooks to localhost, nothing lost, inspectable history → Hookden relay.
• You're all-in on Probot and never disconnect → smee is fine, keep it.
• Payloads must stay in-house → self-host smee or a tunnel to a private box.

← All guides · Signature debugger · Payload examples · Docs · Hookden vs webhook.site