Deployment Servers and Operations

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, and the operations that act on every server in the deployment at once.

The server table

The deployment page lists every server with its ID, game, IP, player count, memory, and a live status indicator (refreshed every 10 seconds while the page is open). Click Manage on a row to open that 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, and Reinstall 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.

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.

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. Each server picks the new count up on its next restart, applied one server at a time, and the count becomes the deployment baseline.

• Restart: restart every server in sequence, so the whole deployment is never down at once. 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 page instead, which waits for each match to end before it touches the server (see Shipping an Update).

• Stop: stop every server and disable each server's auto-boot, 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.

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 page first, then resize, or contact support to raise the limit. A resize to smaller servers never hits this check.

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).