Self-host a webhook receiver and MCP server.

Run Openhook’s MIT-licensed capture service on your own infrastructure. The HTTP receiver, browser inspector and MCP tools share a SQLite event store.

Hosted or self-hosted?

The hosted service gives you a public capture address immediately. Self-hosting gives you control of storage, routing, backups and limits, and makes you responsible for operating them. The open-source core needs no Openhook subscription or license server.

Start locally to check the API and MCP connection. Receiving callbacks from GitHub or another external sender also requires public routing to your server; a localhost URL cannot receive internet traffic.

1. Install and start

Install Python 3.10 or later and uv. Then clone the repository:

git clone https://github.com/openhook-dev/openhook-inbox.git
cd openhook-inbox
uv sync
OPENHOOK_ORIGIN=http://127.0.0.1:8788 \
  uv run openhook --http --host 127.0.0.1 --port 8788

Open http://127.0.0.1:8788 in your browser. The health endpoint is /health, and the Streamable HTTP MCP endpoint is /mcp. Keep this process running while testing.

2. Connect an MCP client

Use this server URL in your client’s remote MCP configuration:

http://127.0.0.1:8788/mcp

For a stdio client, use command uv and arguments ["--directory", "/absolute/path/to/openhook-inbox", "run", "openhook"]. Stdio provides the tool connection; an HTTP receiver must still be running and share the same database to capture callbacks.

Use server_status to check which transports are enabled. Create an inbox and send a local test request using the curl walkthrough with your own origin.

3. Configure persistent storage and public routing

Set OPENHOOK_DATABASE to a durable SQLite path writable by the service user. Back it up using SQLite-aware tooling and test restoration. A container’s disposable filesystem is not a persistent volume.

Put the service behind a reverse proxy with a valid TLS certificate and set OPENHOOK_ORIGIN to the external HTTPS origin, for example https://hooks.example.com. This setting controls the URLs returned to senders. Bind to an appropriate private interface, or a container interface protected by your proxy and firewall.

The repository includes a Dockerfile and deployment examples. Consult the current configuration reference rather than copying hosted service limits into an unrelated deployment.

Optional email and DNS capture

HTTP is enough for webhook testing. Email and DNS capture require their own listener configuration, DNS records and network routing. Do not advertise those addresses until they work from outside the server. DNS callbacks show that a hostname was resolved, not that an application job completed.

Operational checks before accepting real events

Verify public HTTPS delivery from an external sender and private access through an MCP client.
Keep management tokens private and configure provider signature verification.
Set storage, body size and retention limits; monitor capacity because accepted events are not silently evicted.
Protect backups and operational metrics from public access.
Test a restart and confirm an existing inbox and its retained events are still available.

For a hosted alternative, see Openhook’s plans. For private local development against the hosted receiver, use outbound forwarding.