Unity Multiplayer Backend: Adding Online Features to Your Unity Game

Add accounts, matchmaking, and realtime matches to your Unity game with the open-source Nakama SDK, without writing netcode from scratch.

Unity can move actors around a match. It does not hand you player accounts, matchmaking, or a place to save progress that survives a reinstall. Those live on a server that stays up after the match ends. That server is your Unity multiplayer backend, and this guide walks through how to set one up with Nakama. For the architecture behind that choice, see what is a game backend and how to make an online multiplayer game.

What is the best multiplayer backend for Unity?

The best multiplayer backend for Unity is the one that owns the persistent layer your engine does not, then hands you the source and the data. No single product wins for every game. You pick by the shape of your team and how much control you need.

Three archetypes cover the field:

• Open-source self-host means you run the server and own the source, with full control over data and logic.
• Managed game BaaS means a vendor runs the backend for you, trading some control for less operations work.
• Engine-tied cloud means the backend ships bundled with one engine’s ecosystem, which is convenient but harder to carry to another engine later.

We built Nakama, our open source game backend, as the answer. It is a multiplayer game backend you can read, fork, and run anywhere, under the Apache 2.0 license. More than 1M developers build on it, from small studios to publishers shipping at scale. Games on the platform bring in more than $5B in annual games revenue, and Nakama serves over 1T requests a month. It is proven at 2M+ peak CCU. When you want the managed path, we run it for you, and the source still stays yours.

Before you commit, weigh building your own against the criteria in how to choose a game backend.

Nakama is the buy-and-own path. You get a running Unity multiplayer backend in days and still own every line.

Authoritative vs relayed multiplayer in Unity

Nakama runs two match types, and the choice sets who owns the game state. In an authoritative match, your authoritative multiplayer game server runs the game loop and validates every input before broadcasting state to players. You write that match handler in Go, TypeScript, or Lua. In a relayed match, one client drives the state and Nakama forwards messages to the rest without inspecting them. Server authoritative multiplayer buys you anti-cheat and control. Client authoritative multiplayer buys you the lowest overhead for trusted clients.

You set the tick rate on an authoritative match, from 1 to 60 Hz. Fast action runs high. Turn-based runs low. Start around 20 Hz so movement feels live without simulating 60 times a second on the server. Competitive twitch titles can go to 30 to 60 Hz. Relayed matches have no server tick; Nakama forwards data immediately. That relayed path is your realtime multiplayer backend for trusted clients. A match exists from the moment you create it. Players join and leave freely. There is no built-in lobby or player-threshold phase on the server. If you want a lobby, you write that as match logic or as a match-listing UI.

Most teams ship relayed first, then add authoritative handlers for the modes that have to be cheat-proof. The Unity SDK stays the same.

How do I add multiplayer to a Unity game?

Add multiplayer to a Unity game by installing the SDK and connecting it to a Nakama server. From there you call the server for auth, matches, matchmaking, and scores. That is the full Unity multiplayer backend setup, from install to first score.

Before you start, have these ready:

• A Unity project. The SDK imports into the editor like any other package.
• Docker. Follow the Docker Compose install so a local Nakama server is listening at 127.0.0.1:7350, with the console at 127.0.0.1:7351.
• Api Compatibility Level set to .NET Standard 2.1. Change it under Edit, Project Settings, Player, Other Settings, Configuration. The .NET Framework option also works if you already depend on it.

The Unity multiplayer setup is six steps:

1. Install the Nakama Unity SDK and start a local server
2. Create a client and open a realtime socket
3. Authenticate players and manage sessions
4. Create or join a match and exchange state
5. Match players and write leaderboard scores
6. Scale to production

Step 1: Install the Nakama Unity SDK and start a local server

Grab the latest Nakama.unitypackage from the GitHub releases page or the Unity Asset Store, then import it into your project. This is our Unity SDK for Nakama. Set the editor Api Compatibility Level to .NET Standard 2.1 so the client compiles cleanly. You can also pin a release or commit in Packages/manifest.json instead of importing the package.

You still need a server to talk to. Start Nakama locally with the Docker Compose install. When it is up, the server listens at 127.0.0.1:7350 and the console is at 127.0.0.1:7351. Point the client at a hosted cluster later.

Step 2: Create a client and open a realtime socket

Build one Nakama client with your scheme, host, port, and server key. Keep a single client per server for the whole game. On the local Docker server from Step 1, that is http, 127.0.0.1, port 7350, and the development key defaultkey. Change the key and swap the address before you ship.

Open a realtime socket from that client for latency-sensitive features like matches, parties, and chat. Then connect it with the session from the next step. The socket carries the realtime multiplayer backend traffic. The client handles request and response calls like login and leaderboard writes. By default the socket dispatches events on a background thread, so pass useMainThread as true when you want handlers to run on Unity’s main thread. Keep the client on a long-lived object so your whole game shares one connection.

Step 3: Authenticate players and manage sessions

Device authentication uses the device’s unique identifier to sign a player in and create an account if none exists. You skip the login screen entirely. Store a stable device id across launches, because some platforms do not give you a usable hardware identifier.

The SDK supports device, custom, and social sign-in. It also handles console sign-in for Sony, Microsoft, and Nintendo platforms. A session is a portable object that holds the tokens, the user data, and the expiry. Store it, restore it, and refresh it before it expires, so returning players skip the login wall. Auto-refresh is on by default. Device auth gets players in fast. Link email or a social account later so progress survives a new phone.

Step 4: Create or join a match and exchange state

One player creates a match and shares the id. Others join with it. A friends-only session is one create call, then a direct message to each online friend that carries the match id. You can also create a match by a name you pick and pass around, which always runs as a relayed match.

Every message carries an op code that tells the receiver what data it is getting. One code might carry player position each tick. Another might carry a vote. Keep those codes in a shared list so both sides read the same numbers. The receiver switches on the op code, decodes the payload, and updates the matching object in its scene. In a relayed match the server forwards those messages without inspecting them. In an authoritative match your server logic validates input, then broadcasts the true state.

There is no built-in lobby waiting for a player count. The match exists from creation, and players join and leave until the last presence is gone.

Step 5: Match players and write leaderboard scores

Use the Nakama matchmaker to add players to a pool and pair them on your rules. Matchmaking finds players. It does not create the match, and it does not put anyone into one automatically, so you stay in control of what happens once players meet.

1. Add a player to the pool with your criteria, like two to ten players at a set skill level.
2. Wait for the matched event that Nakama sends when the pool has a fit.
3. Join with the match token or match ID from the matched event, then open your gameplay scene.
4. Exchange match state over the socket as the match runs.

Start with simple criteria, then add desired and optional properties as your player base grows.

The same session writes leaderboard scores. Create the leaderboard on the server first. At that moment you pick the operator: best, set, incr, or decr. That operator is immutable, so a weekly wins board that should grow by one uses incr, and a high-score board that should keep the player’s best uses best. Each record can also carry a subscore to break ties when two players land on the same score. List the top records from the client when you want a post-match board.

Step 6: Scale to production

Point the same client at a production server, and nothing in your Unity code changes. Prototype and run on open-source Nakama. When one node is no longer enough for a launch spike, Nakama Enterprise adds node clustering and high availability. Heroic Cloud is the managed path for larger studios, publishers, and enterprise teams. It gives you production ops and SOC 2 Type II without rewriting the stack, and it is the choice when live traffic and uptime matter.

That is the enterprise game backend route when you would rather ship than run infrastructure.

Own your Unity backend

Own your backend and your data from the first commit, and let Nakama carry the scale. Start with the Nakama Unity SDK and connect your first match, or build a full game end to end with the Pirate Panic multiplayer tutorial.