Running game servers

Managing services

A service is one game server on one node. This page covers its lifecycle and the controls on its page. Open a service from Services; the page has the tabs Console, Overview, Files, Configs and Settings (you see the tabs your permissions allow).

Who can create services

Creating a service needs the global permission services:create, which Admins and Resellers have. SuperAdmins and Admins can create services for any user (owner_user_id in the API) and set limits and the crash policy; others get the defaults. Users and sub-users cannot create services themselves in this version (self-service ordering comes with packages and billing).

Lifecycle actions

Action	Allowed when	What happens
Start	stopped, crashed	Starts every process of the service.
Stop	starting, running, crashed	Graceful stop: the game’s stop command (on its console or over RCON), wait up to the definition’s stop timeout (10 s if none), then terminate, then 5 s later kill everything.
Restart	starting, running, crashed, stopped	Stop, then start.
Kill	starting, running, stopping, crashed	Ends every process at once, without the graceful step.
Update	stopped, running, crashed, install_failed	Downloads the latest game files and Workshop mods. A running server is stopped first and started again afterwards.
Reinstall	stopped, running, crashed, install_failed	Deletes the install directory except the files the game definition preserves, then installs again.
Cancel install	installing	Stops a running install, reinstall or update.
Suspend / Unsuspend	any / suspended	Administrators only; see Suspending.
Delete	any but deleting	Stops the server, removes its directory, its OS account, its firewall rules and its ports. Asks you to type the service’s name.

Start, stop, restart, kill, update and cancel need the service permission control; reinstall needs reinstall. All actions need the node to be online. Every action is recorded in the audit log.

“Stop” and “kill” both set the desired state to stopped: the agent will not start the server again on its own, not even after the node reboots. “Start” and “restart” set it to running.

Update versus reinstall

Update runs the definition’s update steps (for SteamCMD games: an app update without full validation). Your files stay as they are.
Reinstall wipes the directory and installs fresh. Only the globs listed under preserve_on_reinstall in the game definition survive (for ArmA 3: server.cfg, basic.cfg, profiles/**, mpmissions/**, keys/**, userconfig/**), plus the account’s .home and .tmp folders. Use it when an install is broken. Make a backup first.

An install that fails leaves the service install_failed with the reason on the page. Fix the cause and choose reinstall (or update, if the game was installed before).

Console

The Console tab streams the game’s output live, a few tens of milliseconds behind the server. It shows the last 500 lines when you open it; the agent keeps the last 5000 lines and a rolling log file.

Type a command and press Enter to send it to the game’s console (its standard input). This needs the service permission console and is recorded in the audit log.
The view follows new lines; scroll up to pause and use Jump to live to return. Filter by source (the main process, headless clients, tailed log files, the agent’s own notes).
Lines from the agent itself (install steps, “stopping (up to 15s)”, scheduled-task results) are marked as such.
Some games write their console to a log file instead of standard output (ArmA 3 on Windows). The definition then tails the log file, and the console shows those lines.
During an install, the console accepts the Steam Guard code SteamCMD asks for.

For games with a remote console (RCON), there is also an RCON console; see RCON and player counts.

Overview

The Overview tab shows where players connect, the ports, the processes with their PIDs, CPU and memory now and over the last hours (up to 24 hours of samples), and the SFTP details.

Crash policy

When a server exits on its own, the agent applies the service’s crash policy:

Setting	Default	Meaning
Restart	Restart after a crash (`on_failure`)	`on_failure`: restart unless the exit was clean. `always`: also after a clean exit. `never`: leave it stopped.
Restarts allowed	5	How many restarts within the window.
Within	5 minutes	The window. After the limit the service stays crashed until someone starts it.
Wait between restarts	Grows each time, from 2 s	Exponential back-off (2 s, 4 s, 8 s … up to 5 minutes) or a fixed delay.

Headless clients marked restart_with_main in the definition restart together with the main server. A crash can send a service.crashed notification.

The crash policy and the CPU / memory limits are set by an administrator when the service is created; they cannot be changed afterwards in this version.

Limits

Limit	Windows	Linux
CPU (% of one core; 100 = one core, 0 = unlimited)	Job Object hard CPU-rate cap	cgroup `cpu.max`
Memory (0 = unlimited)	Job Object limit: allocations beyond it fail	cgroup `memory.max`: the kernel stops processes in this service’s group only
Disk quota	Checked on every write through the panel and SFTP; files the game writes itself are counted at the next scan (every 5 minutes)	the same

Set the disk quota and extra file deny rules in the service’s Settings tab (administrators). See Files and SFTP.

Settings tab

Field	Who	Notes
Name	`settings` permission	1-64 characters.
Player slots	`settings`	Within the game’s minimum and maximum. Config settings bound to the slot count follow it.
Variables	`config` permission	Only variables the definition marks `user_editable`; administrators can change all. Passwords are write-only: you can set a new one, never read it. Clearing a generated password creates a new one.
Workshop mods	`config` (or `mods` through the mod manager)	Changing mods marks the service “mods changed”; run Update to download them.
Steam account	administrators	Which vault account SteamCMD uses; default account if none.
File deny rules, disk quota	administrators	See Files and SFTP.

Changes to variables, slots and mods are applied before the next start. Most games read them at start, so restart the server.

Suspending a service

Suspending blocks a service without deleting it, for example for an unpaid invoice. A suspended service is stopped at once (its processes are killed) and cannot be started. Its owner and sub-users can still see it, but cannot do anything else with it. Suspend and unsuspend need an administrator, a reseller (for their own customers’ services) or the billing permission. Unsuspending leaves the service stopped.

Deleting a service

Delete removes the game files, the OS account, the firewall rules and the port allocations. Backups already stored on a backup target are not removed by deleting the service; delete them from the service’s backups first if you want them gone.

If the node is offline, the service shows deleting and is removed when the node returns. A force-delete for nodes that never come back is not available yet.

Who can delete: administrators, resellers for their customers’ services, and owners who hold services:create.

Changes while the node is offline

Starting, stopping and other actions are refused while the node is offline (“the service’s node is offline”). The game server itself keeps its last state: a running server keeps running, scheduled tasks keep firing, and the panel catches up when the node reconnects.