Does Crux replace Photon Fusion?

No. Photon Fusion is the realtime networking and simulation layer. Crux is the persistent backend beside it: player authentication, durable documents, stats, achievements, leaderboards, economy, live config and server registry. Use both when the game needs both jobs.

Does Crux have a Photon-specific adapter?

Not today. The supported path is the Crux Unity SDK or REST API alongside Photon Fusion. Photon Custom Authentication can call a backend service you operate, but Crux does not currently expose a drop-in Photon Custom Authentication endpoint.

What should stay in Photon and what should go in Crux?

Keep room/session networking, state synchronization, prediction and lag compensation in Photon. Keep durable player state, progression, leaderboards, economy, backend-owned config and server registry in Crux.

Photon Fusion · Unity

Keep Photon for realtime. Put persistent game state somewhere built to persist.

Photon Fusion solves realtime networking and simulation. Crux sits beside it for the parts that must survive the room: player identity, saves, stats, achievements, leaderboards, economy, live config and server discovery.

Create a free Photon/Unity backend → See the Fusion architecture

No Photon replacement, no lock-in claim. Start with one Unity API call, then keep only the backend pieces your Fusion game actually needs.

Division of responsibility Photon + Crux

Photon Fusion
  rooms / sessions
  state sync + prediction
  lag compensation
  realtime transport

Crux
  player auth + sessions
  persistent documents
  stats + achievements
  leaderboards + economy
  live config
  server registry

Verify before you integrate

Inspect the backend layer before you add it to Fusion.

The Unity SDK is MIT licensed, the hosted API contract is public OpenAPI, current service health is live, and the exit commitment is written down.

Live API status

A live check of the hosted API right now. No made-up uptime percentage and no hidden demo environment.

Check current status

Public API contract

The hosted HTTP surface is documented as OpenAPI. Inspect the wire format before choosing an SDK or writing an adapter.

Open the spec

MIT client SDKs

The JavaScript, Godot, Unity, and Roblox client SDK source is public. The hosted backend itself remains a managed proprietary service.

Inspect the SDK source

Documented exit path

Read what is exportable today and the written commitment for advance notice plus an export window if the hosted service winds down.

Read the exit guarantee

Unity SDK source

Read the exact C# client used for player-side publishable-key calls and server-token operations before adding it beside Fusion.

Inspect the Unity SDK

Layer boundary

Do not make Photon carry durable backend jobs.

Photon documents Fusion as the networking/state-synchronization layer and supports multiple authority topologies. Its Custom Authentication flow can delegate identity checks to a web service. Crux complements that architecture; it does not replace Fusion's simulation or transport.

Keep in Photon

Fusion rooms, sessions and matchmaking properties
Networked state, RPCs, prediction and rollback/resimulation
Host, Server or Shared authority topology
Lag compensation and realtime connection behavior

Put in Crux

Guest/email player identity and durable player records
Cloud saves, stats, achievements, inventories and currency
Leaderboards that persist across sessions
Backend-owned live config and project documents
Dedicated-server registration and heartbeat data

Shortest evaluation

Prove the backend independently of Photon first.

Before wiring two systems together, make one authenticated Crux request from Unity. That isolates backend credentials and data calls from Fusion networking, which makes integration failures much easier to debug.

Crux does not currently ship a drop-in Photon Custom Authentication provider. If you need Photon Custom Authentication, keep that adapter as an explicit web-service boundary and use Crux behind or beside it for durable state.

Create the free project and run the live sample.
Open the Unity SDK setup with the real project/environment IDs filled in.
Run the generated C# from your Unity project; Crux confirms the external connection.
Keep Fusion responsible for realtime state and call Crux only for persistent/backend-owned state.
If you run Fusion Server Mode, use a Crux server token from the trusted headless process for authoritative writes.

Start the Unity backend path → Read the Unity quickstart

Photon decision paths

Your question	Start here
Fusion Server Mode + persistent backend	Dedicated-server architecture
Realtime networking vs backend responsibilities	Layer comparison
Connection tokens / custom authentication	Authentication guide
CCU pricing and total stack cost	Photon pricing guide
Model backend cost separately	Backend cost calculator

Keep the boundary clean

Photon owns the room. Crux owns what must outlive it.

Test the backend with one Unity call first. If the architecture fits, add only the persistent services your Fusion game needs.

Create the free project →