Why a Desktop App

Fair question — OtterKit webhooks are answered entirely on the server, and tunnels are one CLI command. Nothing about the platform requires an app. The Mac app exists because endpoints accumulate faster than you can track them, and because some protections only work from software that actually lives on your machine.

One live picture of everything

A tunnel from this morning's terminal, a webhook an agent provisioned during a test run last week, an endpoint you created in the console — they're all one account, but they were started from four different places. The app shows every session in one window with traffic streaming in live, no matter who or what created it. It reads the same credentials and session records as the CLI, so there's nothing to connect or sync.

Your local ports, one click from a URL

The dashboard lists what's actually listening on your Mac — the Vite dev server on :3000, the worker on :8787 — and puts an Expose button next to each. A browser tab can't see your ports; a native app can.

Guardrails that need to run locally

Tunnels bill by the connected hour, and the classic failure mode is the tunnel you forgot. The app enforces protections that have to live on the machine: it stops tunnels when your Mac goes to sleep (a sleeping Mac can't serve one anyway), notifies you when a tunnel has been idle for hours, and keeps a projected monthly spend in the menu bar so cost is never a surprise. See Spend Guardrails for details.

Full configuration, not a read-only viewer

Every knob the CLI has at provision time — responses, verification, forwards, notifications, TTLs — is editable in the app, live, even on sessions your agents started from the terminal.