Creating and Scaling Deployments

Deploy servers from the workspace or API, deploy directly into a fleet, scale up and down, rename, and remove.

Before you deploy

  • The game needs at least one deployment spec. Create one on the game's Deployment tab under My Games; the deploy form links there with a Create one button when none exists.

  • On prepaid billing you need a positive credit balance. With no credit the form shows Credit Required with a Top Up Now link, and the API refuses with HTTP 402 (error code INSUFFICIENT_CREDIT).

The deploy form

Go to Servers > Deployments and click Deploy Servers (requires brand.servers.deploy). The form walks through:

  1. Game: one of your games.

  2. Deployment Spec: the server template to run.

  3. Location: the data center to deploy into.

  4. Resources: Memory, CPU, and Players sliders, bounded by the game's configured ranges (a value with no range shows as fixed). These become the baseline for every server in the deployment, including servers added later by scaling.

  5. Server Count: 1 to 10 servers, plus an optional Friendly Name.

A summary card shows the full selection. Click Deploy N Servers to submit.

The deployment is created immediately and a brand.deploy job provisions the servers one at a time. Each server shows Pending in the server table until it is provisioned; progress and logs appear under Job History on the deployment page.

Over the API: POST /api/brand/servers/deployments with gameId, deploymentSpecId, locationId, count, and optionally memoryMb, cpuMillicores, players, friendlyName, and fleetId. Omitted resources default from the game's configuration.

Deploying into a fleet

To make the new deployment a fleet member from its first boot:

  • From the fleet page, click Deploy New. The deploy form opens with a banner naming the fleet and the Game selection locked to the fleet's game. On success you land back on the fleet page.

  • Over the API, pass fleetId on the create call.

Both paths require the fleets.manage permission on top of brand.servers.deploy, and the fleet must run the same game as the deployment. The attach happens before provisioning is queued, so every server carries the fleet agent configuration from its very first boot. A deployment attached to a fleet later joins automatically within a few minutes, as each server picks up the fleet configuration on its next refresh. See Fleets Overview.

Scaling up

On the deployment page, click Scale (requires brand.servers.deploy; the deployment must be active). Enter how many servers to add (1 to 10). A brand.scale job provisions them with the deployment's baseline resources, and the deployment sits in scaling until it finishes.

Resource limits and prepaid credit are checked again on every scale-up, with the same checks as on create.

Over the API: POST /api/brand/servers/deployments/{id}/scale with addCount.

Scaling down

The workspace has no scale-down button. Remove servers over the API with the same scale endpoint, or let a fleet's autoscaler do it:

POST /api/brand/servers/deployments/{id}/scale with one of:

  • removeCount: remove that many servers, newest first.

  • serverIds: remove exactly these game servers.

A scale-down removes at most 10 servers per call, cannot be combined with addCount, and always leaves at least one server in the deployment. Removing the last server is deployment removal, which is its own endpoint (below). Inside a fleet, the autoscaler drives this same path and only removes idle servers; see Fleets Overview.

Renaming

On the list page, the pencil button (requires brand.servers.manage) sets a new friendly name. Over the API: PATCH /api/brand/servers/deployments/{id} with friendlyName.

Removing a deployment

Click Remove on the deployment page (requires brand.servers.remove; allowed while the deployment is active or failed). Removal queues a brand.remove job that deletes every server and then marks the deployment removed. This cannot be undone.

Following the work

Every create, scale, and remove is a job. The Job History panel on the deployment page lists each job with its type, progress (for example 2/3 servers provisioned), per-step logs, and any error. The page refreshes itself every 10 seconds while open. During a job, the deployment's transient status (deploying, scaling, removing) blocks other operations with HTTP 409; see the lifecycle in Deployments Overview.