Game Server · Nakama, SpacetimeDB and 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 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

Image A frozen, read-only snapshot of a program and its environment. You download one (nakama, postgres) or build your own from a Dockerfile. Images are versioned by tag — always pin a real version instead of latest, or your server changes under you one morning.

Container A running instance of an image. Containers are disposable on purpose — you stop one, start a new one from the same image, and nothing of value is lost. That is the whole trick: if throwing it away is safe, deploying is safe.

Volume Storage that survives the container. Everything written inside a container disappears when it is replaced — so your database files must live in a volume, not in the container. This is the single most common way beginners lose their player data.

Network and ports Containers on the same Docker network reach each other by name — your game server connects to postgres, not to an IP address. A port only needs to be published to the outside world if players connect to it directly, and each host port belongs to exactly one process.

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.

This site runs the same way

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.

PES does not run Nakama

This page teaches Nakama as one option among several. This site itself runs on SvelteKit, PostgreSQL, Centrifugo and Redis — no Nakama. We are describing a tool, not our own stack.

What is actually good about it

The extension model is the real feature Most hosted backends give you a fixed API and a serverless function as the escape hatch. Nakama lets you hook before and after every built-in call and register arbitrary RPCs, in-process. Your custom logic runs inside the same binary with direct database access — no cold starts, no network hop to a lambda. In Go you are writing against typed interfaces at native speed.

Single-binary operations Nakama plus one database. No Kubernetes required, no service mesh, no message broker. You can run the whole thing on a single small cloud instance and it will comfortably handle tens of thousands of concurrent users before you need to think about it. That is unusual in this category — most competitors assume you are either fully managed or running a cluster.

Genuinely open source, and you own the data Apache 2.0. The database is yours, the schema is documented, the server runs on your hardware. If Heroic Labs disappeared tomorrow your game keeps running. The exit path is a database dump, not a support ticket.

The social layer is mature Chat with history, groups with roles and join requests, friend graphs, presence — these are boring to build and easy to get subtly wrong. Nakama's versions have been running in production for close to a decade.

A managed tier without a rewrite Heroic Cloud runs the same server you self-host, so moving to managed hosting is a configuration change rather than a port. You are not locked out of either direction.

What it is not good at

Worth knowing before you commit. None of these are secrets — they are consequences of the design choices above.

It does not orchestrate dedicated servers Nakama has an authoritative match runtime, but routes dedicated-server orchestration to a partner such as Edgegap or GameLift rather than running it first-party. If you need per-match fleets of headless Unreal or Unity builds, that is a separate problem to solve.

The match loop is a fixed-rate tick in a shared process Fine for turn-based, card, board, casual realtime, and lightweight action. Not what you want for a 128-player shooter.

The runtime is not sandboxed Despite what the phrase cloud code suggests, a bad Go module takes the whole server down. This is the flip side of running in-process at native speed.

Clustering is Enterprise-only The open-source build is single-node. You scale vertically — a bigger machine — until you decide to pay. For most small games that ceiling is far away, but it is a real ceiling.

Storage queries are limited You get key-value plus some JSON indexing, not arbitrary SQL over player data. Your Go modules can query the database directly, which is the usual workaround.

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.

One market note

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.