Game Server

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.

A server tower in the middle holds one shared game board with three player tokens; a phone, a laptop, a tablet and a game console around it send moves to the server and receive the same board back. — In an online game every player sends moves to the server, and the server keeps the one true game state and sends it back to everyone, like a fair referee.

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

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

Container A running 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, 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 , not in the container. This is the single most common way beginners lose their player .

Network and ports Containers on the same Docker reach each other by name — your game server connects to postgres, not to an . A 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 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.

This site runs the same way

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.

SONUB does not run Nakama

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

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

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

Genuinely open source, and you own the data . The database is yours, the is documented, the server runs on your . If Heroic Labs disappeared tomorrow your game keeps running. The exit path is a , 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 have been running in production for close to a decade.

A managed tier without a rewrite Heroic 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 runs matches where the server makes the calls, but it hands off — starting, stopping and managing a fleet of dedicated game servers, one per match — to a partner such as or GameLift. If you need to launch a (no-screen) or build for every match, 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 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 . You — 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 plus some JSON , not arbitrary 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 — 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.

One market note

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.

Notifications

How to enable notifications

Choose by the community features, not the game loop

Docker — how the server actually runs

Four words you need

Compose — the whole stack in one file

Three things that bite beginners

SpacetimeDB

What Nakama is

What is actually good about it

What it is not good at

Alternatives

Closest in spirit — open source, self-hostable

Managed and commercial

How to decide

Choose by the community features, not the game loop

Docker — how the server actually runs

Four words you need

Compose — the whole stack in one file

Three things that bite beginners

SpacetimeDB

What Nakama is

What is actually good about it

What it is not good at

Alternatives

Closest in spirit — open source, self-hostable

Managed and commercial

How to decide

Pages that go well with this one