PlayFab Multiplayer Servers 2.0 (Thunderhead)

The PlayFab Multiplayer Server hosting service allows you to operate a dynamically scaling pool of custom game servers in Azure.

This service is currently available as a private preview to a limited set of customers.

If you are an existing PlayFab Pro or Enterprise customer, and interested in early access to this feature set, please reach out to us through our community Slack channel, your Account Manager or email us at

There are three key concepts to PlayFab Multiplayer Servers:

  1. Game Server executable - The application that you are running in Azure. This server may be a simple network repeater, a fully authoritative game server running physics and AI, or anything in between.
  2. Build - The game server executable, packaged with assets and certificates needed to run the game. This content can be uploaded as individual certificates, zip files, and/or a container image. If you do not need a custom container image, you can use our managed Windows containers.
  3. Game Server - A container running your Game Server Executable. There may be multiple servers running on a single virtual machine.

Using PlayFab REST APIs, your matchmaking or lobby services allocates session hosts in your preferred Azure region. Game clients can then connect players to the newly created server for play. As your player base ebbs and flows globally, your build scales to meet the demand.

You can upload and manage multiplayer server builds using Game Manager or the Entity API.

Getting started documentation

SDKs and Tools

August 26, 2018 - Private preview release notes


Get-PFMultiplayerBuild now uses the ListBuilds API to return a list of build summaries. This makes the cmdlet faster, but returns less information by default. Detailed information is still available via Get-PFMultiplayerBuild.

Simply use the new -Default parameter, as seen below.

Get-PFMultiplayerBuild -Detailed

Get-PFMultiplayerBuild "my build name" -Detailed

This will use the GetBuilds API to obtain the detailed configuration for your builds.

API changes


  • ListBuilds have been renamed to ListBuildSummaries.

Property name changes


  • StartGameCommand -> renamed StartMultiplayerServerCommand
  • RegionConfiguration is now RegionConfigurations (plural) for consistency throughout APIs request/responses.


  • Response now contains both ContainerRunCommand and StartMultiplayerServerCommand.
    • StartMultiplayerServerCommand is for Managed builds.
    • ContainerRunCommand is for Custom builds.
    • GetBuildResponse will return both, but will return null appropriately (i.e. StartMultiplayerCommand will be null for Custom Builds, and ContainerRunCommand will be null for Managed Builds).

Response changes


Has been separated and renamed to:

  • CreateBuildWithManagedContainerResponse
  • CreateBuildWithCustomContainerResponse

This separation was necessary to conform to our other APIs - as well as to ensure that we differentiate between both and are able to filter/add extra information for the different flavors of Builds.


This has been eliminated from:

  • GetBuild
  • CreateBuildWithManagedContainerResponse
  • CreatedBuildWithCustomContainerResponse

All information will be at the top level response objects:

  • CreateBuildWithManagedContainerResponse
  • CreateBuildWithCustomContainerResponse
  • GetBuildResponse

Additionally, BuildSummary has been changed, and is only used in ListBuildSummaries and will output as a list of IDs and names.

The usage has changed, so that developers will have to call GetBuild passing in a BuildId to get extra information. This optimization is required on our end.

Enum changes

ContainerFlavor has had these two enum values:

  • ManagedWindowsServerCore
  • CustomLinux

Known Issues and limitations

  • Custom containers are not enabled in Game Manager (this is coming in an update soon).
  • Deleting builds through the Entity API always returns a 400 (Error), but this usually means that the build will be deleted over the next 5-10 minutes.