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, click 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.

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 in the fleet's agent configuration (set via the API or MCP today).

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.

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.

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). 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 the default policy: Min 0, Max 10, Ready Buffer 0. Tune it per location afterwards.

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.

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.

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.

Next steps