Running game servers

Config editors

Game definitions can describe a game’s config files and the settings in them. The service’s Configs tab turns each of those files into a form. Saving the form changes only the values you edited in the real file: comments, order, spacing and line endings stay as they were.

The Configs tab needs the service permission config.

Using the forms

Open the service and choose Configs. Each config file is a card (for ArmA 3: Server, Network (basic.cfg) and BattlEye RCon; for Minecraft: Server).
Change values. Field types follow the definition: text, numbers with limits, switches, drop-down lists, sliders, multi-line lists (one entry per line) and passwords.
Choose the card’s save button (Save Server, for example). Values that are invalid are marked on the field.
Restart the server if the game reads the file only at start (most do).

Hints under a field tell you more:

Not in the file yet: the default (…) is shown. The setting is missing from the file; saving adds it (in the right INI section, ArmA class or JSON object).
Only an administrator can change it. The definition marks it user_editable: false.
Password fields are write-only: Leave empty to keep it; type a new one to change it.

The forms refuse values that would change the structure of the file (for example a line break, a ; inside an ArmA value, or $ in an env file) instead of trying to escape them.

Bound settings

Some settings are bound to the panel: their value comes from a variable, the slot count or a port. The panel is the source of truth for them.

A setting bound to exactly one variable or to the slot count edits that variable or the slot count. The hint says Follows …: changing it here changes that too. Example: ArmA 3’s maxPlayers follows the service’s player slots, so changing it in the form changes the slot count, and the server browser shows the same maximum.
A setting bound to anything else, for example a port, is read-only: Follows …; it cannot be changed here. Ports in config files therefore always match the ports the service received.
The agent writes every bound value into the file before every start, after installs and right after you change the variable or slot count. A hand edit of a bound value in the file is undone at the next start. Until then the form shows: The file says something else right now; the panel value is written at the next start.

Bound settings are how passwords stay consistent: ArmA 3’s join password is used both in server.cfg and on the headless clients’ command line, and the BattlEye RCon password and port follow the panel even though BattlEye renames its config file at every start.

Supported formats

Format	Used for	Notes
`ini`	Classic INI files with sections	Missing keys are added to their section.
`keyvalue`, `properties`	`key=value` files (Minecraft `server.properties`)
`keyvalue_space`	`Key value` files (BattlEye `BEServer_x64.cfg`)
`env`	`.env` files	`$` is refused in values.
`json`	JSON	Missing keys are added to their object.
`yaml`	YAML	Comments are kept; indentation is normalised.
`xml`	XML
`arma_cfg`	ArmA `.cfg` (`key = value;`, arrays `key[] = {...};`, classes)	Booleans written as 1 / 0.
`regex`	Anything else	The setting’s `pattern` has one capture group for the value.

TOML and Lua files have no form support yet; use regex or edit them in the Files tab.

Config files listed with platforms exist only on those operating systems; for example ArmA’s BattlEye file lives in a different place on Windows and Linux, and the form shows the right one for the service’s node.

Defining the forms is part of a game definition; see Writing game definitions.