0 Get started
Find competitors. Room codes, invites, friends, and matched queues — every path lands two or more players in the same authoritative multiplayer session.
@pithy-sh/matchmaking
pithy add matchmakingMultiplayer gives you a session once players are in it. This is how they find each other: a room code they read out, an invite they tap, a friend list, or a queue that buckets on skill.
What it sits on
There is no service anyone operates. Pairing runs in your Worker, and every path ends by placing players in the same authoritative session.
The honest bit
Friends want a code. Strangers want a queue. Someone who just installed the app wants the invite their friend sent. Shipping only a skill queue is the most common way a small game's multiplayer feels empty.
If you build it yourself
Every game needs pairing. Nobody wants to build four of them.
Short, readable aloud, collision-free, and expiring — a surprisingly fiddly little system.
Who is online right now, kept fresh without hammering a database, and correct after a crash.
Matching too tightly means waiting forever; matching too loosely means a bad game. The window has to widen over time.
A durable relationship model, and an invite that survives an app restart.
Every path has to end with the same authoritative session, or you have built four half-games.
pithy add matchmakingComposes with
In the dashboard
Queue depth, wait times, and which path players are actually using.
The dashboard is the admin interface for your own application: whatever this capability writes, your team can look up, check and act on from a browser. Reading is free, forever, with no time limit. Connect the project when you deploy.
Everything else
Each one composes the same way. Nothing you skip costs you anything.
One command installs the package, wires its bindings into every environment your project declares, and runs its migrations.