Game Server
The server is not just game logic. It is who your players are and who they play with.
Most people choose a game server by asking whether it can run their game rules fast enough. That is the wrong first question. Six months later the thing eating your time is not the rules — it is accounts, friends, guilds, chat, leaderboards, push notifications, and receipts. Pick the server that already has those, or plan to build them yourself.
Choose by the community features, not the game loop
A game server does two very different jobs. One is the game itself — moving pieces, resolving hits, keeping the world consistent. The other is everything around the game, and that second job is far larger than beginners expect. It is also the part that decides whether players come back tomorrow.
Before you compare frame rates, count how many of the following you would otherwise have to build, secure, and operate yourself:
- Accounts and login — device, email, Apple, Google, Steam, and linking them all to one player who keeps their progress across devices.
- Chat and boards — one-to-one, group, and room chat with history that survives a reconnect, plus reporting and blocking.
- Guilds and friends — join requests, roles and permissions, member lists, presence (who is online right now).
- Leaderboards and tournaments — daily and weekly resets, tie-breaking rules, and keeping cheaters off the top of the list.
- Push notifications and purchases — telling a player their energy refilled, and verifying that a purchase receipt is genuine before granting anything.
Docker — how the server actually runs
Whichever server you pick, it has to run somewhere — and today that somewhere is almost always a container. Docker packages the server together with everything it needs to run: the runtime, the libraries, the configuration. The result is one image that behaves identically on your laptop and on a rented machine in another country.
For a game server this matters more than for most software, because a game backend is never one program. It is the server plus a database plus usually a cache, and they all have to find each other and start in the right order. Docker turns that from a page of setup instructions into one file and one command — which is also why both Nakama and SpacetimeDB document their quick start as a container.
Four words you need
Compose — the whole stack in one file
A game backend is several containers that must start together. Docker Compose describes all of them — server, database, cache — in a single YAML file, along with their volumes, their network, and which one waits for which. Then docker compose up brings the entire stack alive with one command, and the same file is what you copy to the real server.
This is why you can try Nakama tonight. Its official quick start is a compose file with two services; you run one command and have a working game backend with a database on your own machine, with nothing installed system-wide and nothing to uninstall afterwards.
Three things that bite beginners
- Deleting a volume deletes your database. Commands that clean up with a volume flag will happily remove player data along with the container. Before running any cleanup, know exactly which volumes it touches — and back up before you find out the hard way.
- One host port, one process. If something already holds a port, the second container simply fails to start. On a machine running more than one site this is the usual cause — the fix is to stop publishing the port and let a single reverse proxy in front route by domain instead.
- When it will not start, read the logs. Almost every container failure explains itself in its own log output, and almost every beginner guesses instead of looking. Make reading the log the first thing you do, not the last.
PES is four containers described in one Compose file — the web app, PostgreSQL, Centrifugo for realtime, and Redis — sitting behind a shared reverse proxy that terminates HTTPS. Deploying a change is copying the code up and rebuilding one service. If you learn Docker for your game server, you have also learned how to deploy everything else you will ever build.
SpacetimeDB
SpacetimeDB takes a radically different approach: the database is the server. You don't write a game server that talks to a database — you write functions (reducers) that live inside the database, and clients subscribe to queries instead of calling endpoints. There is no separate server process to deploy, and no synchronization code between two systems, because there is only one system.
That makes it genuinely elegant for persistent worlds, and the structure is simple enough that one person can hold all of it in their head. The trade-off is that it is young, the ecosystem is smaller, and the shift in thinking is real work to absorb — it is simple, but it is not the thing you already know.
What Nakama is
Nakama is an open-source game backend server from Heroic Labs, written in Go, shipped as a single binary plus a PostgreSQL-compatible database. It is not a netcode library and not a hosting platform — it is the layer between them: the thing that knows who your players are, what they own, and who they are playing with.
Out of the box it gives you:
- Identity and auth — device ID, email, Apple, Google, Facebook, Steam, or custom. One account with many linked credentials, working across platforms.
- Storage engine — versioned JSON documents with per-object ownership and access rules. This is where player save data lives.
- Social — friends, groups and guilds, presence, and chat — one-to-one, group, and room — with message history.
- Competitive — leaderboards and tournaments with configurable reset schedules, plus a matchmaker that queries on properties.
- Economy — wallets with atomic ledger transactions, and in-app purchase receipt validation for Apple, Google, and Steam.
- Realtime — WebSocket and rUDP sockets, plus an authoritative match runtime where you write server-side tick loops.
- Runtime modules — you extend the server in Go, Lua, or TypeScript, registering your own RPCs and hooking before or after any built-in operation.
This page teaches Nakama as one option among several. This site itself runs on Laravel, PostgreSQL, Centrifugo and Redis — no Nakama. We are describing a tool, not our own stack.
What is actually good about it
What it is not good at
Worth knowing before you commit. None of these are secrets — they are consequences of the design choices above.
Alternatives
There is no single thing that is just as good as Nakama — the field splits by what you are optimizing for. Decide what your hard problem is first, then pick.
Closest in spirit — open source, self-hostable
| Language | Strength | Weakness vs Nakama | |
|---|---|---|---|
| Colyseus | TypeScript / Node | Best-in-class automatic state synchronization, built-in matchmaking, SDKs for Unity, Defold, Construct, Haxe and JS. | Realtime rooms only — no identity, storage, social, economy, or leaderboards. You build the meta layer yourself. |
| SpacetimeDB | Rust / C# modules | A radically different model: the database is the server. Clients subscribe to queries and you write reducers instead of endpoints. Genuinely elegant for persistent-world games. | Young, with a smaller ecosystem, and the paradigm shift is real work to absorb. |
| Rivet | Rust core, JS/TS scripting | Apache 2.0 and self-hostable; game servers, matchmaking, auth, plus backend scripting — the closest thing to a full Nakama replacement. | Smaller community, and the company has pivoted toward general stateful-services positioning, so the gaming focus is diluted. |
| Agones + Open Match | Kubernetes | Google-backed and the industry standard for orchestrating fleets of dedicated servers. | Solves a different problem — no meta layer at all. It pairs with Nakama rather than replacing it. |
Managed and commercial
- PlayFab — Microsoft's offering, and the broadest feature set in the category — LiveOps, A/B testing, segmentation, analytics, economy. It has both matchmaking and dedicated servers, but they run exclusively on Azure. Usage-based pricing, and you do not own the data.
- AccelByte — Enterprise-grade, and the one competitor that runs first-party dedicated server orchestration. Priced for funded studios.
- Pragma — Positions itself as a backend game engine for live-service games, with deep customization, party and matchmaking, server allocation, inventories, progression, battle passes and stores. The closest philosophical cousin to Nakama on the commercial side.
- Photon (Fusion / Quantum) — Networking-first rather than backend-first. Quantum's deterministic rollback is unmatched for competitive action games, but it is a netcode product with services attached, not the other way round.
- LootLocker · brainCloud · Beamable — Hosted, quicker to start, and thinner. LootLocker has no matchmaking or servers; Beamable is relay-only and routes real-time elsewhere. Good when your game barely needs a backend.
This category consolidates faster than most — hosting services in this space have shut down or exited with little warning. That is an argument for the self-hostable open-source options if you are planning a live service that has to run for years.
How to decide
- Realtime sync is the hard part, the meta layer is simple → Colyseus
- A persistent shared world, and you are willing to rethink the architecture → SpacetimeDB
- You need identity, social, economy and leaderboards, and want to self-host → Nakama
- You need dedicated per-match server fleets → Agones with Open Match, or Edgegap — with a meta backend beside it
- You would rather buy LiveOps tooling than build it → PlayFab or Pragma
- You already have a custom realtime server → Nakama for meta-services only is a common and sensible pattern
If you prefer self-hosting and low vendor lock-in, the honest shortlist is Nakama, Colyseus, or rolling the meta layer yourself. The Nakama trade is that you accept a large opinionated Go binary in exchange for skipping six months of building friends, chat, wallets and leaderboards. The question to ask is whether your game's meta layer looks enough like Nakama's assumptions that you will be extending it rather than fighting it.