Migration

/

PlayFab

Published

Published

Published

Last reviewed for accuracy

Last reviewed for accuracy

Last reviewed for accuracy

Migrate from PlayFab Multiplayer Servers with zero impact on your players

Migrate from PlayFab Multiplayer Servers with zero impact on your players

Keep PlayFab. Your matchmaker, economy, auth and Player Data stay exactly where they are: only the servers move, and with them the Azure VM bill you pay for standby capacity that sits waiting between peaks.

Remove the GSDK, containerize the build you already have, and let a PlayFab Azure Function deploy on Edgegap the moment a match is found. Edgegap’s hybrid orchestration combines bare metal Private Fleets with our Edge Cloud network of 615+ locations to keep your hosting cost-effective. Each Edge Cloud deployment goes to the best available location at request time, measured from the players in the match.

No credit card required. Free tier includes the resources to deploy a real game server.

No credit card required. Free tier includes the resources to deploy a real game server.

What changes (and doesn't change)

Changes to expect, at a glance

A PlayFab Multiplayer Servers migration is a hosting change, not a backend change. Here's what to expect from your migration.

A full feature-by-feature breakdown is in Step 3: Identify & Replace features below.

What Remains the Same

Your netcode and transport

Edgegap never touches your transport, serialization or tick loop. The container runs the same server binary you build today.

Your PlayFab backend

Matchmaking queues and rules, Player Data, economy, auth, leaderboards and CloudScript all stay in PlayFab. This migration touches Multiplayer Servers and nothing else in your title.

Your client connect flow

Your client still receives an address and a port and connects to it. In the documented bridge it still reads them from PlayFab Player Data, exactly as it does today.

Engine, versions & CI

Same engine, same version, same build pipeline. Nothing in your CI needs a new step beyond pushing the image.

What Changes

The GSDK comes out

The PlayFab Game Server SDK leaves your binary: the agent start-up, the ready and session callbacks, and the health and state reporting it runs on a loop. Edgegap needs no server SDK. Your server reads its public IP and ports from environment variables at deployment.

One deploy call replaces the standby pool

Instead of requesting a server from capacity you provisioned in advance, a PlayFab Azure Function posts once to the deploy endpoint when a match is found, and the deployment is created for that match.

Regions stop being a purchase decision

You no longer size VM capacity region by region. Each deployment is placed at the best available location on the Edge Cloud network at request time, measured from the players in the match.

The standby math goes away

No standby target to calculate, no percentage thresholds and multipliers to tune per region, no ramp-down window, and no pool to keep warm between peaks. Capacity stops being your job: Private Fleets get resized with us as your traffic curve moves, and Edge Cloud has nothing to pre-provision at all.

Expected Timeline

Five simple steps

Most studios reach end-to-end validation in under two weeks, including parallel running while traffic rolls out.

Most studios reach end-to-end validation in under two weeks, including parallel running while traffic rolls out.

Total: under 1 week

Total: under 1 week

Step 1

Remove the GSDK

Remove the GSDK

Remove the PlayFab Game Server SDK: agent start-up, the ready and session callbacks, and the health and state reporting loop.

~2 hours

Step 2

Your PlayFab backend

Your PlayFab backend

If you already ship a Linux container build, the artifact is unchanged. Windows-only builds need a Linux server build first, which is the one genuinely large task on this migration.

~30 min. to 2hrs.

Step 3

Push to a Registry

Push to a Registry

Edgegap's registry is available for free, or keep ACR, DockerHub, GitLab, etc.

~30 min.

Step 4

Bridge the matchmaker

Bridge the matchmaker

A match_found rule runs an Azure Function that deploys on Edgegap, and each player gets the address in read-only data once the server is ready.

~1 day

Step 5

Deploy Globally

Deploy Globally

Deploy globally on Edge Cloud, and optionally cut cost further with egress-free hosting on Private Fleets.

Instant Rollout

Detailed migration steps

The migration steps, in detail, with the code

If you are looking to move your game servers off PlayFab Multiplayer Servers while keeping the rest of PlayFab, the following simple steps will get you running in no time. Full instructions, including a working Unity sample: PlayFab Matchmaking with Edgegap sample.

Before getting started, it helps to be clear on what moves and what does not.

Only Multiplayer Servers moves: PlayFab keeps your matchmaker, Player Data, economy and auth, and Edgegap becomes the place the matched server runs. Edgegap is an API, with no server SDK.

We expect that: you currently use PlayFab Multiplayer Servers, you have a working game server build, you can add automation rules in your title, and you have an Azure subscription for the two Azure Functions.

Step 1:

Remove the PlayFab Game Server SDK

Edgegap does not require a server SDK to integrate. The first step is to remove the code that initializes the PlayFab Game Server SDK in your game server: the agent start-up call, the callbacks you registered for server activation and session assignment, the shutdown and maintenance handlers, and the health and player-state reporting the agent expects on a loop. Nothing replaces them. On Edgegap your server reads what it needs from environment variables injected at deployment, including its public IP and its port mapping, and it is ready for players as soon as it is listening. If you used the GSDK wrapper rather than a direct integration, that comes out too, and PlayFab's own documentation notes the wrapper "is not meant for production use".

Step 2:

Containerize your game server

If you already run Linux container builds on PlayFab, this step is a check rather than a rebuild: confirm the image builds and starts locally, then push it to Edgegap's free registry, or keep ACR, DockerHub, GitLab or any other OCI-compatible registry.

If your title runs Windows VM builds, you need a Linux server build first. That is real work, but Edgegap's dedicated plugins for Unity, Unreal Engine and Godot help you build the image automatically once you have a Linux server target.

Step 3:

Identify & Replace features

GSDK feature

Edgegap replacement

Game Server SDK (GSDK)

No server SDK. Ports and variables injected at deployment.

Builds and VM sizes

Apps and Versions. Choose vCPU and memory per version, fractionable from 0.25 vCPU.

Build regions

No region configuration. Placement at request time at the best available location on the Edge Cloud network for on-demand compute, Private Fleets on bare metal for reserved capacity.

Standby servers and target standby math

Automatic scaling for on-demand compute (Edge Cloud). Private Fleets on bare metal for persistent capacity, rightsized monthly.

Dynamic and scheduled standby

Not required. Overflow to Edge Cloud is automatic.

RequestMultiplayerServer

One POST to the deploy endpoint, from an Azure Function on the match_found rule, or your backend.

PlayFab matchmaker

Unchanged, with server allocation turned off on the queue. A match_found rule triggers the deployment.

Server connection details

Written to each player’s read-only player data by a second Azure Function once the server is ready, and read by your client. Your game server holds no PlayFab secret.

Server logs and archived servers

Deployment logs, Deployment Status API and Deployment Webhook.

Server management in Game Manager

Edgegap Dashboard, Deploy API and Deployment Analytics and Monitoring.

Porting work

Optional: connect your coding agent to the Edgegap MCP server. It loads Edgegap’s tested agent skills for your engine, then builds or checks your image, uploads it and deploys your server, and every change can be previewed as a dry run first. The PlayFab skill sets up the queue, the two Azure Functions and the match_found rule end to end.

Step 4:

(Optional) Setting up Private Fleets

Private Fleets are the closest thing to the capacity you manage today: persistent, dedicated bare metal hosts with egress-free hosting.

The difference is the work around them. There is no standby target to compute, no per-region thresholds or multipliers to tune, and no ramp-down window. You rightsize the fleet monthly, and when a Private Fleet is full, deployments overflow onto Edge Cloud automatically.

Pricing

Price Comparison

Discover how Edgegap's orchestration is cost effective versus your current PlayFab Multiplayer Servers bill.

Cost driver 1: standby capacity versus deployments.

PlayFab's own guidance is to size a standby pool from propping time and allocation rate, and it states that servers in the propping and standing-by states are billed to your title.


PlayFab Multiplayer Servers

Edgegap

Idle capacity

Billed. Standby and propping servers run and bill between peaks

Not billed on Edge Cloud. Zero active deployments costs $0

Sizing method

Standby target calculated from propping time and target allocation rate, per region

Nothing to size on Edge Cloud. Private Fleets rightsized monthly

Failure mode

Standby pool starvation: server requests fail when demand outruns provisioning

Deployments are created per match, provisioned from scratch in 2 seconds, median, to container ready

Cost driver 2: VM sizes versus fractional vCPU.

You buy a machine shape on PlayFab. You buy compute on Edgegap.


PlayFab Multiplayer Servers

Edgegap

Unit

VM size chosen by cores, RAM and storage, per build region

vCPU-minute, fractionable from 0.25 vCPU

Granularity

Whole machines, plus servers-per-machine packing you manage

Per deployment, with no packing decisions

Rate

Per VM size, per region, per PlayFab's published price list

$0.00115 per vCPU per minute worldwide, single price

Cost driver 3: hybrid orchestration at scale.

A fleet sized for peak is idle most of the week. Hybrid orchestration keeps hosting cost-effective by combining bare metal Private Fleets with on-demand Edge Cloud.


PlayFab Multiplayer Servers

Edgegap

Reserved capacity

Standby pools you size per region, tuned with thresholds and multipliers

Bare metal Private Fleets, rightsized monthly as the traffic curve moves

On-demand capacity

Dynamic standby multiplies the target standby you configured, up to your maximum servers

Edge Cloud network of 615+ locations, each deployment at the best available location at request time

Net effect at thousands of CCU

Capacity planning as an ongoing operational task

25 to 35 percent below pure cloud with a properly optimized split. Model it in the pricing calculator

Pricing

Optimize costs and performance with hybrid orchestration

Optimize costs and performance with hybrid orchestration

Optimize costs and performance with hybrid orchestration

Edge Cloud

On-Demand

$0.00115

/ vCPU

/ MINUTE

Billed by the Minute, Only on Usage

Pay only when players play. 0 active servers = $0

Deploy game servers worldwide, per instance, to all 615+ edge cloud locations. Zero commitment.

Simply add a credit card.

Edge Cloud

On-Demand

$0.00115

/ vCPU

/ MINUTE

Billed by the Minute, Only on Usage

Pay only when players play. 0 active servers = $0

Deploy game servers worldwide, per instance, to all 615+ edge cloud locations. Zero commitment.

Simply add a credit card.

Private Fleet (Bare Metal)

Reserved Capacity

$0.0261

/ vCPU

/ HOUR

Billed Monthly, Always On

$280 per host/month (12 mo rate), or $350 monthly

Optimize the cost effectiveness of your game server with egress-free hosting of Private Fleets.

Persistent, available 24/7, exclusive to your studio.

Private Fleet (Bare Metal)

Reserved Capacity

$0.0261

/ vCPU

/ HOUR

Billed Monthly, Always On

$280 per host/month (12 mo rate), or $350 monthly

Optimize the cost effectiveness of your game server with egress-free hosting of Private Fleets.

Persistent, available 24/7, exclusive to your studio.

Your bill varies per rate and usage; which can vary per game type, player count, & more.

Your bill varies per rate and usage; which can vary per game type, player count, & more.

Model your usage with our estimate calculator ->

Model your usage with our estimate calculator ->

Edgegap's features & price: detailed comparison between Edge Cloud & Private Fleets

Edgegap's features & price: detailed comparison between Edge Cloud & Private Fleets

COMPARE

Free Trial

Edge Cloud

Private Fleets

FEATURES

Analytics & Monitoring

Billing Alarms

Click to Expand

28 more rows

Unlocks

Capabilities are unlocked when a credit card is added to the account.

COMPARE

Free Trial

Edge Cloud

Private Fleets

FEATURES

Analytics & Monitoring

Billing Alarms

Click to Expand

28 more rows

Unlocks

Capabilities are unlocked when a credit card is added to the account.

COMPARE

Free Trial

Edge Cloud

Private Fleets

FEATURES

Analytics & Monitoring

Billing Alarms

Click to Expand

28 more rows

Unlocks

Capabilities are unlocked when a credit card is added to the account.

Features Comparison

Features Comparison

Edgegap

Azure PlayFab

Orchestration

Hybrid orchestration, no game server SDK required:

Infrastructure

Single provider:

Hardware

Placement

Pricing

Scalability

Integration

Support

24/7 for clients, free. Available on Discord, Slack, email

Latency

58% average reduction vs. public cloud (Edgegap case study)

Track Records

Clients

Learn more from clients who migrated to Edgegap

15 case studies are available from studios that moved to Edgegap from another platform.

Key reasons why they chose Edgegap

Key reasons why they chose Edgegap

Discover the impact of Edgegap's automated game server orchestration for a flawless multiplayer experience.

Frequently Asked Questions

Edgegap is the hosting & orchestration experts. Our platform is tailor built to help you speed up your development process, which allows you focus on what you excel at - development.


Do I have to leave PlayFab?

No. This migration moves Multiplayer Servers only. Your matchmaking queues and rules, Player Data, economy, auth, leaderboards and CloudScript stay in PlayFab and keep working exactly as they do now. The integration is two Azure Functions: a match_found rule runs the first, which deploys a server on Edgegap near the matched players, and Edgegap calls the second when the server is ready, which writes the address and port into each player's read-only data for the client to read. Your game server holds no PlayFab secret. We publish the whole thing as a working Unity sample, and the PlayFab skill for the Edgegap MCP server can set it up with your coding agent.

What happens to the GSDK in my server?

It comes out and nothing proprietary replaces it. The agent start-up, the ready and session callbacks, the shutdown handler and the health-report loop all go. On Edgegap your server reads its public IP and port mapping from environment variables at deployment and is ready as soon as it listens. If you integrated through PlayFab's GSDK wrapper rather than directly, that comes out too; their own documentation says the wrapper "is not meant for production use".

What replaces standby servers and dynamic standby?

Today you calculate a standby target from propping time and allocation rate, set maximum servers per region, and tune dynamic standby thresholds and multipliers so the pool does not starve, with servers in propping and standing-by states on your bill throughout. On Edge Cloud there is no pool: each match gets a deployment, provisioned from scratch in 2 seconds, median, measured to container ready, before the game engine starts. If you want capacity that is already yours, Private Fleets give you that, rightsized monthly rather than tuned per region.

My server build is Windows. Does that block me?

It is the one thing on this page that can be real work, so here it is plainly: Edgegap runs Linux containers, so a Windows-only server needs a Linux build before anything else. For most Unity and Unreal projects that is a build target and a pass over platform-specific code. If your server depends on Windows-only libraries it is a project, and it needs an honest look at what that means for your architecture. That is a conversation we are happy to have: talk to our engineers and we will work through the move to Linux game server instances with you. If you already ship Linux container builds on PlayFab, none of this applies and your artifact is unchanged.

Does my PlayFab matchmaker keep working the way it does today?

Yes. Queues, rules, tickets and the matchmaking behaviour your players experience are untouched, because PlayFab is still doing the matchmaking. Two things change. Server allocation is turned off on the queue, so PlayFab only forms the match. And instead of requesting a server from your provisioned capacity, the match_found rule runs an Azure Function that posts once to Edgegap's deploy endpoint with the players' locations, so the server is placed for the players actually in that match. If you would rather consolidate later, Edgegap's no-code matchmaker is there, but nothing about this migration requires it.

Where do the savings actually come from?

Mostly from capacity you stop paying for while it waits. PlayFab bills servers in the propping and standing-by states, so a pool sized for your peak allocation rate runs and bills through every quiet hour. On Edge Cloud, zero active deployments costs $0, and compute is $0.00115 per vCPU per minute, fractionable from 0.25 vCPU, rather than a VM size you pick per region. At thousands of CCU, a properly optimized split of Private Fleets and Edge Cloud lands 25 to 35 percent below pure cloud. Model your own traffic in our pricing calculator rather than taking the range on faith.

Methodology

How we measured

Each metric states what is measured, over what window, and what is excluded. Benchmark results are dated to the test that produced them and are not restated as current figures.

Orchestration Platform Scale

Where servers can run, and how many we have run.

Inventory

Global Edge Cloud locations

615+locations

Distinct deployment targets where a game server container can be scheduled on demand.

Platform inventory
How we measure this
Live

Private Fleet locations

58locations

Locations where a studio can reserve Private Fleet hosts for its exclusive use.

Published live
How we measure this
Cumulative

Game server deployments to date

135million deployments

Total game server deployments orchestrated since February 2019, including deployments that failed to start, the same basis our competitors use.

Since February 2019
How we measure this

Performance Under Load

How fast our orchestration delivers a server, and what it sustains under test.

Rolling 30d

Server deployment time

2seconds · median

From cold start: provisioned from scratch, not allocated onto an already-running server. Measured to container ready, before the game engine starts.

Rolling 30-day window
How we measure this
Benchmark

Sustained deployment rate for each game

40per second

Started deployments per second, averaged over a continuous 60-minute benchmark. The standard rate for each game from confirmed studios with live traffic; higher rates are available on request.

November 2023 benchmark
How we measure this
Benchmark

Concurrent capacity for each game

14million concurrent

Concurrent sessions reached on real game server containers, at 100 players per server.

November 2023 benchmark
How we measure this

Reliability

What we commit to contractually for our orchestration, and what the monitors record.

Committed

Availability

99.99%SLA commitment

Committed under our SLA. Trailing 90-day measured uptime: 99.999%.

Trailing 90 days
How we measure this
Inventory

Provider redundancy

17+providers

Cloud and bare-metal providers under contract and carrying production traffic. Failover is automatic.

Platform inventory
How we measure this

Live component status is published at status.edgegap.com.

How We Measure

One entry per metric: what is measured, how, and over what window.

Global Edge Cloud locations

A location is a distinct deployment target: one datacenter site at one of our infrastructure providers, in which a game server container can be scheduled on demand. Sites are counted once each regardless of how many providers operate in the same metro, and count only while accepting deployments.

Back to the metric ↑
Private Fleet locations

Counted separately from the 615+ Edge Cloud locations, which are on-demand cloud capacity: a Private Fleet location is a site where a studio reserves hosts for its exclusive use. Published live on the Fleet Manager page. Each Private Fleet host includes 6 TB of egress per month.

Back to the metric ↑
Game server deployments to date

Counted as total deployment records since February 2019, including deployments that failed to start, the same basis our competitors use.

Back to the metric ↑
Server deployment time

From cold start: provisioned from scratch, not allocated onto an already-running server. Measured to container ready, before the game engine starts.

Back to the metric ↑
Sustained deployment rate for each game

The orchestrator started real game server containers continuously for 60 minutes, averaging 40 started deployments per second over the full hour, counted at deployment start rather than at ready state. Measured across 550+ locations and 17 providers in November 2023. The benchmark ran for a single game. Capacity is allocated per game, so every game on the platform can scale to this level independently and at the same time. 40 per second is the standard rate. Studios that need more can plan a higher rate with us: in an October 2026 client load test, deployments peaked at 70 per second, with 85 in a single second, through the same production API and scheduler every customer uses, with no measurable impact on other customers. How we ran the test.

Back to the metric ↑
Concurrent capacity for each game

In November 2023, the platform sustained 40 game server deployments per second for 60 minutes across 550+ locations and 17 providers, reaching 14 million concurrent sessions at 100 players per server. Game servers were real containers; player clients were simulated. The benchmark ran for a single game. Capacity is allocated per game, so every game on the platform can scale to this level independently and at the same time.

Back to the metric ↑
Availability

Availability is committed at 99.99% under our SLA and measured continuously against five independently monitored components: Container Registry, Dashboard, Public API, Public Documentation and Website. Trailing 90-day measured uptime: 99.999%. The live figure is published on status.edgegap.com.

Back to the metric ↑
Provider redundancy

Distinct suppliers under contract and carrying production traffic, counted at corporate-entity level. Failover across providers is automatic; it is the premise of the multi-cloud architecture.

Back to the metric ↑

How We Keep This Current

What gets reviewed, on what cadence, and what carries its own date.

Platform figures on this page are reviewed and refreshed quarterly. Metrics drawn from live sources (availability and game server deployments) carry their own as-of dates and are updated as measured. Benchmark results are dated to the test that produced them and are not restated as current figures.

Last updated
Next reviewor earlier

Get your Game Online Easily & in Minutes

Start Integrating Now!

Get your Game Online Easily
& in Minutes