Provision Matchmaking

What pithy add matchmaking writes

pithy add matchmaking is one line. This is everything it writes.

pithy add matchmaking

Four bindings, into every environment of your Worker’s wrangler.jsonc:

Together with the new_sqlite_classes class-migration tags the two Durable Objects need.

One binding it cannot finish

A KV namespace entry has no name field, so pithy add prints the name to give the MATCHMAKING namespace in each environment.

Create it in your account under that name and paste the id in. After that, Using Matchmaking is the whole surface and the reference has the config.

The class exports

pithy add also writes both classes into your Worker entry, so wrangler’s class_name resolves against it:

export { MatchmakingQueue } from "@pithy-sh/matchmaking/src/queue/durableObject";
export { MatchmakingPresence } from "@pithy-sh/matchmaking/src/presence/durableObject";

Then migrate

pithy migrate

Two tables: the invites and the friend graph.

The binding it does not declare

SESSIONS, the multiplayer Durable Object, is read at runtime to mint the session a match resolves into.

It is not declared here — it is multiplayer’s binding, and pithy add multiplayer writes it.

That is the general rule: a capability declares what it owns, and reaches a peer through a seam rather than by re-declaring the peer’s bindings.

What runs where

Nothing is provisioned in a Cloudflare account by a separate command. There is no bucket, no index, no deployed Worker of its own — the two Durable Objects run inside your app Worker.

Which is why the whole setup is add, one KV id, and migrate.

Before production

Read the waiting queue. The sweep cadence is the one setting that decides what a waiting queue costs, and it is a per-game field rather than a global one.