Nakama vs Pithy

Nakama is the closest thing to a peer this kit has in games: open source, self-hosted, and built by people who clearly know what a game backend needs. The overlap is large and honest. Where they part is real-time — Nakama has it and the kit does not — and operations, where Nakama is a server you run and Pithy is not.

The table stakes.

If a feature is standard for a modern backend, assume both have it. We are not going to dress one up as a differentiator.

Both, genuinely, and both self-hostable in their own sense.

Both authenticate players and link identities.

Both have them, with time windows.

Both put players together.

Their runtime there; a Worker and a Durable Object here.

Both validate Apple and Google receipts.

A server you run, or a runtime that already exists.

Nakama is a game server. You deploy it, give it a database, scale it, and write your game's logic inside its runtime in Go, TypeScript or Lua. That design is what makes real-time authoritative matches possible, because a match needs a process holding state with a socket open to every player in it.

Pithy has no server. A Durable Object is a per-session object Cloudflare instantiates on demand, which is a very good fit for turn-based play — one referee, durable state, an alarm for the deadline — and a poor one for sixty-hertz simulation.

So the fork is the game, not the philosophy. Both let you own your infrastructure. Only one of them gives you a socket you can push frames down, and only one of them asks you to run nothing.

What each one actually gives you.

Feature	Nakama	Pithy
Multiplayer
Real-time authoritative matches Nakama: relayed and authoritative modes, over sockets Pithy: not offered; the kit is turn-based and asynchronous	Yes	No
Turn-based authoritative sessions Nakama: in their runtime Pithy: a Durable Object with hidden per-player state and an alarm-driven deadline	Yes	Yes
Matchmaking Nakama: a matchmaker with offline support Pithy: room codes, invites, a friend graph and a skill-bucketed queue	Yes	Yes
Parties and chat Nakama: both built in Pithy: not offered	Yes	No
Tournaments Nakama: first-class Pithy: leaderboards with closing windows, which is not the same thing	Yes	Partial
Skill rating feeding matchmaking Pithy: MMR per pool, which the queue buckets on directly	Partial	Yes
Economy
Virtual currency Nakama: wallets on the account Pithy: a ledger with movements, holds and settlement	Partial	Yes
Overdraft impossible by construction Pithy: a CHECK constraint; a race cannot slip past SQLite	No	Yes
A payout delivered twice pays once Pithy: the caller's ref is a UNIQUE row, so the replay aborts	No	Yes
Operations
No servers to run Nakama: the server and its database, unless you take Heroic Cloud Pithy: there is no Pithy server to deploy	No	Yes
No scaling to do yourself Nakama: you size and scale it Pithy: Workers and Durable Objects scale because that is what they are	No	Yes
Runs in every region Nakama: wherever you deploy it Pithy: by construction	Partial	Yes
A preview environment per branch Pithy: a worktree, ports and ephemeral resources, torn down afterwards	No	Yes
The rest of the product
Payments on five rails, one entitlement Nakama: receipt validation for Apple and Google Pithy: Apple, Google, Stripe, Paddle and Lemon Squeezy resolving to one entitlement	Partial	Yes
General file storage with quotas Nakama: object storage for game data Pithy: R2 with an owner, a quota and revocable shares	Partial	Yes
Support inbox Pithy: inbound mail in your own D1, classified on your own AI binding	No	Yes
Audit trail attributed to an actor Pithy: including when a dashboard is the actor	No	Yes
Play closed-test roster and its clock Pithy: the fourteen-day Google Play requirement, tracked	No	Yes

The saffron tick marks where Pithy leads — not that the other column is absent. Every claim about Nakama was checked against their own documentation on 2026-08-25; both products change, and this page is a snapshot rather than a maintained contract.

The parts Nakama does not have.

Nothing to run.

Nakama is a server and a database you operate, or a managed cloud you pay for. A Worker and a Durable Object are instantiated on demand in an account you already have, and there is no instance to size or patch.

An economy that cannot be wrong.

Wallets on an account are not a ledger. Atomic movements, idempotent by a caller-supplied ref, overdraft-safe by CHECK constraint — enforced by the database rather than by application code that must remember to check.

The product around the game.

Payments across five rails on one entitlement, storage with quotas, a support inbox and an audit trail. A game is rarely only a game, and none of that is in a game server.

The Play closed test, tracked.

Twelve testers, fourteen continuous days, and no screen anywhere telling you where you stand. Modeled from your own invite records, and honest that the number is an estimate.

Every region, without deciding.

Nakama runs where you deploy it. A Worker runs where the player is, and the session object is created near them.

Sometimes it is the better pick.

Real-time is the whole difference.

If your game needs a socket and a tick rate, Nakama does it and the kit does not. That is not a gap to close; it is a different architecture.

Parties, chat and tournaments.

Three substantial features, built in, that the kit has no answer for at all.

Client libraries for every engine.

Unity, Unreal, Godot, Flutter, Swift, Java and more, maintained. An HTTP contract is more work on every client you ship.

Write server logic in Go.

If your team is Go-shaped, running game logic in Go next to the state is a real advantage. The kit is TypeScript only.

You choose where it runs.

Your own hardware, your own region, your own network. A Worker runs where Cloudflare runs.

Heroic Cloud if you want it managed.

A first-party managed option from the people who wrote it, which is a good ownership story either way.

The honest version.

If your game is real-time, choose Nakama — this page is not going to argue you out of an architecture that fits. The kit is for asynchronous and turn-based games where the hard part is not frames but correctness: a match no client can lie about, a balance that cannot go negative, and the auth, payments and support the product around the game needs anyway.