Fleets Overview

Connect your deployments to Discovery: fleet structure, scaling policy, the listing-only setup, and the optional autoscaling and matchmaking layers.

A fleet connects your deployments to Discovery. It is a named group of deployments (typically one per location) for a single game, linked to a Discovery app: every game server in the fleet connects to the Discovery service automatically and shows up in the app's live state and public server list, with no heartbeat code on your side. On top of that link sit two optional layers for session-based games: an autoscaler that keeps each location sized to demand, and matchmaking through allocations and tickets (see Matchmaking Integration).

In the sidebar, open Hosting > Fleets. Viewing requires the fleets.view permission; creating, editing, and deleting require fleets.manage. A control you lack the permission for is shown disabled; hover it to see which permission it needs.

Structure

Fleet  ->  Member Deployments (typically one per location)  ->  Game Servers

  • Fleet: the group itself. A name, a game, a status (Active or Paused), and a linked Discovery app. Every member deployment must run the fleet's game.

  • Member deployment: a deployment attached to the fleet, carrying its own scaling policy. One member deployment per location is the recommended layout, not an enforced rule; the autoscaler treats each member deployment independently.

  • Discovery app: the Discovery service link. See Discovery Overview. Fleet servers connect to it automatically and appear on its public server list; you write no heartbeat code for fleet servers. Matchmakers holding an allocate-scope token can also allocate them.

The fleet page shows how these connect in a strip under Game, member deployments and Discovery app: the game, the fleet, its member deployments and the Discovery app, each linking to its page. A name you do not have the brand permission to open shows as plain text; hover it to see which permission opening it needs. The same strip appears on each member deployment's page, and each member deployment row on the fleet's Locations tab links to that deployment. A game's own overview has a Where this game runs card that lists each of its fleets with their member deployments, game server counts and Discovery app.

Using a fleet as a server browser

You do not need matchmaking to use a fleet. To give players a live server browser for servers you host on PingCore:

  1. Create a fleet and deploy into it.

  2. Set Min and Max to the same number on each member deployment. The autoscaler then holds each location at exactly that size, healing it back if the server count ever drifts above or below.

  3. Point your game client at the linked Discovery app's public server list. See The Public Server List.

That is the whole setup: no matchmaking calls, no SDK integration, no heartbeat code. Live player counts also work without game changes through the agent's RCON occupancy poll, provided your game exposes RCON and the occupancy command is configured under RCON occupancy in the Agent Settings card on the fleet's Settings tab (or through the API or MCP).

RCON polling is the zero-integration fallback tier and covers occupancy display only. When your game integrates directly, the Agones-compatible SDK is the primary integration (games already written for Agones work unmodified), and the native session endpoints are the lightweight alternative; allocation-driven matchmaking needs at least those session calls. Making Your Game Fleet-Ready describes all three tiers.

Creating a fleet

  1. On the Fleets page, click Add Fleet.

  2. Enter a Fleet Name and pick the Game.

  3. Pick the Discovery app: Create a new Discovery app, or an app you already have that uses Private registration. When your workspace cannot create another Discovery app, the form picks an existing private app, preferring one no other fleet uses.

  4. Click Create.

You can also start from a game: in the Where this game runs card on the game's overview, New fleet (or Create a fleet (recommended) while the game runs nowhere yet) opens this form with the game selected.

With Create a new Discovery app, an app named after the fleet (plus one agent token) is created, so fleet servers can connect as soon as they boot. To reuse an app you already have, pick it in the Discovery app field. An app another fleet already uses is labelled with that fleet's name, for example "(used by EU Pool)". Both fleets then list their game servers on the same app, in one server list, so prefer an app no fleet uses. The app must use Private registration: an app with open registration refuses every hosted game server's connection, so the form lists open apps but you cannot pick them. Through the platform API, pass discoveryAppId to link an existing private app.

Your workspace may have a limit on how many fleets and Discovery apps it holds. The Fleets and Discovery pages show it. Contact support to raise it.

Adding member deployments

On the fleet's Locations tab there are two ways to add one, both at the top of the tab:

  • Deploy New: opens the deploy form with the fleet preselected. The deployment is attached to the fleet before provisioning is queued, so its servers carry the fleet agent configuration from their very first boot. This path requires the brand.servers.deploy permission on top of fleets.manage.

  • Attach Deployment: attaches an existing deployment. It must belong to your organization, run the same game as the fleet, and not already belong to another fleet (detach it first; a deployment belongs to at most one fleet). The picker lists deployments in another fleet as unavailable, with the name of that fleet. Game servers already running in the deployment join the fleet automatically within a few minutes, when their containers next refresh their configuration; no restarts are needed. Servers added through Deploy New connect from first boot.

Either way the new member starts with Min 0 and Ready Buffer 0. With Deploy New, Max starts at 10, which always covers the Server Count because a deploy adds at most 10 game servers. With Attach Deployment, Max starts at the larger of 10 and the deployment's current game server count. Max is then lowered to what your workspace's resource limits can hold beside its other fleet deployments, and the success message names the value when it is. A deploy is refused with a 400 when the room is smaller than the Server Count (see Creating and Scaling Deployments), and an attach when not even one game server fits. Tune the policy per location afterwards.

Through the platform API (POST /api/fleets/{fleetId}/deployments) you can send minServers, maxServers and bufferFloor with the attach. An omitted maxServers gets the default above, raised to cover the minServers and bufferFloor you sent. An explicit maxServers that does not fit your limits is refused with a 400 rather than lowered.

Scaling policy

Each member deployment has three numbers. To edit them, open the location's row on the fleet's Locations tab and click Policy on the deployment:

  • Min (minServers): the floor. The autoscaler never scales the location below this many game servers. Defaults to 0.

  • Max (maxServers): the hard ceiling the autoscaler never exceeds. Must be at least 1 and at least minServers.

  • Ready Buffer (bufferFloor): the number of idle, ready game servers kept warm so matches start instantly. As matches consume them, the autoscaler tops the buffer back up (within Max). Cannot exceed Max.

Invalid combinations (negative values, minServers above maxServers, bufferFloor above maxServers) are rejected with a 400.

A policy must also fit your workspace's resource limits (memory, CPU and game server count). The room a deployment's Max has to fit in is your limits, minus everything the workspace already runs, minus the game servers every other fleet deployment may still add before it reaches its own Max. The autoscaler may grow each of them that far, so their maximums count even while they run fewer. Raising Max, Min or Ready Buffer is checked; lowering any of them never is, so a workspace already over a limit can always scale its policy down. A policy that does not fit is refused with a 400 whose message names the limit, and whose data carries:

  • reason: brand_memory_limit, brand_cpu_limit or brand_server_limit.

  • maxServersAllowed: the highest Max that fits today.

Lower Max to that value, lower another fleet deployment's Max, or contact support to raise the limit.

A 503 with the message Another fleet change for this brand is still being applied. Try again in a few seconds. means another attach, deploy or policy change in your workspace is being checked at the same moment. Nothing was changed; retry after a few seconds.

Setting Min equal to Max holds the location at a fixed size: scale-up is capped at Max and scale-down never goes below Min, so the autoscaler keeps the location at exactly that size (healing it back if the count drifts). Use this when you want the Discovery listing without autoscaling.

How the autoscaler decides

The autoscaler reconciles every member deployment once per minute:

  1. It reads the live fleet state from Discovery: how many of the deployment's servers are currently ready (idle and allocatable).

  2. The ready target is the larger of the deployment's Ready Buffer and its share of the matchmaker's demand hint (an app-wide desired-capacity hint is split evenly across member deployments, rounded up).

  3. Too few ready servers: it scales up to cover the shortfall, never above Max.

  4. More ready servers than the target: it scales down the idle excess, never below Min.

Three situations change that loop. Each one shows on the member deployment's row on the fleet's Locations tab, and a blocked scale-up or missing game servers also appear under Needs attention on the Overview tab:

  • Game servers missing from Discovery. While at least half of a deployment's live game servers are missing from Discovery, the autoscaler holds scale-up (it still scales back up to Min), and the row shows an alert such as 3 of 4 live game servers are absent from Discovery, with the likely causes. The hold lifts by itself once the game servers report again.

  • A game server that refuses connections. A missing game server that is past its boot time and whose container actively refuses connections is treated as dead. It does not count toward the hold, and the autoscaler replaces it, with a limit on how many it replaces per hour.

  • A scale-up blocked by a resource limit. When adding game servers fails because a workspace limit is reached, the row shows the reason, for example Scale-up blocked by brand memory limit (30 / 32 GB used). The autoscaler does not retry for about 10 minutes, then tries again, so a raised limit is picked up on its own. Lower Max or contact support to raise the limit.

The autoscaler guarantees three things:

  • Scale-down only ever removes ready (idle) servers, and readiness is re-verified against live Discovery state at removal time. Shrinking a fleet never interrupts a live match.

  • A fleet location never drains to zero. Even with Min 0, the removal floor is one server. Emptying a location only happens through deployment removal, which is a deliberate operator action. Set Min 0 to let a quiet location idle at a single warm server.

  • Per-cycle actions are capped at 10 servers per location, so a bad demand hint cannot remove or create large numbers of servers at once. Sustained demand is still met over successive one-minute cycles.

Pause, resume, detach, delete

  • Pause (the Pause button at the top of the fleet page, or on its Settings tab): removes the fleet configuration from container bootstraps. Each container stops its agent on its next configuration refresh (within about five minutes), the same poll that delivers the change. Pause propagates within a few minutes rather than instantly, and allocations can still land in that window, so it is too slow to serve as an incident kill switch. The servers themselves keep running.

  • Resume puts the fleet configuration back. Game servers rejoin automatically within a few minutes, when their containers next refresh their configuration; no restarts are needed.

  • Detach a member deployment: the deployment and its game servers are untouched; they stop being fleet members (agents disconnect on their next configuration refresh, within about five minutes).

  • Delete the fleet: member deployments and their game servers are untouched, and the linked Discovery app is kept.

  • The dependency only runs one way: a Discovery app cannot be deleted while a fleet links to it (the delete is refused, naming the fleet). Delete the fleet first.

  • A game cannot be deleted while a fleet runs it or while any of its deployments still exists. The delete is refused with a message naming how many fleets and deployments use the game. Delete those fleets and remove those deployments first (see Game Overview).

Next steps