Menu
  Log out
 

Unity Dedicated Server Backend Integration (2026): Post-Multiplay Guide

Game Server Backend Guide • Updated Apr 20, 2026

Unity Dedicated Server Backend Integration (2026): Post-Multiplay Guide

Unity ended direct support for its Multiplay Game Server Hosting service on March 31, 2026. Studios using Unity Matchmaker with Multiplay-allocated servers now need to bring their own hosting and wire their dedicated Unity servers up to an external backend for auth, player data, registry, and live config. This guide shows the integration shape teams are adopting.

Short path: keep Unity Netcode for GameObjects for realtime, rent dedicated servers somewhere, and point your server code at a backend that speaks plain HTTP. The backend handles identity, documents, leaderboards, and config. Unity handles gameplay.

The Integration Surfaces

Four surfaces cover 90% of a Unity dedicated-server integration:

  1. Client auth. Unity client logs the player in and receives a JWT.
  2. Server identity. The dedicated Unity server authenticates with a server token, not a player JWT.
  3. Registry heartbeat. The server registers itself, heartbeats while running, and deregisters on shutdown.
  4. Live config pull. The server fetches the active config bundle on startup and on signal.

Example: Server-Side Integration With Supercraft GSB

var client = ServerToolkitClient.Init(
    baseUrl: "https://api.supercraft.host/v1",
    projectId: "your-project-id",
    environmentId: "your-environment-id",
    serverToken: "your-server-token"
);

// Register the server so the browser can find it
var server = await client.RegisterServerAsync(new ServerRegistrationRequest {
    server_id = "eu-west-1-01",
    name = "EU West Public",
    region = "eu-west"
});

// Keep it alive while the process runs
_ = Task.Run(async () => {
    while (!ct.IsCancellationRequested) {
        await client.HeartbeatAsync(server.server_id);
        await Task.Delay(TimeSpan.FromSeconds(20), ct);
    }
});

// Read per-player progression during session setup
string state = await client.GetPlayerStateAsync(playerId);

// Atomic reward on a kill / match end
await client.AdjustEconomyAsync(playerId, new EconomyAdjust {
    balance_adjustments = new[] { new { currency = "gold", amount = 50 } },
    inventory_adjustments = new[] { new { item = "rare_loot_drop", quantity = 1 } }
});

// On shutdown
await client.DeregisterServerAsync(server.server_id);

Trust Boundaries You Must Not Blur

Caller Credential Allowed actions
Unity client Player JWT Own documents, own leaderboard entry, server browse
Unity server build Server token Any player documents, economy adjust, registry, live config
Operator / CI API key Create environments, upload config bundles, ban/unban players

Hosting the Unity Server Itself

Since Multiplay is gone, options fall into three buckets: run dedicated-server hosting from a specialist (like Supercraft's game server hosting), deploy containers on GameLift/Edgegap/Hathora-style services, or host it yourself on bare metal. Whichever you pick, the backend integration stays the same HTTP-level shape.

Common Pitfalls

  • Using a player JWT on the server. The server inherits player-only permissions and can't do atomic economy writes safely.
  • No heartbeat. Stale servers pollute the browser; players join empty sessions.
  • Config fetched only at start. Balance tweaks never reach running servers. Subscribe to a signal or poll cheaply.
  • Single environment. Staging playtests end up in the production leaderboard.

Why this shape works: it mirrors the three-caller model (operator / server / player), matches Unity Netcode's own "server-authoritative" default, and keeps the backend replaceable. If you ever migrate, the contracts stay the same.

Related in This Hub

Pair with Supercraft's game server hosting on the Game Server Backend page.

← Back to Game Server Backend Guides
Top