Deployment Servers and Operations

The per-server management page, changing one server's memory or deleting it, and the operations that act on every server in a deployment at once: settings, resize, players, restart every server in sequence, and stop.

Every server in a deployment is a complete game server with its own address, files, and management page. This page covers what each server gives you, how to change one server's memory or delete it, and the operations that act on every server in the deployment at once.

The game server table

The Game Servers table on the deployment page shows 50 game servers per page. Use Previous and Next under the table to move between pages. The columns are:

  • Game Server ID and Game.

  • IP: the game server's address, or Pending until it is provisioned.

  • Player slots (per game server): the player count each game server is configured for, not the number of players currently connected.

  • Memory.

  • Build: the build version the game server reports, and how long ago it reported it.

  • Status: the live status, refreshed every 10 seconds for the game servers on the page you are viewing while the page is open.

A game server whose supervisor does not answer can read Unknown for up to a minute before its status is filled in. Click Manage on a row to open that game server's management page.

The per-server management page

Each server's page carries the full management surface:

  • Basic Settings and Config Manager: the server's editable settings and its config files.

  • Console: the live server console, with command input.

  • File Manager: browse, upload, and edit the server's files in the browser.

  • Task Manager: scheduled reboots or shutdowns, daily or weekly at a fixed hour.

  • Logs: the server's log files.

  • FTP Details: SFTP connection details for direct file transfer.

  • Mods: mod browsing and install, when the game has a mod provider configured.

File Manager, FTP Details, and Mods appear only when the game's configuration enables them. The actions menu on the server page offers Restart, Shutdown, Reinstall Server, and Delete Server for that single server.

Connection details (IP, game ports, and the SFTP host, port, and username) are also returned by the deployment API endpoints, so external tooling does not need to open each server's page.

Restart and Shutdown on a busy server

A server runs one lifecycle operation at a time. If you press Restart or Shutdown while another operation holds the server (for example a reinstall, or Shutdown during a restart), the server refuses and nothing changes. Pressing Restart while the server is already restarting is accepted. The panel shows Not restarted or Not stopped with the reason. Wait for the other operation to finish, then try again.

Over the API, POST /api/gameservers/{id}/actions/restart and POST /api/gameservers/{id}/actions/stop answer HTTP 409 in this case, and the message ends with "Wait for it to finish, then try again." The response data carries supervisorStatus and conflictingOperation (the operation that holds the server); either can be null when the server did not name it. Retry after that operation completes.

A 409 with empty data on a restart means the cluster is busy with another operation on the server, such as a migration. Wait for it to finish, then try again.

Auto-boot keeps the game running. While it is on, the game starts whenever the server's container starts, and is started again whenever it is found not running (checked about every 2 minutes, so also after a crash). While it is off, the game is not started on its own. A restart asks the server to start the game, but a restart that has to recreate the server's container starts the game only if auto-boot is on, so check the server's status after it. Turn it on or off with Auto Boot under Server Features on the server's My Server page, or with POST /api/gameservers/{id}/actions/features, which returns the resulting autoBoot, autoUpdate and updateOnBoot flags.

Shutdown turns the server's auto-boot off only once the server has accepted the stop, or reports that the game is not running. A refused or unanswered stop leaves auto-boot as it was, so a server that is still running keeps its normal restart behaviour. If a stop times out, check the server's status and press Shutdown again.

Changing one server's memory

Change Memory, next to Memory Usage on the server's My Server page, changes the memory of that one server. The change is applied live without downtime. It runs the same checks as a deployment Resize, in this order:

  • Deployment status. The deployment must be active. While it is busy with another operation, or is not active, the change is refused with HTTP 409.

  • Game maximum. The size must be between the game's minimum and maximum. The options on the page stop at the game maximum. A server that is already above it shows its current size with a note, and you can choose a size up to the maximum.

  • Prepaid credit. With an empty balance the change is refused with HTTP 402 (error code INSUFFICIENT_CREDIT), even when it makes the server smaller.

  • Resource limits. A change that makes the server bigger must fit your workspace's resource limits, or it is refused with HTTP 400 and the message names the limit. A change that makes the server smaller, or keeps its size, is never refused for resource limits, even while your workspace is over one.

  • Fleet capacity. On a fleet member, a bigger server must still let the deployment reach its fleet Max. This is the same check as resizing a fleet member (below), with the same 400 and data.

The new size applies to this server only. It lasts until a deployment Resize sets the size of every server, or until the server is replaced. Servers added later, by scaling up or by fleet replacement, get the deployment's size.

Over the API, GET /api/gameservers/{id}/resources returns the options, including baselineMemoryMb (the size new servers in the deployment get), and POST /api/gameservers/{id}/actions/resources applies a memoryMb from them. Both require brand.servers.manage. The options do not account for credit, resource limits or fleet capacity; the apply step checks those.

Deleting one server

Delete Server in the server page's actions menu permanently deletes the server and its files. You confirm by typing "delete my server". This cannot be undone.

  • The deployment shrinks by one server. A deployment that is not in a fleet is not refilled.

  • In a fleet, the autoscaler starts a new server only if the deployment is then below its Min or its Ready Buffer. A replacement is a different server with a new ID, a new address, and an empty disk.

  • Deleting the only server leaves the deployment active with no servers. Scaling down never goes that far, so scale the deployment up again or remove it.

  • Session logs are not archived. Scaling down a fleet deployment archives them before it removes servers, so use scaling down to remove servers whose logs you want to keep.

  • The server can stay listed in Discovery for up to 90 seconds after the delete.

Use Delete Server to discard one broken or stale server. Over the API it is DELETE /api/gameservers/{id} (requires brand.servers.manage), which answers HTTP 409 while the server is migrating or waking.

Deployment-wide operations

The deployment page header carries a toolbar of operations that act on every server at once. All of them require brand.servers.manage and are enabled only while the deployment is active. Each queues a job and parks the deployment in a transient status until it finishes; see the lifecycle in Deployments Overview.

  • Settings: one form for the config variables shared by every server in the deployment. Each field shows the current value when all servers agree, and warns when servers have diverged. Saving writes the values to every server; they take effect on each server's next restart, so follow up with Restart to roll them out.

  • Resize: change the memory allocation of every server. Memory is applied as a live update without downtime, and CPU follows the game's configured scaling curve. The new size becomes the deployment baseline, so future scale-ups inherit it. A fleet member has an extra check, below.

  • Players: set the player count on every server. Shown only when the game defines a player range. Running servers restart with the new count one at a time, 5 seconds apart, and the count becomes the deployment baseline, so servers added later get it too.

  • Restart: restart every server in sequence, one every 5 seconds. The job does not wait for a server to come back up before it restarts the next one, so with a game that takes longer than that to start, several servers can be down at the same time. It also asks servers that a Stop left stopped to start their game; a server whose container has to be recreated starts its game only if auto-boot is on, so check the Status column afterwards. This is also the apply step after a Settings update. It is not session aware: a server running a match is restarted along with the rest. If the deployment is a fleet member, use a release on the fleet's Releases tab instead, which waits for each match to end before it touches the server (see Shipping an Update).

  • Stop: stop every server and turn each server's auto-boot off, so the servers stay offline until you run a deployment Restart. As with a single server, auto-boot is turned off only on servers that accepted the stop. After a deployment Restart, check that the servers are running, and turn Auto Boot back on where it is off. While stopped, the deployment serves no players, and a fleet it belongs to loses that capacity.

When a job completes. A Restart, Stop or Players job sends the action to each server and does not wait for it to take effect. The job completes once every server has been sent the action, and the deployment's lock is released then, so the next operation can start while servers are still restarting or shutting down. Before the next step, check the Status column, or each server's status with GET /api/gameservers/{id}/context/status, or all of them with GET /api/brand/servers/deployments/{id}?includeStatus=true.

Restart and Stop handle each server on its own. A server that is busy with another operation refuses, and the job logs that server as failed and moves on to the next one. Job History shows each failed server and its error, and the job itself fails only when every server failed. Run the operation again once the busy servers are free.

Resizing a fleet member. A resize to bigger servers must still let the deployment reach its fleet Max (maxServers) inside your workspace's resource limits, beside your current usage and the maximums of your other fleet deployments. If it would not, the resize is refused with HTTP 400 and nothing changes.

The response data carries reason (brand_memory_limit, brand_cpu_limit or brand_server_limit) and maxServersAllowed, the highest Max that fits at the new size. Lower the deployment's Max on the fleet's Locations tab first, then resize, or contact support to raise the limit. A resize to smaller servers never hits this check.

One operation at a time. Settings, Resize, Players, Restart, Stop and fleet releases share one lock per deployment. While one runs, starting another is refused with HTTP 409; wait for its job to finish, then try again. A fleet release that reaches a busy deployment waits for it and shows the wait in its progress.

Over the API, each operation is under /api/brand/servers/deployments/{id}: POST actions/restart, POST actions/stop, POST actions/players with players, and POST settings/bulk-update with updates (a list of {variable, userValue}). All four require brand.servers.manage. GET settings/catalog lists the shared variables with their current values and a bulkEditable flag (requires brand.servers.view); the bulk update accepts only the variables flagged bulkEditable. It can also take targetServerIds to write a few servers first; restart those servers, not the deployment, to apply the values (the response message says which to restart). MAXPLAYERS is refused there: change it with POST actions/players. An unknown, non-editable or invalid variable, or a server outside the deployment, refuses the whole request with HTTP 400 and nothing is written. Each operation returns a jobId, and GET jobs/{jobId} follows that job (requires brand.servers.view).

Job types, for reading Job History or the jobs API: brand.bulk_update (settings), brand.resize, brand.update_players, brand.restart, and brand.stop.

All servers in one place

Hosting > Game Servers lists every game server in your organization in a single table, both deployment servers and servers rented by your customers (requires brand.servers.view). Use it to find a server without knowing which deployment it belongs to. Hosting > Jobs shows jobs across all deployments (requires brand.jobs.view).