Everything here is optional, and what a capability actually is is worth reading first. A Pithy Worker starts with nothing composed and serves GET /health; each capability you add contributes routes, middleware, tables, bindings and English to that one Worker, and the ones you do not add are not there — no dead routes, no unused tables, no bill.
pithy add --list prints this same catalog from the CLI, marking what your project already has.
Identity and access
| Capability | What it gives you |
|---|---|
| auth | Passwordless identity — magic link, email one-time code, Google, Apple. Sessions, short-lived JWT access tokens, and a device registry. There is no password, ever |
| secrets | Encrypted secret storage with a worker-only master key and automatic at-rest key rotation. Almost everything else composes it |
| turnstile | A humanity check you stack on any route, with test keys wired automatically in dev and staging |
| audit | A queryable trail of security-relevant actions — who did what, when, and whether it succeeded — attributed to the right actor |
| control plane | The inbound administration seam. Present and denying by default: with no connection registered, every admin route answers 403 |
Money
| Capability | What it gives you |
|---|---|
| payments | Five rails — Apple, Google Play, Stripe, Lemon Squeezy and Paddle — resolving to one cross-rail entitlement. Buy Pro on iOS, be entitled on the web, with no hosted service holding your purchase history |
| ledger | A per-user balance for chips, gold, gems or credits. Atomic, idempotent, and overdraft-safe by a database constraint. Holds reserve a stake the moment a bet is placed |
Files, media and search
| Capability | What it gives you |
|---|---|
| storage | Your users’ files in your own R2, with an owner, a quota and revocable share links. Uploaded bytes are treated as untrusted on the way out, so a user’s file cannot execute on your origin |
| media | Images, video, audio and documents, with direct-upload URLs and opt-in AI alt text, transcription and text extraction |
| vector | Semantic search over your own Vectorize index, with filterable metadata treated as a schema decision rather than a query-time hope |
Communication
| Capability | What it gives you |
|---|---|
| Transactional and lifecycle mail as durable, tracked jobs. Auth needs it for magic-link and one-time-code delivery | |
| support | An inbound support inbox in your own D1, classified on your own Workers AI binding, linked to the account your app already knows about |
| testers | The Google Play closed-test roster and its fourteen-day clock, run from your own event log |
Games
| Capability | What it gives you |
|---|---|
| multiplayer | Authoritative turn-based sessions. The server holds the state no client can be trusted with, resolves it, and writes a durable result |
| matchmaking | Four ways players find each other — a room code, an invite, a friend graph, an open skill-bucketed queue — and every one ends at a session id |
| rating | Two numbers per player, per pool: a skill rating that moves both ways, and an experience total that only rises |
| leaderboard | Boards and windows — daily, weekly, monthly, all-time — with closed windows staying in your own D1 for as long as you ask |
Language
| Capability | What it gives you |
|---|---|
| i18n | A translator seam every screen, error and email renders through, with each reader’s locale negotiated per request |
Not shipped
| Capability | Status |
|---|---|
| lakehouse | Planned. Nothing ships yet, and the page says only that |
How they fit together
Some capabilities require others, and the requirement is enforced at boot — which is what pithy add resolves before it wires anything. A manifest’s peer capabilities are not advice: createBackend refuses to assemble a capability whose peers are missing, naming the one that is absent, so a Worker missing one does not start at all.
| Capability | Requires |
|---|---|
| auth | secrets, email |
| secrets | |
| payments, support, storage, media, turnstile | secrets |
pithy add auth --with-prerequisites composes the whole graph, deepest first. Without the flag, a terminal asks once and anything headless is refused with the exact commands in order.
Others compose optionally, and get better together. Turnstile auto-gates auth’s magic-link and one-time-code send routes with zero configuration when it is present. Audit records auth/* events when composed. Matchmaking buckets its queue by skill when rating is there, and by region alone when it is not. Ledger settles multiplayer’s wagers. None of those is a hard dependency: each capability has a defined behavior when the other is absent, and it is documented on the page rather than left to be discovered.
Almost everything needs auth. Storage objects belong to an owner, ledger balances belong to a player, ratings bind to a player, and payments has no public routes at all. Adding auth first is nearly always right.
Every cluster reads the same way
Four pages, in the same order, so once you have read one you know how to read the rest.
| Page | Answers |
|---|---|
| Overview | What it does, what it deliberately does not, and when you would reach for it |
| Add it | What pithy add <name> writes, wires and runs |
| Provision it | The separate step that touches your Cloudflare account, where there is one |
| Use it | The routes, the client side, and the code you write |
| Reference | Config options, routes, error codes and tables — the page you come back to |
Every package name is in the package index. Capabilities with more model to explain carry deep-dives beneath those. A page that reads as a task — sell a subscription on the web, let users upload files — lives under Build instead, because a capability page explains a part and a guide explains a job.