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.

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 page 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 page (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. 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.

A Discovery app named after the fleet (plus one agent token) is created automatically, so fleet servers can connect as soon as they boot. If you already run a Discovery app you want to reuse, create the fleet through the platform API instead and pass discoveryAppId. The app must use Private registration: an app with open registration refuses every hosted game server's connection, so the create is refused with a 400 telling you to pick a private app or leave discoveryAppId out.

Adding member deployments

From the fleet page, under Member Deployments, there are two ways to add one:

  • 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, edited inline on the fleet page:

  • 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, and each one shows on the member deployment's row on the fleet page:

  • 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 (fleet page, Pause button): removes the fleet configuration from container bootstraps. Each container stops its agent on its next bootstrap refresh (every 5 minutes by default), 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 bootstrap refresh).

  • 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