PlayFab Multiplayer Servers Setup 2026 Step by Step

A multiplayer launch gets easier to manage when you can turn the game server, its deployment settings, and its ready capacity into a repeatable setup. This guide takes you from account readiness to a tested deployment that can grow with your game.

You will prepare a build, deploy it, connect a client, and plan capacity by region. First, confirm that the Servers feature is enabled for the correct title. Propping time is the period PlayFab needs to start a game server and make it ready for allocation.

Keep your first test small enough to inspect, but realistic enough to show how the server starts and handles a match. A working test can reveal missing files, incorrect ports, or limits that need attention before launch.

Key Takeaways

• Enable the Servers feature for the title you plan to use.
• Integrate the PlayFab Game Server SDK into the server build.
• Review fixed build settings before creating the build.
• Choose regions based on your player base and measured latency.
• Set standby capacity using measured startup time and demand.
• Test allocation and client connections before raising limits.

Start with a small deployment in a region near your players, then measure before increasing capacity.

How PlayFab Multiplayer Servers Runs Your Game

PlayFab runs your game server inside a container on an Azure VM that it provisions from the build settings. You supply the server build, then configure how PlayFab should host it.

You do not create or manage each Azure VM directly. PlayFab provisions the hosting environment from your build configuration, while you provide the server executable and required files.

The PlayFab Game Server SDK, or GSDK, must be integrated into your game server build. It lets the server work with PlayFab Multiplayer Servers and report its state to the service.

Build and integrate the game server with the GSDK, then let PlayFab manage the configured Azure hosting environment.

The container is the environment in which your server runs. PlayFab places that container on an Azure VM and manages the hosting resources based on your build and regional settings.

Your own matchmaking logic remains a separate part of the game. It decides which player or group should receive a server, while PlayFab Multiplayer Servers provides hosting and allocation tools.

This separation matters when you plan the connection path. The hosting service can allocate a game server, but your game still needs logic that decides when to request one and how to pass connection details to players.

PlayFab Multiplayer Servers does not require you to create a separate cloud VM for every match. You define how many servers can run on a machine and configure regional capacity through the build.

The service handles the managed hosting layer, not the rules of your game. Your code still controls matches, player sessions, game state, and the steps needed to end each session cleanly.

Treat the server executable and GSDK integration as your responsibilities, and let the configured build define the managed hosting environment.

What Do You Need Before PlayFab Multiplayer Servers Setup 2026?

Before you configure a build, confirm that the correct PlayFab title has the Servers feature enabled. Start with the title, since feature settings apply to the title you select.

A new PlayFab account does not have Multiplayer Servers enabled automatically. Game Manager needs a payment method on the account when none exists before you can enable the feature there.

Use this ordered checklist to enable the feature in Game Manager:

1. Sign in to PlayFab.com.
2. Open My Studios and Titles, then select an existing title or create one.
3. Choose Multiplayer, then Servers.
4. Select Enable on the Servers page.
5. Add a payment method if Game Manager prompts you.
6. Confirm that the Servers feature is available for the selected title.

API or PowerShell activation offers another route for accounts that already have a payment method. When the account has no payment method, use Game Manager to add one and enable the feature.

Keep the title name and studio in view while you work. A studio running several games can have multiple titles with similar names, and enabling the wrong one will not prepare the title you intend to deploy.

You can check the result by returning to Multiplayer, then Servers, for the same title. The page should show that the feature is available rather than asking you to enable it.

Verify the title selection before enabling the feature, since the dashboard settings apply to that title.

Which Azure VM Should You Start With?

For a first deployment, start with the D2as v4 and scale only after observing the server’s actual load. It is a baseline, not a promise that every game will fit.

The D2as v4 has 2 vCPUs and 8 GB of RAM. For 2026, PlayFab recommends starting there for most multiplayer server workloads, then sizing up when a real match shows a need.

Start with a D2as v4 for a baseline

Test a typical match, not just a quiet server waiting for players. Watch CPU and memory use while the server handles the number of players and game systems you expect.

Server density per machine also matters. A VM that runs one server smoothly may behave differently when several game server processes share its CPU and memory.

Record the workload during a representative match, including its busiest moments. If the server struggles or leaves too little room for other processes, test a larger size before changing the production build.

Compare Dasv4 and Fsv2 for workload fit

Dasv4 uses AMD EPYC 7452 processors, offers up to 256 GB of RAM, and has up to 800 GB of SSD-based temporary storage. PlayFab lists its performance at 230-260 Azure Compute Units.

Fsv2 uses Intel Xeon Platinum 8168 processors, with a sustained all-core Turbo clock speed of 3.4 GHz and a maximum single-core turbo frequency of 3.7 GHz. Compare those CPU details with your game’s memory needs before choosing.

Validate the chosen size with a representative match workload, not just an idle server.

How Do Core Quotas Limit Capacity?

A VM size can fit your workload and still be unavailable for deployment if its series and region lack enough quota. Quota is tracked separately for each available compute series and region.

Core quotas are not one interchangeable total. A title may have room in one series but still lack the specific cores needed for a VM in another series or region.

Documented default starting quotas for independent, pro, and enterprise customers include 16 Av2 cores and 8 Dv2 cores. Those starting quotas are split between East US and West US.

A VM’s size tells you how many cores it needs, while the quota shows how many cores your title can use in that series and region. Check both before you plan server counts.

For example, an F4_v2 uses twice the Fv2 cores of an F2_v2. A plan that fits the smaller VM may exceed the available series quota when you raise the VM size or add machines.

Large requests also need lead time. Requests for 1,000 cores or more can take several days to fulfill, so they may not fit a last-minute launch plan.

Request substantial quota well ahead of a launch, since requests at 1,000 cores or more can take several days.

What Goes Into a Build Definition?

Treat the build definition as the versioned package of choices you should review before creating it. Its fixed fields define how the server package will run.

You cannot modify a build definition after creation. You can change its build configuration during the build’s life, so separate fixed choices from regional settings.

Set the build’s fixed definition

The definition includes the VM selection, servers per machine, operating system, container, uploaded assets, start command, and network ports. Optional certificates and metadata can also be part of the definition.

Review each field as a group. The VM, operating system, and container must suit the server, while the uploaded package and start command must point to files that exist in that environment.

Manage region-level build configuration

The build configuration sets the Azure region, standby server count, and maximum server count for that region. You can adjust these regional settings over the build’s life.

A build can therefore have fixed package choices and different capacity settings across regions. The configuration does not change the underlying server executable or its fixed operating system choice.

Incoming-port settings belong with the fixed definition because they describe how clients can reach the server. Keep those entries consistent with the port the game server actually listens on.

Double-check the VM, operating system, start command, and port entries before committing the definition.

How Should You Package the Server Build?

Package the executable and required files in a supported archive before uploading them to the build. Keep the package focused on files the server needs to run.

All uploaded assets combined must be less than 10 GB. Use ZIP, .tar.gz, or .tar format, and check every filename before creating the archive.

Use this packaging checklist before upload:

• Keep the combined uploaded assets under 10 GB.
• Choose ZIP, .tar.gz, or .tar for the archive.
• Use only letters, numbers, underscores, hyphens, and periods in asset filenames.
• Choose Windows or Linux, then match the start command and asset mount path to the container.

PlayFab Multiplayer Servers supports Windows and Linux VM operating systems for builds. Your game server binary, files, and start command must fit the operating system and container you choose.

A path that works on your development machine may not match the asset mount path in the container. Check the command against the uploaded folder structure, including capitalization where your operating system treats it as meaningful.

The Wrapper sample can adapt an existing Windows or Linux server for evaluation. It processes standard output and error streams as a workaround, but it does not replace production GSDK integration.

Use the wrapper only to evaluate an existing server, not as the production integration path.

How Do Ports and Client Connections Work?

Add an incoming port for every connection your game client must make to the server. Each entry names a port number and its TCP or UDP protocol.

Build port settings configure the operating-system firewall and let clients reach the VM through the specified TCP or UDP ports.

Network configuration covers incoming connections. Outgoing or solicited network flows do not need configuration, so list the ports on which the game server accepts new client traffic.

PlayFab virtualizes networking with NAT44. The game server does not directly access its Internet-accessible IP address, so clients receive connection information through PlayFab services.

Game servers have IPv4 connectivity. IPv6 connectivity is documented as a future addition, so plan the current client path around IPv4.

Instances on one VM have separate container IP addresses and separate TCP and UDP port spaces. They still share physical network infrastructure, so heavy traffic can cause contention between instances.

After allocation, clients typically connect directly to the game server using TCP or UDP sockets. The connection details come through PlayFab services, while the client opens the configured game port.

Keep the listening port in the game server, build configuration, and client connection settings aligned.

How Do You Create a Build in Game Manager?

In Game Manager, open Multiplayer > Servers and select New Build to begin configuring a title’s server. Use the sample values to create a first test deployment.

The Windows Runner C# sample uses one server per machine and a Dasv4 VM. PowerShell and APIs offer other ways to create a build.

Enter the build and container settings

Follow these steps in order, and keep the sample’s paths and port values together as you enter them:

1. Open Multiplayer > Servers and select New Build.
2. Name the build My build, choose Dasv4, and set one server per machine.
3. Choose Windows Server Core and enter C:\Assets as the asset mount path.
4. Upload the Windows Runner C# sample assets.
5. Set the start command to C:\Assets\WindowsRunnerCSharp.exe.

The build definition also includes the container, uploaded assets, operating system, start command, and network configuration. Use the sample’s values to keep the build settings in line with its files.

Upload assets and deploy the sample

Choose East US for the sample’s regional configuration, then set one standby server and one maximum server. Add an incoming TCP port named game_port on port 3600.

Select Add build to submit the settings. Game Manager first shows a Deploying state while PlayFab prepares the build and regional capacity.

The sample build takes 10 to 20 minutes to reach Deployed. The status is a useful check that the build finished deploying, but a client test is still needed to confirm connections.

Confirm the build reaches Deployed before moving on to client connection testing.

How Should You Choose Regions and Server Counts?

Put a region near the players you need to serve, then set its server limits to match your rollout plan. Start from your player base, not from a list of available locations.

Choose regional settings using player location and measured latency. A build can use different configurations in different regions, including different standby and maximum server counts.

PlayFab Multiplayer Servers runs on most generally available Azure VM sizes and regions. That does not mean every VM size is ready for your title in every region.

Check whether the selected VM series has enough quota in the region you want. A region can offer a suitable Azure VM size yet still lack enough series-specific quota for your planned deployment.

Set the maximum server count to fit expected demand and the quota available for that VM series. A small launch test can give you better demand signals than a large limit chosen before players arrive.

Regional VM prices vary by Azure region and hardware. Compare the regions that can serve your player base, then use latency and planned capacity to make the final choice.

You can keep the initial regional footprint narrow if your launch audience is concentrated. Add regions when player locations, connection tests, or capacity needs support that change.

Check the selected VM series’ quota in every region before treating that region as launch-ready.

How Do You Size the Standby Pool?

A larger standby pool can make servers available faster, but PlayFab bills capacity while servers are propping and standing by. Size it from real startup time and the rate at which players need servers.

Propping time is the period PlayFab needs to start a game server and make it ready for allocation. Measure that interval for your own build before setting a target.

Use this formula to estimate the standby target:

Standby Target = (Propping Time + Server time to standing by) × Target Allocation Rate

The target allocation rate is the number of servers your game needs per second. The longer servers take to become ready, the more standby capacity may be needed to keep up with that rate.

For example, a Linux server that takes 100 seconds to prop, with a target allocation rate of 0.2 servers per second, needs 20 standby servers to stably support the build.

That example is not a setting to copy without testing. Time the server from start through the point when PlayFab can allocate it, then use the actual result in your calculation.

Set the standby target per build and per region. A server that starts quickly in one configuration may take longer in another, so each regional target should reflect its own measured behavior.

Servers in both propping and standing-by states are billed to the title. That makes an oversized pool a capacity choice with a direct cost, not just a technical cushion.

Recalculate the target for each build region using measured startup time and the allocation rate you need.

Which Scaling Method Fits Player Demand?

Default scaling is the simplest starting point when demand rises and falls within the limits you configured. It follows demand while staying within the regional standby and maximum server settings.

Default scaling grows and shrinks capacity with player demand, then scales down when sessions finish. It works best when your configured limits can cover the demand pattern you expect.

Use default scaling for basic demand response

With default scaling, the platform uses the configured maximum server and standby limits. It can add capacity as players need servers and reduce capacity after sessions end.

The limits still matter. If player demand reaches the maximum count, the build cannot grow beyond that configured cap even when the region has more resources available.

Choose scheduled or dynamic scaling deliberately

Scheduled scaling suits demand patterns you can plan around. Dynamic scaling suits demand that changes and needs a response beyond a simple fixed schedule.

Each scaling configuration applies to a build region. Set the approach for each region based on its expected demand rather than assuming one setting fits the whole deployment.

A sudden rush can outpace server provisioning. If players request servers faster than the platform can prepare them, the standby pool can run out and requests may fail until more servers are ready.

Use a demand test that includes a fast increase, not only steady traffic. That shows whether the standby capacity and maximum limit can handle the load at the same time.

Test the expected demand spike against both the standby target and maximum server limit before launch.

How Does a Client Request a Multiplayer Server?

Request a server from a region the player can use, and include other acceptable regions as fallback choices. More than one valid choice can help when the preferred region has no standby server.

A server request can be fulfilled within one second when a standby server is available. That timing depends on ready capacity being there when PlayFab receives the request.

Your matchmaking service or lobby logic can decide which regions are acceptable for each player or group. It then calls RequestMultiplayerServer with those region choices.

PlayFab services return connection information for the allocated server. Your matchmaking logic passes that information to the client, which typically connects directly over TCP or UDP sockets.

Use this four-step flow in your game:

1. Determine every region the player can accept.
2. Call RequestMultiplayerServer with the chosen region options.
3. Pass the returned connection details to the client.
4. Connect the client to the configured server port.

Including every acceptable region can give the request another configured location to use if the preferred region lacks a standby server. Only list regions that work for that player’s connection and game experience.

Test the allocation and handoff as one path. A successful server request does not prove the client received the right connection details or reached the listening port.

Keep the allocation request and the client’s connection handoff in the same tested matchmaking path.

How Can You Test and Troubleshoot a Deployment?

Test the server locally before treating a successful build upload as proof that clients can play. Local checks catch gaps before they become cloud deployment problems.

Use LocalMultiplayerAgent to test the setup and GSDK integration locally. Confirm that the server reaches its ready state before you move on to cloud testing.

Validate the build locally

Run the local test with the same server files, start command, and network settings you plan to deploy. Check that the server reports readiness and can complete a representative session.

A local pass does not test every regional limit, but it can expose problems with the executable, asset path, or GSDK setup. Keep the logs from a failed run so you can compare them with cloud behavior.

Check deployment and allocation failures

Use this pre-launch checklist to separate a broken build from a valid build with no ready capacity:

• Check the build status for a completed deployment.
• Confirm the start command and asset path match the uploaded files.
• Check that the incoming port and protocol match the game server.
• Confirm that the selected region has enough quota for the VM series.
• Check whether the maximum server count allows the requested capacity.
• Confirm the standby pool can meet the request when it arrives.

A failed build points to deployment or configuration trouble. A valid build can still lack available standby servers when demand rises faster than capacity becomes ready.

Re-run the allocation test from the client’s real matchmaking path after correcting any build, quota, port, or capacity issue.

What Does PlayFab Multiplayer Servers Cost in 2026?

Budget beyond compute: the 2026 allowance includes Dasv4 VM hours in two named regions and limited egress in two zones. The allowances apply separately by region and zone.

PlayFab Multiplayer Servers includes 750 Dasv4 VM hours per month in East US and another 750 in North Europe. The network allowance includes 10 GB of egress in each of Zones 1 and 2.

Additional egress costs differ by zone. Zone 1 includes US East, US East 2, US West, US West 2, US Central, US North Central, US South Central, and US West Central, along with listed European regions.

Those included VM hours apply to Dasv4 in East US and North Europe, not to every region or VM family. VM prices vary by Azure region and the hardware used.

Published VM prices increase by about 6% on November 1, 2026, for titles billed at those public prices. Prices through October 31, 2026 remain available in the VM Hourly Rates price list.

Check the billing date and region before estimating compute costs, because the public VM price changes on November 1, 2026.

Plan for network traffic as well as compute. Egress beyond the included amount is charged at the rate for the zone where that traffic applies.

Check the VM Hourly Rates for the billing date and Azure region that apply to your title.

Conclusion

A reliable first launch starts with a build that reaches ready status and a client that can connect through the configured port. Those two checks show that the server can start and the game can reach it.

Verify the GSDK-integrated build and the full client connection path before raising capacity. A server that deploys but cannot serve the client is not ready for players.

Size regional standby capacity from observed startup behavior. The time your server takes to become ready and the rate of player requests should shape the target you set for each region.

A small deployment in the intended player region gives you a useful launch test. Run the real client flow, then record whether allocation succeeds and whether the client reaches the server.

Use that result to decide what to change. A failed allocation, a slow start, or a client connection error points to a different setting, so keep the test notes specific.

Do not raise every limit at once after one test. Change the setting tied to the result, then run the same client flow again to see whether the change helped.

Run that small regional test with your real client flow, then adjust capacity from what it shows.

Conclusion

A measured first deployment gives you a stronger basis for launch capacity than an untested maximum setting. Observed demand helps you set limits that match how your game starts and serves players.

Run a small test with your intended client and matchmaking flow. Record whether allocation succeeds and whether the client reaches the game server in the region you plan to use.

Use that result to tune standby capacity before opening the game to more players. A careful test gives you a clear next move, whether you need more ready servers or a fix in the connection path.

Run the client allocation test in your target region, record the result, and adjust the standby target before opening the game to more players.