Skip to main content
Nakama is Heroic Labs’ open-source game server: a Go binary with a wide feature set, including authoritative match handlers, a matchmaker, leaderboards, tournaments, parties, chat, in-app purchases, and a storage engine. Pylon overlaps significantly; the question is shape and scope.

​
TL;DR

  • Choose Nakama if you want a feature-complete game backend built in, you are shipping a free-to-play mobile game with leaderboards, tournaments, and in-app purchases, and you have Go (or Lua or TypeScript) game-server engineers.
  • Choose Pylon if you want a single binary with both app data and game shards, your team is comfortable with Rust and TypeScript, and you do not need every Nakama feature.

​
Architecture

Both are single-binary game backends with built-in user systems. Pylon treats app data as declarative entities; Nakama stores typed JSON blobs in its Storage Engine.

​
Same shape

Both ship:
  • Tick-based authoritative match handlers
  • Matchmaker with customizable algorithm
  • Single self-hosted binary
  • Built-in user accounts + sessions
  • WebSocket realtime
  • Notifications
  • Friends + relationships
  • Open source (Apache 2.0 / MIT-Apache)

​
Where Nakama is better

  • Wider feature set for game-specific concerns:
    • Leaderboards — complete with reset schedules, ranks, and authoritative submissions
    • Tournaments — scheduled leaderboard-style competitions
    • Parties — pre-match group formation
    • Groups / clans — guild-like social systems with ranks
    • In-app purchases — receipt validation for Apple and Google stores
    • Notifications — persistent in-game notifications with read state
    • Streams — pub/sub channels for game-specific topics
  • Mature game-server patterns — written by Heroic Labs, used by Vela Games, PlayerUnknown Productions, and others
  • Multi-language runtime — match handlers in Go, Lua, or TypeScript
  • Console support — patterns for PlayStation, Xbox, Switch
  • Distributed deployment — clustering and Heroic Cloud patterns for larger games
  • Persistent storage engine — typed JSON with read/write permission per object
  • Bigger team behind it — commercial company with paid support

​
Where Pylon is better

  • Declarative app entities — Pylon’s schema is built into the framework. Nakama’s Storage Engine is typed JSON, which is flexible but does not give you typed entities, relations, or live queries the same way.
  • Live queries for UI — Nakama has the Storage Engine for persistent data and Streams for pub/sub; neither gives you “useQuery returns the live array” built in.
  • Faceted search — Nakama has storage search, but not a built-in faceted full-text search API like Pylon’s useSearch.
  • TypeScript functions tied to data — Pylon’s mutation/action shares a transaction with the entity write. Nakama’s TS runtime is game-backend code against the Storage Engine and realtime APIs.
  • Smaller dependency shape — Pylon can run with SQLite for small deployments. Nakama runs with an external database dependency.
  • MIT/Apache and Apache 2.0 — Pylon’s runtime is MIT/Apache. Nakama core is Apache 2.0, with commercial cloud and ecosystem offerings available separately.
  • Single-language story — Rust + TS for everything. Nakama is Go (server) + your choice (handlers) + SDK language; the runtime polyglot is a feature for some teams and a complexity tax for others.

​
Use case fit

​
Pricing

Nakama is open source. You self-host for free. Heroic Labs offers Heroic Cloud (managed Nakama) and Satori (managed analytics and experiments) as paid services. Pylon is open source. Self-host for free. Pylon Cloud is managed Pylon, priced by usage. If you are self-hosting either, the cost is your VPS. If you are going managed, both have managed cloud options at different price points.

​
Migrating from Nakama

The mental model translates with caveats: The migration’s largest cost is rewriting the features Pylon does not have built in: leaderboards, tournaments, IAP validation, advanced groups. For each one, you build the entity plus a small action or function. It is doable, but not effortless.

​
Pylon tradeoffs

Nakama’s feature set is genuinely deeper for game-specific concerns. If you need leaderboards with reset schedules, scheduled tournaments, IAP validation, or groups with rank hierarchies, those are real things you would otherwise build yourself. Pylon’s primitives let you build them, but Nakama provides them ready-made. For pure-game backends with deep social features, Nakama is often the right pick. For app + game backends where the game is one piece of a larger product, Pylon’s integration story is cleaner.

​
Both / and

You can run Nakama for the game backend and Pylon for the surrounding web or mobile app (account management UI, billing, support tools, content management). Some studios do this: Nakama for the game, Pylon (or any other backend) for the marketing site, store, and admin tools. The two backends do not conflict; they share the user identity through OAuth or a shared SSO.