Photon Fusion Dedicated Server Architecture and Backend Integration

Photon Fusion Dedicated Server Architecture and Backend Integration

Photon Fusion is arguably the most powerful state-sync networking engine available for Unity today. It supports massive player counts, client-side prediction, lag compensation, and sub-tick accuracy. However, a common point of confusion among developers migrating to Fusion is how to handle Server Authority and Persistent Data.

While Photon provides the networking transport (the cloud relay that passes messages between clients), Photon does not provide backend databases or dedicated server hosting. If you want to prevent cheating, validate inventory, or run complex physics, you must deploy an Authoritative Dedicated Server and connect it to a Custom Game Server Backend.

This guide breaks down the architecture required to run Photon Fusion in a true Dedicated Server environment and how to integrate it with an external REST API for persistent player progression.

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 (Relay): The managed infrastructure provided by Exit Games. It routes network packets between the clients and the server, ensuring NAT punch-through and low latency.
• The Headless Unity Dedicated Server: A Linux-compiled instance of your Unity project running Fusion in Server Mode. It acts as the State Authority. It connects to the Photon Cloud just like a client, but it has absolute control over the simulation.
• The Platform Backend (REST API / Database): Your external backend (e.g., Supercraft GSB) 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

Instead of joining a room as a client, the server creates the session and designates itself as the GameMode.Server.

public async void StartDedicatedServer()
{
    var runner = gameObject.AddComponent<NetworkRunner>();
    runner.ProvideInput = true;

    var result = await runner.StartGame(new StartGameArgs()
    {
        GameMode = GameMode.Server,
        SessionName = "EU-Survival-01",
        PlayerCount = 100,
        Scene = SceneManager.GetActiveScene().buildIndex,
        SceneManager = gameObject.AddComponent<NetworkSceneManagerDefault>()
    });

    if (result.Ok)
    {
        Debug.Log("Dedicated Server Started Successfully");
        RegisterServerWithBackendAPI();
    }
}

When running this build on your cloud virtual machine, ensure you launch the executable with the -batchmode -nographics flags to prevent Unity from attempting to initialize a rendering pipeline, which saves massive amounts of RAM and CPU.

3. Securing Connections and Authentication

One of the biggest challenges in multiplayer architecture is ensuring that the person connecting to the server is actually who they say they are. With Photon Fusion, anyone who knows the SessionName can theoretically connect. You must implement a secure token exchange.

Step	Action
1. Client Login	Client sends Steam/Epic/Guest credentials to your Platform Backend via HTTPS and receives a secure JWT (Session Token).
2. Fusion Connect	Client connects to the Fusion session and passes the JWT in the ConnectionToken byte array during StartGameArgs.
3. Server Validates	The Dedicated Server intercepts the connection request, pauses spawning, and makes an HTTP POST request to the Platform Backend to validate the JWT.
4. Approval	If the Backend confirms the token is valid, the server accepts the Fusion connection, spawns the player prefab, and applies their inventory data.

Implementing the Token Check

In Fusion, you can intercept connections using the INetworkRunnerCallbacks.OnPlayerJoined callback, or by utilizing custom authentication endpoints in the Photon Dashboard. However, doing the validation on your Authoritative Server ensures the game simulation remains the absolute source of truth.

4. Orchestrating Unity Dedicated Servers

Running a single headless Unity instance is easy. Running 500 instances across the globe to support thousands of players requires Orchestration. Because Photon Fusion relies on the Photon Cloud Relay for traffic routing, orchestrating Fusion servers is actually much easier than standard UDP servers.

Why? With standard Unreal or Godot servers, the Orchestrator must dynamically assign open UDP ports and manage complex NAT forwarding. With Photon Fusion, the Dedicated Server connects outbound to the Photon Cloud. Therefore, you do not need to open inbound ports on your Kubernetes cluster or AWS instances.

You can package your headless Unity build into a Docker container and use simple auto-scaling groups or Kubernetes deployments. The server simply boots up, connects to Photon, and registers itself with your Backend API so players know it exists.

5. Handling Persistent Data (Inventories and XP)

Fusion is a real-time memory state engine. If the server crashes, any XP earned or items collected during that session are wiped. To prevent this, the Dedicated Server must constantly synchronize state with your Platform Backend.

Do not attempt to have the Unity Client write directly to a database like Firebase or MongoDB. This allows hackers to easily alter their stats using tools like Charles Proxy. Instead, use Server Authority:

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 Considerations for Fusion + Dedicated Servers

It is important to model your operational costs correctly. When running this architecture, you are paying for two separate infrastructure layers:

• Photon CCU Costs: You pay Exit Games for the concurrent users (CCU) connected to their cloud relay, as well as the bandwidth processed by the relay.
• Compute Costs: You pay your cloud provider (AWS, Google Cloud, Supercraft) for the Linux virtual machines running your headless Unity builds.

Because the Unity Headless Server is also a "client" connected to the Photon Cloud, it counts against your CCU limit. If you have 100 servers running, that is 100 CCU utilized just by the servers themselves. Ensure you factor this into your pricing model.

Summary and Next Steps

Photon Fusion is an incredible tool for Unity multiplayer, but it is only half of the puzzle. By deploying an Authoritative Headless Server and integrating it with a robust REST API backend, you transform a local prototype into a secure, commercial-grade MMO or competitive shooter.

To avoid building the database APIs and server registries from scratch, consider leveraging existing Backend-as-a-Service platforms designed specifically for dedicated servers.

• Unity Dedicated Server Integration Guide
• The Game Backend Infrastructure Stack
• Player Authentication Patterns
• Return to the Game Server Backend hub