The claim is easy to make and hard to verify, so here is the specific list rather than the sentence.
Never stored
Who owns your data is the architecture this follows from, the zero-logging commitment covers what passes through without being kept, and revoking us is how you end it.
| Yours | Where it lives |
|---|---|
| Your users, and their devices | Your D1, pithy_auth_* |
| Their purchases and subscriptions | Your D1, pithy_payments_* |
| Their entitlements | Your D1 |
| Your audit events | Your D1, pithy_audit_* |
| Your support mail, and its attachments | Your D1 and your R2 |
| Your email jobs and suppression list | Your D1 |
| Your secrets, at any point | Your Secrets Store and your D1, under a master key that never leaves your Worker |
| Your files | Your R2 |
Every one of those is fetched live through a credential you minted, rendered, and discarded.
Stored
| Ours | Why |
|---|---|
| Our users and organizations | Somebody has to sign in |
| Our subscriptions | The dashboard bills for itself |
| Connection metadata | Project, environment, endpoint, and a reference to the credential |
That is the list. There is not a fourth row.
The tempting exception
Caching your data for performance.
It is the obvious optimization, it would make every pane faster, and it is the thing that would quietly end the argument — because the moment a copy of your user table lives here, this has become the thing Pithy’s architecture exists to avoid.
So it is resisted. Where something genuinely must be held across a request, it is explicitly time-bounded and documented rather than left to accumulate.
What transits, and what happens to it
Panes are built to call directly from your browser to your Worker. A browser cannot hold a long-lived signing key, so the dashboard’s server mints a short-lived, single-scope, body-bound token and hands it to the browser, which calls your Worker itself. Response bodies on that path never touch our origin at all, and our private key never leaves our server. That path is waiting on the kit to answer a CORS preflight — the browser call path is the detail — and we have not built a proxy to stand in for it, because a proxy is the thing it exists to avoid.
The calls our own server makes are two, and neither one is a pane’s: the ping that proves a new connection answers, and the key rotation that appends a successor. Both have to be ours, because only our server holds a private key. Where a response does reach us, the commitment is a zero-logging policy on your data: response bodies fetched from your Worker are not logged, not cached and not persisted.
One thing does come back to us, and only one. After you rotate a secret, your browser reports the outcome it already read so the act lands in your audit trail — the names of the secret and the environments, never a value, and nothing at all for any other kind of act.
Your Worker does not distinguish the two, deliberately: both are the same sixty-second, single-scope token, verified by the same code. There is no second token class to get wrong.
Why the architecture makes this cheap to keep
A promise you have to work to keep is a promise that eventually gets broken by a deadline.
This one is nearly free, because there is nowhere for your data to go. There is no Pithy-operated data plane — not for the dashboard, not for the kit, not at all. Storing your users would mean building something to store them in, which is a decision somebody would have to make on purpose rather than a corner somebody could cut in a hurry.
That is the difference between a policy and an architecture, and it is the reason this page can be a list rather than an assurance.
Verifying it yourself
Read the scopes you granted. pithy dashboard status --env prod prints them. The dashboard can do exactly what that row says and nothing else — your Worker enforces the row, not us.
Read your audit trail. Every control-plane call lands in it under its own actor kind, reads included — so what the dashboard did is answerable separately from what your users did. Reading your user table hands a management client every customer’s address; if only the writes were recorded, the trail would show one revoked session and say nothing about the customer list walked on the way there.
Revoke and watch it stop. pithy dashboard disconnect --env prod --yes --local deletes the row without telling us. Every pane fails immediately, because the authority was always your Worker.
The exceptions, stated plainly
Connection metadata is real data about you. Which projects you run, which environments they have, and what each Worker’s address is. That is not nothing, and it is not on the never-stored list.
Our own audit trail records what we did. Separate from yours, and about our own actions.
Billing details are held by our payment processor, not by us — the same arrangement any product using a merchant of record has.