Tunnex

A self-hosted webhook inbox for teams, with tunnels. Point Stripe, GitHub or Telegram at one stable URL. Tunnex keeps every event, verifies its signature at the edge, and delivers a copy to every developer who is listening — including the ones who were offline when it arrived. Replay any event days later, and it still passes your signature check.

Website · Getting started · Inboxes · Self-hosting · Configuration · API · Changelog

30 seconds

pip install tunnex
tunnex login
tunnex inboxes create acme-stripe --provider stripe --secret whsec_...   # → https://acme-stripe.tunnex.org
tunnex listen acme-stripe --forward 3000                                 # every developer runs this

Set https://acme-stripe.tunnex.org/webhooks/stripe as the endpoint in Stripe once. Every listener now gets every event at localhost:3000/webhooks/stripe, with the original headers, so your handler verifies the signature as usual.

Why

Providers give a team one webhook URL per environment (Stripe allows 16 endpoints, a Telegram bot exactly one, a GitHub App one), but the team has many developers. So people rewire the dashboard every time someone starts a tunnel, events that arrive while a laptop sleeps are lost, and replaying an old Stripe or Slack event fails its 5-minute signature window. The research and the comparison with Hookdeck, Convoy, Webhook Relay, smee.io and ngrok are in ADR 0001.

What you get

• Inboxes — a team-owned URL per provider that stores every request and acknowledges it immediately; size limits, retention, IP allowlists, custom acknowledgements.
• Fan-out and catch-up — every listener gets its own copy; a cursor per listener delivers what it missed; at-least-once delivery with retries while your app restarts; filters on path, headers and JSON fields.
• Signatures at the edge — Stripe, GitHub, Slack, Shopify, Standard Webhooks (Svix, Clerk, …) and Telegram; invalid events rejected by default; re-signing on replay for timestamped schemes.
• Teams — owner/admin/member roles, invite links, scoped and expiring API tokens (revocation disconnects live clients), an audit log.
• Runs where your code runs — official multi-arch images for the client and the server, tunnex.yaml + environment configuration, Docker Compose and Kubernetes sidecars, GitLab CI and GitHub Actions.
• Tunnels — HTTPS and TCP to localhost with WebSockets and streaming, reserved subdomains, edge policies (basic auth, API keys, IP and path allowlists, email SSO, rate limits).
• A local inspector — every request and delivery on 127.0.0.1:4040, with replay.
• For coding agents — an MCP server: start a listener, wait for the next webhook, read it, replay it.

Self-host

docker compose -f examples/self-hosted/docker-compose.yml up -d     # server + PostgreSQL on *.lvh.me
tunnex login --server ws://connect.lvh.me:8081

Production (TLS, wildcard DNS, backups, upgrades, Kubernetes): docs/self-hosting.md. Images: registry.gitlab.com/homycoder/tunnex/server and registry.gitlab.com/homycoder/tunnex/client.

Documentation

Development

uv venv .venv --python 3.12
uv pip install -e . -r tunnex_server/requirements.in --group dev
make check            # ruff, mypy, the whole test suite with coverage
make run-server       # a local server on http://connect.lvh.me:8081

Tests start real servers, clients and upstream apps in-process (no sleeps, no fixed ports). Set TUNNEX_TEST_DATABASE_URL=postgresql+asyncpg://… to run them against PostgreSQL. See CONTRIBUTING.md.

License

MIT. Security reports: SECURITY.md.