You have a Worker that boots, a table that is yours, a capability doing work you did not write, and a deployment that proved it was the version answering. That is the whole shape of the kit — everything after this is more of it.
Three ways on from here, and they are not sequential. Pick the one that matches what you are doing this week.
If you want to understand the model
Seven pages, read once, come back to. Nothing in Core concepts is a tutorial; each page explains something you need to hold in your head.
Start with these three, in this order:
- One project, or two? — the most expensive question to answer wrong, because two projects can never be merged into one. Read it before your second app.
- What is a capability? — why the logic lives in the package and not in your repository, and what that buys you at upgrade time.
- The Worker contract —
createBackend,createEntrypoint, what is onc.varwhen your handler runs, and why a missing binding fails on the first request rather than in production.
Then, when each becomes relevant: The data layer, Migrations, Routing and verification, Errors, Secrets, and The Pithy config directory — that last one answers most of the where did that file go? questions before you ask them.
If you know what you are building
Guides are task-shaped and cross-capability. A capability page explains a part; a guide explains a job.
| You are building | Start here |
|---|---|
| A web app with sign-in | Sign in on the web |
| An iOS or Android app | Sign in on iOS and Android |
| A subscription business | Sell a subscription on the web, then Entitlements on mobile and web |
| A mobile app that sells in-app | Sell on the App Store and Sell on Google Play |
| A turn-based game | Ship a turn-based game, then Get players into a session |
| Anything with user uploads | Let users upload files |
| Search over your own content | Semantic vector search |
| Mail your users | Send a transactional email |
| A second language | i18n overview |
| A front end on the same origin | Add React |
Coming from somewhere else? Coming from Supabase and Coming from Firebase say what maps, what does not, and what you give up.
If you want to see what is available
The capability catalog is every capability, one line each, and what each one composes with. It is the page to skim when you are deciding what your app is made of rather than how to build one part of it.
Each capability’s cluster follows the same four pages in the same order — Overview, Add it, Use it, Reference — so once you have read one you know how to read the rest.
Before you ship anything real
Three pages that are worth twenty minutes each, and are much cheaper to read now than to discover later:
- Local development —
pithy devin full: what is real, what is simulated, and how several projects run at once. - Test your backend — Vitest with the Workers pool, against real D1 and KV through Miniflare. The scaffold already ships a passing binding test.
- What it costs to run — Cloudflare’s meters, per capability, with real numbers. A waiting matchmaking queue is the one that surprises people.
And when something is wrong, pithy doctor is the first command to run. It reports what is composed, what is bound, what has drifted, and where every file it uses actually lives. Diagnose a broken project works through what each finding means.
One more thing
Every command in this kit is agent-drivable: full flags, no required prompt, --json everywhere, and exit codes that mean something. That is a design rule rather than a side effect, and Pithy is agent-drivable explains what it buys you. And these docs are themselves an MCP server, so you can point your agent at them rather than let it guess at flag names.