Unity ended direct support for Multiplay Game Server Hosting on March 31, 2026. If your team relied on Multiplay, the urgent question is not whether you need to migrate. It is how much of your stack actually needs to change.
For most studios, the answer is less than it looks. Unity Matchmaker, Relay, Lobby, and Distributed Authority still work. The part that changed is the dedicated server hosting layer underneath them. In practice, this migration is mostly about replacing allocation, hosting, and server lifecycle management without turning it into a broader multiplayer rewrite.
This is where Gameye stands out. If you want to keep Unity Matchmaker, avoid another server-side SDK, and move to infrastructure built specifically for dedicated multiplayer servers, Gameye is the cleanest path.
Unity Multiplay shut down on March 31, 2026. What that means now
Unity’s own Matchmaker documentation now treats Multiplay Hosting as deprecated as of March 31, 2026 and points teams toward third-party hosting integrations through Cloud Code modules. In practical terms, that means Unity did not shut down your whole multiplayer stack. It shut down the dedicated server hosting layer that used to sit behind it. See Unity’s Matchmaker hosting providers docs and Matchmaker overview.
That distinction matters because many teams initially frame this as a full multiplayer migration. It usually is not.
If your current stack uses Unity Matchmaker to form matches, plus Relay, Lobby, or Distributed Authority around it, those services can stay. Your game rules, queues, ticket logic, and player-facing connection flow can stay too. The piece you need to replace is the part that actually allocates and runs dedicated servers for each match.
What stays the same in your Unity multiplayer stack
The easiest way to think about Unity Multiplay migration is to separate matchmaking from hosting.
Unity Matchmaker can stay
Unity documents a Cloud Code based path for third-party hosting providers, and Matchmaker continues beyond the Multiplay shutdown. That is the key reason this migration can be narrower than teams expect.
If your matchmaking rules already work, you do not need to redesign them just because the hosting backend changed. You still create tickets, match players, and return connection info to clients. What changes is the allocator behind that flow.
Gameye supports Unity Matchmaker through this exact model. Matchmaker stays in place, and the hosting handoff moves to Gameye through a documented Unity Matchmaker integration path.
Relay, Lobby, and Distributed Authority can stay
Unity’s migration guidance is clear that these services are unaffected by the Multiplay shutdown. If they are already part of your game flow, this is not the moment to replace them unless you already wanted to for unrelated reasons.
That matters for scope control. The more pieces you leave untouched, the easier it is to migrate safely.
Your game logic and client connection flow can stay
The best migration paths preserve the code that differentiates your game. Match flow, server gameplay logic, ticket rules, client networking expectations, and player-facing behavior should not need to change just because you picked a new dedicated server orchestrator.
Gameye is a good fit here because it does not require a replacement SDK in your game server binary. You package your Linux dedicated server in Docker, configure the application, and allocate sessions through the API. The infrastructure changes; your actual game stays yours.
What actually changes when you leave Multiplay
The migration is still real work. It is just narrower than a full stack rebuild.
The hosting provider and allocation path
Under Multiplay, Unity handled the hosting layer directly. After migration, your Matchmaker flow needs to call a third-party allocator instead.
With Gameye, that means replacing the server allocation handoff with a call to POST /session, then polling until the session is ready and returning the host IP and port to the client flow. That is a hosting integration change, not a gameplay rewrite.
The server-side SDK surface
This is one of the biggest reasons Gameye is the best path for many teams.
Multiplay-specific server code — IMultiplayService, allocation callbacks, and readiness handling — should come out during the migration. Some alternative platforms replace that dependency with another server-side SDK or lifecycle contract. That keeps you in the same class of problem you are trying to escape.
Gameye does not. The server binary does not need a Gameye SDK. That lowers migration risk and reduces the amount of platform-specific code you need to maintain going forward.
Containerization and deployment workflow
If your server is not already packaged as a Linux container, it needs to be. That is not Gameye-specific in principle, but Gameye leans into it cleanly: build the dedicated server, wrap it in Docker, push the image, configure ports and regions, and allocate sessions through the API.
For teams that want clearer ownership boundaries between game code and infrastructure, that model is usually easier to reason about than embedding platform lifecycle logic into the server binary itself.
Why Gameye is the best path after Multiplay
If you are evaluating a Unity Multiplay alternative right now, the real question is not just who can host a server. It is who lets you move fast without increasing future platform debt.
Gameye has the strongest case for four reasons.
1. You can keep Unity Matchmaker
This is the highest-leverage reason to prefer Gameye. If your queues, ticket logic, and player grouping already work, preserving them is the fastest way to contain risk.
Unity supports third-party hosting through Cloud Code modules, and Unity provides example modules for this path via the Unity Matchmaker Hosting Providers repository. Cloud Code also has a free tier, which makes it a practical integration surface for teams getting off Multiplay without immediately adding another large platform cost line item. Unity documents both the hosting-provider Cloud Code path and Cloud Code module pricing.
Gameye fits this model directly. Deploy the Cloud Code integration, keep Matchmaker, and move only the hosting backend.
2. No replacement SDK in your game server
A migration is much easier when the hosting vendor does not need to live inside your binary.
With Gameye, you remove the Multiplay SDK and do not replace it with another server-hosting SDK. That means less migration churn now and less lock-in later. For CTOs and infrastructure leads, that is a meaningful architectural advantage, not just a nicer developer experience.
3. The platform is built for dedicated multiplayer servers, not generic compute
Gameye is opinionated about the problem in the right way. It is designed for dedicated game server orchestration across bare metal and cloud, with global deployment, fast session allocation, and matchmaker-oriented workflows. That is a better fit for this use case than a generic infrastructure stack that happens to be able to run game servers.
If your team cares about launch readiness, provider flexibility, and less infra plumbing work, that specialisation matters.
4. It keeps the migration scope under control
The best migration is the one your team can finish without dragging gameplay engineers into weeks of hosting-specific rewrite work.
Gameye keeps the move focused on:
- removing Multiplay-specific server hooks
- containerising the dedicated server
- configuring the Gameye application and regions
- replacing the allocation handoff
That is still engineering work, but it is bounded work.
How Unity Multiplay to Gameye migration works
The implementation path is straightforward.
Remove the Multiplay SDK
Start by stripping Multiplay-specific server hooks from the dedicated server build. In Unity terms, that usually means removing IMultiplayService, related callbacks, and readiness code that existed only for Multiplay lifecycle integration.
Package the server in Docker
Build a Linux dedicated server and package it as a container image. Push that image to your registry so Gameye can deploy it.
Configure the application and regions
In Gameye, configure the image, ports, networking settings, and regions where the game should run. This is the part where you translate hosting assumptions into an orchestration configuration.
Replace the allocation call
Your Matchmaker integration needs an allocator path that can request a server, poll until it is ready, and return connection details. With Gameye, that flow centres on POST /session.
The Gameye docs cover the API flow in full, and the Unity Multiplay to Gameye migration checklist goes deeper on the exact steps.
Unity Multiplay to Gameye checklist
Use this as the working sequence:
- Confirm which services in your current Unity stack are still in use: Matchmaker, Relay, Lobby, Distributed Authority, and any custom backend services.
- Remove Multiplay-specific SDK calls from the server build.
- Build a Linux dedicated server and package it in Docker.
- Configure the Gameye application, ports, and target regions.
- Deploy the Unity Matchmaker Cloud Code integration for Gameye.
- Replace the allocation handoff so Matchmaker asks Gameye for a session and polls until ready.
- Validate client ticket flow, connection timing, and server teardown behaviour.
- Run controlled environment tests before moving live traffic.
If you want the practical version rather than the summary version, start with the Unity Multiplay migration overview and then use the Gameye migration checklist.
When Gameye is a good fit, and when it is not
Gameye is a strong fit if:
- you want to keep Unity Matchmaker
- you want to avoid another server-side SDK
- you run dedicated multiplayer servers and want infrastructure built specifically for that model
- you care about provider flexibility and reducing egress-driven hosting pain
Gameye is a weaker fit if:
- you are using the migration as a reason to replace Unity Matchmaker entirely
- your team wants to stay as close as possible to the historical Multiplay operational model regardless of future lock-in
- you are not willing to move to a containerised dedicated-server workflow
That last point is worth stating plainly. Gameye simplifies orchestration, not packaging. Your team still needs to own the dedicated server build and container image.
The short version
Unity Multiplay migration is not a full multiplayer rewrite unless you turn it into one.
If your goal is to keep Unity Matchmaker, preserve your existing multiplayer flow, and swap out only the hosting layer, Gameye is the best path. It supports the Unity integration model that exists today, avoids replacing one server-side SDK with another, and keeps the work focused on infrastructure instead of gameplay code.
Start with the migration overview, review the migration checklist, and use the Gameye docs when you are ready to wire the allocator path.