Game Server
The is not just . It is who your players are and who they play with.
Choose a game for accounts, friends, chat and , not just game rules. List the features you need, then compare with the alternatives.
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 rates, count how many of the following you would otherwise have to build, secure, and operate yourself:
- Accounts and login — device, email, Apple, Google, , 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 , member lists, (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 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 . packages the server together with everything it needs to run: the , the , 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 even more, because a game is never one . There is the server, a and usually a . They have to find each other and start in the right order. Docker shrinks a page of setup instructions to one file and one command. , the game backend server in a later tab, also documents its official quick start with .
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 file, along with their volumes, their network, and which one waits for which. Then 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 (the game backend server you will meet later) 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 in front route by instead.
- When it will not start, read the logs. Almost every container failure explains itself in its own output, and almost every beginner guesses instead of looking. Make reading the log the first thing you do, not the last.
SONUB runs as several containers described in one Compose file — the and its background workers ( and ), PostgreSQL, , for realtime, and . In front of them, a shared reverse proxy receives the connection, decrypts it and passes it in. Deploying a change is putting the up and rebuilding the services. If you learn Docker for your game server, you have also learned how to deploy the other things you will build.
SpacetimeDB
takes a different path from the usual game server: the is the server. You don't write a game server that talks to a database. You upload a written in a language such as or , and its functions () run inside the database and change its . call reducers to change state, and to the tables they need to receive changed rows right away. Because there is only one system, there is no separate server process to and no to keep two systems in sync.
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 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
is an game server from Heroic Labs, written in , shipped as a single plus a PostgreSQL-compatible . It is not a netcode and not a — 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 , email, Apple, Google, Facebook, , or custom. One account with many linked credentials, working across platforms.
- — versioned documents with per-object ownership and access rules. This is where player save lives.
- Social — friends, groups and , , and chat — one-to-one, group, and room — with message history.
- Competitive — and tournaments with configurable reset schedules, plus a that on properties.
- Economy — wallets with ledger transactions, and for Apple, Google, and Steam.
- Realtime — and , plus a match where the server makes the calls () — you write the server-side loops.
- Runtime — you extend the server in Go, , or , registering your own and hooking before or after any built-in operation.
This page teaches Nakama as one option among several. This site itself runs on , , and — 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 — the field splits by what you are optimizing for. Decide what your hard problem is first, then pick. Below, the '' means features outside the match itself (accounts, friends, chat, saves, ), and '' means running events, the shop and updates after launch.
Closest in spirit — open source, self-hostable
| Language | Strength | Weakness vs Nakama | |
|---|---|---|---|
| / | Best-in-class automatic , built-in , for , , , and . | Realtime rooms only — no identity, storage, social, economy, or leaderboards. You build the meta layer yourself. | |
| / | A radically different model: the is the server. to and you write instead of . Genuinely elegant for persistent-world games. | Young, with a smaller , and the is real work to absorb. | |
| Rivet | Rust core, JS/TS scripting | and self-hostable; game servers, matchmaking, auth, plus scripting — the closest thing to a full Nakama replacement. | Smaller community, and the company has pivoted toward general positioning, so the gaming focus is diluted. |
| + | Google-backed and the industry standard for fleets of . | Solves a different problem — no meta layer at all. It pairs with Nakama rather than replacing it. |
Managed and commercial
- — Microsoft's offering, and the broadest feature set in the category — LiveOps, , segmentation, analytics, economy. It has both matchmaking and dedicated servers, but they run exclusively on . Usage-based pricing, and you do not own the .
- AccelByte — Enterprise-grade, and the one competitor that runs first-party dedicated server orchestration. Priced for funded studios.
- Pragma — Positions itself as a backend for live-service games, with deep customization, party and matchmaking, server allocation, inventories, progression, and stores. The closest philosophical cousin to Nakama on the commercial side.
- (Fusion / Quantum) — Networking-first rather than backend-first. Quantum's 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 — services in this space have shut down or exited with little warning. That is an argument for the self-hostable 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 →
- A persistent shared world, and you are willing to rethink the architecture →
- You need identity, social, economy and leaderboards, and want to self-host →
- You need dedicated per-match server fleets → with , or — with a meta 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 and low , the honest shortlist is Nakama, Colyseus, or rolling the yourself. The Nakama trade is that you accept a large opinionated in exchange for skipping six months of building friends, chat, wallets and . 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.