0 Get started
Every application needs a back office: somewhere to look up a customer, see what they bought, check why an entitlement is not granting, and read who changed what. This is that screen for the app you deployed — assembled from the capabilities you composed, so there is nothing to build and nothing to keep in step.
Why it exists
The moment real people use your app, you need to answer questions about it. Did that payment land? Why is this account not entitled? What did we send that customer? Answering them means either a terminal or an internal tool you now own and maintain forever.
This is that tool, already built, and it works against whatever your Worker composes. Add a capability and its panes appear — there is nothing to wire.
The part that matters
A Worker that has never been connected refuses every control-plane route. There is no flag left off and no backdoor to open.
The dashboard holds a private key; you hold and can revoke the public one. Nothing secret of yours ever leaves your infrastructure, and a breach on our side is not a breach on yours.
Append, prove, then expire — never replace. Revocation is a row you delete: immediate, and needing nothing from us.
Each call carries a signed, single-scope, short-lived token bound to its own body, and lands under its own actor kind — so what the dashboard did is answerable separately from what your users did.
Your Worker is the authority. We are a client that you can revoke.
Connecting
You run these against your own project. Every registration is a row in your own D1, so granting access and revoking it are both things you do, not things you ask us for.
You run it, against your own project. It registers the dashboard's access as a row in your D1 — your Worker is the authority, and the dashboard is a client of it.
Connection is project-wide per environment, never per Worker, because Workers share a database: a per-Worker credential would show a user in one pane and not another. So a staging credential can never touch production.
$ pithy dashboard connect --env prod
▸ opened a browser to confirm it is you
▸ registered app.pithy.sh
▸ scopes the seam's own, plus every declared read
▸ stored in your D1, on your account
Done.
status reports what is connected and with which scopes. With --verify it proves the connection end to end with a signed ping rather than telling you what a row says.
$ pithy dashboard status --env prod --verify
▸ connected app.pithy.sh
▸ key kid_01hv8w… (active)
▸ scopes read:*, controlplane:self
▸ ping signed, answered in 41ms
Done.
Append the new key, prove it, then expire the old one — never replace. A rotation that fails leaves the previous key working, which is the opposite of how most credential rotations behave.
$ pithy dashboard rotate --env prod
▸ added kid_01hv9x…
▸ proved signed ping with the new key
▸ expired kid_01hv8w…
Done.
Immediate, and needing nothing from us. --local deletes the row without even the courtesy call, so revocation never depends on our availability.
After it, every control-plane route answers 403 again — which is what a Worker that has never been connected already does. There is no backdoor to close, because there was never one to open.
$ pithy dashboard disconnect --env prod --local --yes
▸ deleted the registration row
▸ routes controlplane/not_connected
Done.
Screens
Connect a project when you deploy it and every pane your Worker composes becomes readable.