Unity Dedicated Server Backend: Auth, Data & Registry

A Unity dedicated server has two separate infrastructure problems: where the process runs, and which trusted backend it calls. Keep those decisions separate. Hosting can change without forcing a player-data migration, and a backend can change without rewriting your realtime simulation.

The trust boundary

Caller	Crux credential	Typical jobs
Shipped Unity client	Publishable key + player session	Own player data, auth, public reads
Trusted headless server	Server token	Server registry, authoritative writes, cross-player operations
Operator / CI	Secret operator credential	Project/environment administration

Use the shipped Unity server client

The current Crux Unity SDK exposes a dedicated-server constructor. Do not put a player publishable key or player JWT into trusted-server code and do not put a server token into the shipped client.

var crux = ServerToolkitClient.ForServer(
    baseUrl: "https://crux.supercraft.host",
    projectId: "proj_...",
    environmentId: "env_...",
    serverToken: "..."
);

var server = await crux.RegisterServerAsync(new ServerRegistration
{
    server_id = "eu-west-01",
    name = "EU West Public",
    region = "eu-west",
    map_name = "arena-01",
    game_mode = "ranked",
    player_count = 0,
    ip_address = publicIp,
    port = gamePort,
    server_version = buildVersion
});

while (!ct.IsCancellationRequested)
{
    await crux.HeartbeatAsync(server.server_id);
    await Task.Delay(TimeSpan.FromSeconds(20), ct);
}

What this integration should own

• Registry lifecycle: register after the process is actually joinable; heartbeat while healthy; stop advertising a dead or draining process.
• Authoritative results: match rewards and cross-player state mutations come from trusted server code, not from the client that benefits from them.
• Persistent player state: save what must survive the session outside the server process.
• Live config: fetch backend-owned balance/config data without baking every operational choice into the build.
• Environment isolation: staging and production should not share credentials, players or leaderboards.

What this integration does not own

It does not replace Unity Netcode, the MPS sessions API, Relay, Matchmaker, or your hosting provider. If Unity MPS solves the connectivity job, keep it. If another allocator starts your headless processes, keep that too. The useful property is that persistent backend calls remain an ordinary HTTP/SDK boundary.

Hosting after Unity Multiplay

Unity's own direct Multiplay Game Server Hosting support ended in 2026, with continuity licensed to Rocket Science Group for migrating customers. New Unity projects should treat fleet hosting as an explicit provider decision. Crux currently does not offer general-purpose Unity dedicated-server hosting; its Runtime closed alpha is a separate Godot-specific product path.

Common failures

• Shipping server credentials in the client. A server token belongs only in trusted server infrastructure.
• Registering before the process is ready. Discovery should not advertise a process that cannot accept a connection yet.
• No health/heartbeat expiry. Stale registry entries become broken join attempts.
• Coupling persistence to hosting callbacks. Keep your game-domain writes in your own server code so a hosting migration does not become a data migration.

Verify the moving parts

• Unity Multiplayer Services SDK — current sessions/Lobby/Relay/Matchmaker model.
• Unity Multiplay deprecation notice — current hosting status.
• Crux Unity SDK source — actual player/server constructors and request models.