Unity Gaming Services 2026: MPS, UGS & Alternatives
Current map of Unity Multiplayer Services and UGS: what MPS unifies, what still lives elsewhere in UGS, and when a separate persistent backend makes sense.
Unity's backend stack changed shape in 2026, but it did not disappear. The current Multiplayer Services (MPS) SDK wraps Lobby, Relay and Matchmaker behind a sessions-oriented API. The old standalone Lobby, Relay and Matchmaker SDK packages are deprecated in favor of com.unity.services.multiplayer; their functionality remains available through MPS.
Do not confuse two changes: Unity concluded direct support for Multiplay Game Server Hosting in March 2026. Separately, Unity is consolidating the client SDK surface for Lobby, Relay and Matchmaker into MPS. "Multiplay hosting is deprecated" is not the same statement as "Unity multiplayer services were shut down."
The current Unity multiplayer layer
| Job | Current Unity path | When a separate backend is useful |
|---|---|---|
| Group/session coordination | MPS Sessions | Usually keep Unity if it fits your networking topology |
| Lobby / quick join | Lobby through MPS | Only replace if you need a materially different discovery model |
| Relay | Relay through MPS | A persistent BaaS is not a Relay replacement |
| Rule-based matchmaking | Unity Matchmaker through MPS | Compare only if your rules/workflow do not fit |
| Persistent player state | UGS services such as Cloud Save, or another backend | Useful boundary for portable data and one API across engines |
| Dedicated fleet hosting | Choose a hosting provider / migration path | Crux backend can stay independent of the host |
MPS: the part many older guides now describe incorrectly
Unity's current documentation says the MPS SDK unifies Lobby, Relay and Matchmaker and introduces sessions as the coordination abstraction. Sessions can work with client-hosted Relay-style connections or dedicated-server experiences and can sit beside Netcode for GameObjects or Netcode for Entities.
That means an architecture diagram written around three standalone Unity SDK packages is now stale even if the underlying services are still part of the design.
What Crux is — and is not — an alternative to
Crux is strongest where you want a narrower, portable persistent-backend contract: player auth, JSON documents, stats, achievements, leaderboards, economy, live config and server registry. It is not a replacement for Unity Relay, Netcode, or the MPS sessions abstraction.
- Choose Unity MPS when Unity-native session orchestration, Lobby, Relay or Matchmaker solves the job.
- Add Crux beside it when persistent player/game state should live behind a separate API boundary.
- Use only Crux backend primitives when your connectivity/matchmaking comes from another networking stack or hosting provider.
- Stay fully inside UGS when the first-party operational model fits and portability is not a concern.
Pricing: model the services you actually call
MPS Sessions is an abstraction over underlying Unity services; Unity documents that usage can contribute to billing for services such as Relay, Lobby, Matchmaker, Distributed Authority and Cloud Code depending on the path used. Avoid a single invented "UGS monthly price". Model your actual player/session/traffic pattern and compare it with the backend workload you would move elsewhere.
Dedicated hosting is the separate 2026 migration problem
Unity concluded direct support for Multiplay Game Server Hosting on March 31, 2026 and its status notice marks the Unity service deprecated from April 1, with an exception for customers already migrating to Multiplay by Rocket Science. This affects the fleet-hosting decision; it does not invalidate MPS sessions, Lobby, Relay or Matchmaker.
A low-risk way to evaluate a split stack
- Keep your existing Unity networking path unchanged.
- Create a separate backend project and prove one player-data request from Unity.
- Move one low-risk persistent primitive first — for example a test leaderboard or profile document.
- Measure operational complexity, cost and debugging ergonomics before moving more state.
- Keep hosting, realtime networking and persistence separable so each can move independently later.
Current primary sources
Sources
Technical, pricing, and product claims were checked against these primary sources on the verification date above.