You do. There is no Pithy-operated service in any request path, because there is no Pithy-operated service at all.
Every claim like that is easy to make. This page is the architecture behind it and — at the end — the exceptions, because a promise with no stated exceptions is a promise nobody should believe.
What the architecture actually is
What the dashboard never stores is the specific claim, the control-plane seam is how it reaches your Worker without holding anything, and leaving Pithy is the test of whether any of it is true.
Every capability runs in your Worker, in your Cloudflare account, against your D1, KV and R2, on your bill.
There is no step where data leaves. Not for processing, not for aggregation, not for a dashboard, not for telemetry. A capability is a package that runs inside your own script; the package has no network destination of its own to send anything to.
That is the difference between a policy and an architecture. A policy is something somebody could change under deadline pressure. An architecture is something somebody would have to build.
The consequences, which are the interesting part
Nobody can raise prices on your data, because nobody else is holding it. Cloudflare bills you for compute and storage, and that is a bill for infrastructure rather than for access to your own records.
Nobody can deprecate the API you built against. The kit is MIT and it is in your node_modules. A version that works keeps working.
Nobody can get acquired and sunset it. The Worker is deployed under your account. It keeps running because it is yours.
A subpoena served on us produces nothing about your users, because we do not have anything about your users.
Your data is joinable. Every capability’s tables sit in the same database as your own, prefixed but not partitioned — so did the players who topped the March board renew is a SQL join rather than two exports and an afternoon.
The AI part, which is easy to get wrong
Where a capability does inference — alt text, transcription, text extraction, support classification — it runs on your own Workers AI binding.
The inference lands on your bill, and your users’ files and mail never leave your infrastructure to be processed. That is the one place where quietly calling somebody else’s API would be invisible and convenient, which is exactly why it is stated.
No capability is ever gated by tier
Every @pithy-sh/* package stays fully usable from the CLI and the API regardless of what anyone pays. No control-plane route checks a subscription.
Crippling MIT code would be both wrong and futile — anybody can read it, fork it and remove the check.
Leaving
It is your account, your data and your Worker, so leaving is mostly a matter of deciding to.
The kit keeps working with nobody’s involvement. Stop upgrading and nothing changes.
Eject the capabilities you want to own. pithy add <capability> --eject copies the source into your repo and repoints the wiring at it. It is a one-way door and it is always available.
Your data is already where it is going to be. There is no export step, because there is no copy anywhere else. The tables are in your D1.
Leaving Pithy is the practical version.
The exceptions, stated plainly
Three things are true and none of them is on the list above.
The hosted dashboard stores connection metadata. If you connect one: which projects you run, which environments they have, each Worker’s address, and a reference to a credential. That is real data about you, and it is not nothing. What it never stores is the specific list in both directions — and the dashboard is optional, so this exception only exists if you choose it.
Some dashboard calls transit their infrastructure. The ones a management client has to make from its own server — proving a new connection answers, and rotating a key — because only a server holds a private key. The commitment there is a zero-logging policy on your data: response bodies fetched from your Worker are not logged, cached or persisted. Everything a pane reads is built to go straight from your browser to your Worker and transit nothing.
Cloudflare is Cloudflare. Your data is in their D1, their R2, their KV, and it is subject to their terms and their jurisdiction. Pithy does not change that and does not claim to. What it changes is that there is no second party beyond them.
Verifying it rather than believing it
Read the package. MIT, in your node_modules. Search it for a hostname.
Read the scopes you granted, if you connected a dashboard. pithy dashboard status prints them, and your Worker enforces that row and nothing else.
Read your audit trail. Every control-plane call lands in it under its own actor kind, reads included.
Revoke and watch it stop. One row, deleted locally, and every pane fails immediately — because the authority was always your Worker.