Unity Game Server to Gameye Migration

Why move away from Unity Game Server Hosting?

Unity Game Server Hosting (Multiplay) is tightly integrated into the Unity ecosystem. That’s great when you’re all-in on Unity.
But as your studio grows, you might want:

Engine independence across multiple projects
More control over infrastructure, providers, and regions
Better cost visibility and levers as concurrency grows
Less strategic lock-in on a single vendor for both engine and hosting

We hear the same concerns again and again: teams want the convenience of managed hosting, but with the flexibility to choose their own stack.

Gameye focuses on one job: orchestrating your dedicated servers, wherever they live.

What actually changes (and what doesn’t)

The reassuring bit: your core multiplayer stack doesn’t have to change.

What usually stays the same

Your authoritative server code and game logic
Your networking model (custom UDP/TCP, Photon, Unity netcode, etc.)
Your matchmaking rules and queues
The client flow: “get IP + port, then connect”

What usually changes

You run your dedicated server as a Docker image, not a bespoke VM setup
Your matchmaker or backend calls the Gameye Session API, instead of Unity’s hosting APIs
Capacity and regions come from Gameye’s orchestrator (multi-provider, multi-region), not from Unity’s fleet

So you’re not “rewriting your multiplayer”. You’re changing how servers get spun up, scaled, and torn down.

A practical migration plan for CTOs

From a leadership point of view, you want something you can roll out safely, measure, and reverse if needed.

Think of the migration in four stages.

1. Check your dedicated server is ready

First, confirm you have a Linux headless dedicated server build that runs cleanly outside the editor:

No hardcoded assumptions about specific infrastructure
Ports and config controlled via environment variables or config files
Logs written somewhere you can pick up in containers

If you’re already on Unity Game Server Hosting, you’re almost certainly here already.

For a more detailed checklist, see our guide:
Getting ready to start with Gameye</a >.

2. Containerise the server

Gameye runs dedicated servers in Docker containers, so the next step is packaging your build.

At a high level:

Write a Dockerfile that:
- Copies your headless build into the image
- Exposes the game server port(s)
- Starts the server as the entrypoint
Add this to your CI pipeline so every server release publishes a tagged image
Decide on a clear tagging scheme (for example, mygame-server:1.4.2)

Result: every release is a versioned image that Gameye can schedule across providers and regions.

3. Replace orchestration calls

This is where you swap Unity hosting out for Gameye.

Today, with Unity hosting, the flow is roughly:

Matchmaker builds a match
Unity hosting (Multiplay) allocates a server
Unity returns IP + port to the client

With Gameye, the flow becomes:

Matchmaker decides on match parameters (region, game mode, version)
Your backend calls the Gameye Session API to create a session with those parameters
Gameye spins up a container in the right location and returns connection details
Client connects to the IP + port from Gameye

Your matchmaking logic doesn’t need to change; you’re just changing who you ask for capacity.

4. Validate, then roll out gradually

Before you send real players through the new path, you’ll want to validate:

Functionality: sessions start, stop, and recycle correctly in all regions you care about
Performance: startup time, latency, and failure rates are at least as good as your Unity setup
Cost: you can see and control what you’re spending per CCU/CCM, region, and provider

On rollout, you don’t need a single “flag day”. Safer options:

Move one region at a time (for example, start with a secondary region)
Move one game mode or queue at a time
Use percentage-based routing in your matchmaker (e.g. 10% of EU matches use Gameye, then ramp up)

To help you decide what to monitor during this phase, you can use the checklist in:
Top ten metrics for your server infrastructure</a >.

Because Gameye is provider-agnostic and API-driven, you can keep Unity hosting running in parallel while you migrate.

What your teams actually have to do

To keep this from becoming a giant “infrastructure project”, be clear about ownership.

Backend / infrastructure team

Own the Dockerfile and container build
Integrate the matchmaker/backend with the Gameye Session API
Plug logs and metrics into your existing observability stack

Gameplay / networking team

Confirm server behaviour and netcode are unchanged
Help define health checks and lifecycle hooks (for example, when to mark a server “ready”)

Production / LiveOps

Plan rollout order (regions, modes, percentages)
Track KPIs across the old and new paths: queue times, match start times, error rates, cost

This keeps the impact on day-to-day game development low.

Why this matters at CTO level

From a CTO’s perspective, the benefits go beyond “it works”.

Reduce strategic lock-in

Your hosting strategy is no longer tied to a single engine vendor
You can experiment with different engines, networking stacks, or backend tools without redoing hosting each time
You’re not constrained by a single provider’s roadmap and commercial terms

Get stronger cost and infra levers

Mix and match cloud, bare metal, and flex metal depending on your needs
Optimise for latency in some regions, cost in others
Scale up for platform events and sales without hard caps or scary surprise bills

If you want to go deeper on sizing and planning, this is a good companion read:
How to calculate the resource profile for your multiplayer game</a >.

Align with how the rest of your backend works

Containerised game servers fit naturally into modern DevOps workflows
The same practices you use for microservices (CI/CD, rollbacks, observability) now apply to your multiplayer
servers
Your infra team has clearer, more standard tools to work with

Plan your migration

If you’re thinking about moving from Unity Game Server Hosting to Gameye, a good first step is just
seeing how your architecture would map across:

Which regions and providers you’d use
What your CI/CD pipeline would look like for server images
How long it’d take to get a first test environment running

If you’d like to explore that with us:

Book a call with our team – we’ll walk through your current setup and sketch a migration plan
tailored to your game
Or get in touch via our contact page and tell us about your game; we’ll set up an evaluation
environment so you can try Gameye with real sessions before committing

How to move from Unity Game Server Hosting to Gameye