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 Specs tab under Games > 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 Hosting > Deployments and click Deploy Game Servers (requires brand.servers.deploy). You can also open the form from a game's overview with Deploy Game Servers in Quick Actions, which preselects the game. 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 the deploy button to submit. It names the Server Count, for example Deploy 3 Servers.

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.

The new member starts with a Max (maxServers) of 10. A deploy adds at most 10 game servers, so that always covers the Server Count. The deploy is then checked against your workspace's resource limits in two steps:

  • The Server Count itself. As for any deploy, the game servers you ask for must fit beside everything the workspace already runs. If they do not, the deploy is refused with HTTP 400, a message naming the limit, and empty data. Nothing is created.

  • The fleet Max. The new member's Max must also fit beside the game servers your other fleet deployments may still add before they reach their own Max. When 10 does not fit, Max is lowered to the highest value that does, and the success message says so ("Its fleet maxServers was set to N, the highest that fits the brand's resource limits today."). Check the new member's policy on the fleet page. When the other fleet deployments leave less room than the Server Count, the deploy is refused with HTTP 400 and nothing is created. In this case data carries reason (brand_memory_limit, brand_cpu_limit or brand_server_limit) and maxServersAllowed.

For either refusal, deploy fewer servers or contact support to raise the limit. For the second one, lowering another fleet deployment's Max also frees room.

HTTP 503 with "Another fleet change for this brand is still being applied" means another fleet change in your workspace is being checked at the same moment. Nothing was created. Try again after a few seconds.

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.