Photon Fusion Dedicated Server: Server Mode, Hosting & Backend

Photon Fusion handles realtime state synchronization for Unity, including prediction and lag compensation. Server Mode moves State Authority into a headless dedicated process, but it leaves two production layers for you to choose: the hosting/orchestration that runs that process and the persistent backend that owns accounts, saves, economy, and trusted results.

Photon's own dedicated-server documentation makes that split explicit: the Fusion headless build runs on a dedicated game-server machine from a hosting provider, while Photon Cloud remains part of the networking/session topology. Photon Cloud is not the machine that runs your Unity game simulation.

This guide maps those boundaries explicitly: what Fusion owns, what the headless Unity server owns, what Photon Cloud owns, and what belongs in the persistent backend.

1. The Photon Fusion Architecture Stack

A secure production architecture using Photon Fusion consists of four distinct layers:

• The Unity Game Client: Runs on the player's device, authenticates via HTTP, and connects to the Photon Cloud via UDP.
• The Photon Cloud connection: Every networked Fusion peer maintains the cloud connection used for session/matchmaking services; it can also provide relay fallback. In Server Mode, direct client↔server traffic is normally the important data path when network conditions allow it.
• The Headless Unity Dedicated Server: A headless instance of your Unity project running Fusion in Server Mode. It owns State Authority but is not a player and has no player Input Authority.
• The Platform Backend (REST API / Database): Your external backend (e.g., Crux) that stores player data, leaderboards, and server registries. The Headless Server communicates with this API via HTTP.

2. Configuring Fusion for Dedicated Server Mode

To run a dedicated server, you must compile a headless Linux build of your Unity project. In your code, you must initialize the Fusion NetworkRunner differently than you would on a client.

Starting the Server

At the Fusion API level, Server Mode is selected with GameMode.Server. Keep the first proof deliberately small; port binding, scene loading, session properties, and allocation belong to the hosting design you add around it.

public async Task<StartGameResult> StartDedicatedServer(NetworkRunner runner)
{
    return await runner.StartGame(new StartGameArgs
    {
        GameMode = GameMode.Server,
        SessionName = "EU-Survival-01"
    });
}

Photon documents several Server Mode network setups because the public endpoint and port rules depend on the host. Do not assume that a successful local StartGame() means the production firewall/NAT path is correct. For the Unity process itself, use a headless/dedicated-server build appropriate to your Unity version and hosting environment.

3. Secure Identity and Per-Session Admission Are Different Jobs

Fusion gives you more than one place to establish trust, and they solve different problems. Photon Custom Authentication establishes the user's identity as they connect to the Photon application. A Fusion connection token is application-defined bytes attached to StartGameArgs that the server/host can read for session-specific logic. Do not treat an unchecked client-supplied user ID as authentication; Photon explicitly warns that the default user ID is not verified.

1. Authenticate the account. Use Photon Custom Authentication or your own backend login so the user has a server-verified identity rather than a self-asserted ID.
2. Authorize the match/session. Mint a short-lived, opaque application ticket bound to the target match and player. Keep it small enough for the Fusion connection-token field.
3. Validate before gameplay authority is granted. In Server/Host mode, inspect the connection request/token on the authority side and refuse a ticket that is expired, replayed, or for a different session.
4. Load durable state separately. After admission, the authoritative server loads the player's progression/inventory from the backend and becomes the only writer for trusted match results.

For reconnects, Fusion also uses connection tokens as an application-level way to recognize a returning player and restore Input Authority. That is another reason to keep the token's meaning explicit rather than stuffing a large profile or save blob into it.

4. Orchestrating Unity Dedicated Servers

Running one headless Unity process is different from operating a fleet. Photon describes an orchestration service as part of the dedicated-server topology because something still has to allocate a machine/process when a match needs one, expose a usable endpoint, observe readiness, and stop the process afterward.

Network boundary: do not design Server Mode as “everything goes through a Photon relay.” The Photon Cloud connection is mandatory for the Fusion peer, but direct connections between Fusion clients and the dedicated server are typical; relay is a fallback path. Your hosting rules still need to account for the actual public endpoint/port mode you choose.

The hosting implementation can be a VM process manager, containers plus a scheduler, Kubernetes/Agones, or a managed game-server platform. Crux does not currently provide general Unity/Fusion fleet hosting, so the Crux role in this architecture is the persistent backend layer, not the Unity process scheduler.

5. Handling Persistent Data (Inventories and XP)

Fusion's replicated match state is not a durable progression database. If a process dies before important progress is committed elsewhere, that progress can be lost. The right persistence strategy depends on the game: transactional rewards may be written immediately, while noisier state can be checkpointed or batched.

Do not give a modified game client direct authority to award itself trusted currency, inventory, rank, or match results. Let the authoritative server validate the game event, then write the durable consequence through a server-side backend credential:

1. When the player performs an action (e.g., kills an enemy), they send a Fusion RPC to the Server.
2. The Server validates the action (was the enemy actually there? was the weapon in range?).
3. If valid, the Server updates the Fusion [Networked] state, which replicates the change visually to all clients.
4. Simultaneously, the Server makes an asynchronous HTTP request using UnityWebRequest to your Backend API to update the persistent database.

6. Cost: Photon Cloud + Dedicated Compute Are Separate

Server Mode adds a hosting bill on top of Photon. Photon prices its cloud service primarily around peak CCU and traffic; the machine/process running the headless Unity build is third-party compute that you price separately. Photon itself describes dedicated-server topology as the higher-operations-cost option because you own that additional hosting layer.

Do not model every headless server process as “one extra player CCU.” In Fusion a dedicated server is not a PlayerRef and does not consume a player slot in the session. For current Photon plan limits, commercial-free eligibility, traffic allowance, Premium/Enterprise options, and exact fees, use the separate pricing guide and verify against Photon before launch.

The infrastructure equation is therefore: Photon cloud plan + bandwidth behavior + dedicated game-server compute/orchestration + your persistent backend. Optimize those as separate layers rather than assuming one vendor meter represents the whole multiplayer bill.

Summary and Next Steps

Fusion Server Mode answers the simulation-authority question; it does not collapse hosting, player identity, durable progression, and fleet lifecycle into the same product. A clean production design names each of those boundaries and tests them independently.

If you do not want to build the persistent HTTP/API layer yourself, a game backend can own player accounts, versioned state, leaderboards, economy and server registry while Fusion continues to own realtime simulation.

• Unity Dedicated Server Integration Guide
• The Game Backend Infrastructure Stack
• Player Authentication Patterns
• Return to the Game Server Backend hub
• Photon Fusion Connection Tokens and Custom Player Data