Deployments Overview

What a deployment is, how it relates to game servers and fleets, its status lifecycle, and the permissions that gate it.

A deployment is a pool of identical game servers: one game, one location, one shared configuration, and a server count you control. It is the unit you create, scale, and operate when hosting game servers on PingCore. Fleets, autoscaling, and Discovery listing are all built on top of deployments.

In the sidebar, open Servers > Deployments. Viewing requires the brand.servers.view permission.

Structure

Deployment  ->  Game Servers (identical instances)

  • Deployment: the game, a deployment spec, a location, a resource allocation (memory, CPU, players), and an optional friendly name. The resource allocation is the baseline every server gets, including servers added later by scaling.

  • Game server: one running instance. Each has its own address and ports, its own files, and its own management page with a console, file manager, and logs. See Deployment Servers and Operations.

  • Deployment spec: the server template behind the deployment. It defines the container image and server configuration, and is created per game on the game's Deployment tab under My Games. A game needs at least one deployment spec before it can be deployed.

Deployments and fleets

A deployment lives in exactly one location. A fleet groups deployments (typically one per location) for a single game and links them to Discovery, so their servers appear on a live player-facing server list, with optional autoscaling and matchmaking on top.

The fleet layer is optional:

  • Deployments alone are enough for persistent, always-on servers: a survival world, a community server, a fixed set of instances players join directly. You set the server count and change it by scaling.

  • Add a fleet when you want the servers on a Discovery server list, sized automatically per location, or allocated by a matchmaker.

A deployment belongs to at most one fleet. Membership shows on the deployment page as a fleet link under the header; it is managed from the fleet page, never from the deployment itself.

Status lifecycle

A deployment always has one status, shown as a badge on the list and detail pages:

  • pending and deploying: created, servers are being provisioned.

  • active: the normal state. All operations are available.

  • scaling: servers are being added or removed.

  • updating: a deployment-wide operation (restart, stop, resize, settings, players) is running.

  • failed: provisioning or removal failed. Removal can be retried from here.

  • removing and removed: removal in progress, then done.

Only one operation runs at a time. While the status is transient (deploying, scaling, updating, removing), further operations are refused with HTTP 409 until the running job completes and the status returns to active.

Every operation is an asynchronous job. The Job History panel on the deployment page shows each job with its progress and per-step logs.

Billing

Deployment servers draw from your prepaid credit based on their memory and CPU allocation; player count is not billed. Creating or scaling a deployment with an empty balance is refused with HTTP 402 (error code INSUFFICIENT_CREDIT), and the workspace points you to the top-up page instead.

Permissions

  • brand.servers.view: view deployments, their servers, live status, and job history.

  • brand.servers.deploy: create deployments and scale them.

  • brand.servers.manage: rename deployments and run deployment-wide operations.

  • brand.servers.remove: remove a deployment and all its servers.

Next steps