Self-Hosting

OtterKit installs into your own Cloudflare account: one Worker holding the tunnel engine, the console API and the dashboard, with a D1 database and a KV namespace beside it. Your webhook payloads never touch OtterKit infrastructure, and the instance never calls home - if every OtterKit host disappeared tomorrow, your install would keep running. Installing is free and there is no license key.

What you need

The domain should be a zone apex. Free Universal SSL covers example-hooks.com and *.example-hooks.com but not a second level, so installing on a subdomain needs Advanced Certificate Manager on the zone.

Install

Open deploy.otterkit.com, sign in with Cloudflare (or paste a scoped API token), pick your domain, and the wizard provisions everything: the database and its migrations, the KV namespace, the Worker and dashboard assets, DNS records, and the zone routes. It verifies the deployment end to end, then hands you a one-time claim link to create the operator account.

Your Cloudflare access is used for that run only and is never stored - the wizard keeps no database, and rediscovers your installs from your own account on each visit. Updates and teardown run from the same place.

Point the CLI at your instance

One login, and every command targets your instance instead of the cloud:

npx otterkit login https://example-hooks.com
npx otterkit whoami                       # shows the server and endpoint domain

Endpoint URLs, help text and MCP tool descriptions all switch to your domain, and the credit and top-up copy disappears since nothing is metered. For CI, set OTTERKIT_SERVER and OTTERKIT_TOKEN instead of logging in. Running otterkit login with no argument goes back to the cloud.

Email

Endpoint inboxes and email notifications are both built in, and both are off on a fresh instance. Each needs a step in your own Cloudflare account that no API can take for you, so the wizard does not attempt it - the dashboard's Instance → Email page shows what is live and walks through the rest.

Two Cloudflare rules explain why this stays manual. A Worker can only send to a destination address you have verified by clicking a link in an email, which nothing can automate. And enabling Email Routing rewrites the zone's MX records, which would break a domain that already receives real mail - not something to do to your domain unasked.

Push notifications need none of this. Your instance mints its own keys on first use, so desktop and phone notifications work on every install with no setup at all.

Updates and teardown

New releases are one click from Instance → Update in your dashboard, which opens the wizard with your install selected. Destroying removes the Worker, its storage, the DNS records the wizard created and the zone routes - and touches nothing else in your account.

Deploying by hand

The wizard is the supported path, but nothing is gated: the instance code is MIT and deploys with wrangler like any other Worker. A hand-deployed instance is a first-class install - it simply does not get one-click updates.

What differs from the cloud