Deployment Servers and Operations
The per-server management page, and the operations that act on every server in a deployment at once: settings, resize, players, rolling restart, 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, 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.
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.
Players: set the player count on every server. Shown only when the game defines a player range. Each server picks the new count up with a rolling restart, and the count becomes the deployment baseline.
Restart: restart every server in a rolling sequence, so the whole deployment is never down at once. This is also the apply step after a Settings update.
Stop: stop every server and disable each server's auto-boot, so the servers stay offline until you run a deployment Restart.
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
Servers > Gameservers 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. Servers > Jobs shows jobs across all deployments (requires brand.jobs.view).