GBR Hosting game templates

Every game you can host on GBR Hosting is defined by a template in this repo. They're public so you can see exactly what your server runs: the Docker image, the startup command, the install script, and every default setting.

Layout

games/<id>/game.yaml   the template
games/<id>/test.yaml   values CI uses to boot-test it
schema/                JSON Schemas for both files
cmd/gbrgames/          validator and importer

Reading a template

Field	What it means
defaultDockerImage	The container image your server runs in.
defaultStartupCommand	The command started inside that container.
installMethod / installConfig	How game files are installed: STEAMCMD (anonymous SteamCMD download of appId), BASH_SCRIPT (the script shown in full), or NONE (the image already contains the game).
defaultPorts	Ports opened for players.
defaultConfig	Starting value for every setting.
configSchema	Which settings you can edit in the panel, with their types and limits.
configFilePath / configFileFormat	Where settings are written in your server's files, and in what format (INI, JSON or ENV).
backupPaths	What's included in backups.

Your settings vs. the defaults

When you create a server, it starts with defaultConfig. Anything you change in the panel overrides that one setting for your server only; everything else keeps following the template. A few settings are fixed by your plan. For example, the key named in maxPlayersConfigKey always matches your plan's player count.

Values filled in for you

Some defaults are placeholders the panel replaces when your server starts:

Placeholder	Becomes
{SERVER_NAME}	Your server's name.
{PUBLIC_IP}, {PUBLIC_HOST}, {PUBLIC_PORT_n}	The address players connect to.
{saved:KEY}	A value you stored under Saved Values (e.g. a password or token).

Generated passwords

Admin and RCON passwords are never shared between servers. A setting marked x-generate is left blank in the template, and if you leave it blank when you deploy, your server gets its own easy password like otter-maple-42. You can see it and change it any time in your server's settings. Values under replace are old shared defaults: a server still using one gets a fresh password the next time it starts.

Agreements

A setting marked x-consent in configSchema (a game's EULA, for example) is never accepted for you. You tick it yourself when you deploy.

Changes

Templates are maintained by GBR Hosting. Every change is a commit here, so the history shows what changed for each game and when. Want a game added or something fixed? Open an issue.

Tooling

go run ./cmd/gbrgames validate                     # what CI runs on every push
go run ./cmd/gbrgames import admin-games.export.json  # pull templates from GET /api/v1/admin/games

go run ./cmd/gbrgames inspect-image -game <id> pulls the game's Docker image and reads what it needs without starting the game: its user, home folder permissions, ports, tools and startup scripts. It then checks the template against that, e.g. an image built around its own user needs containerUser, and a startup command must read settings under the names the node gives them (RCONPort arrives as RCONPORT). Boot tests run it first, so these fail in seconds. -json prints the facts for tooling.

Besides the schemas, validate checks that each folder name matches its id, that referenced config keys exist, that consents don't default to accepted, and that no credentials or private network addresses end up in a template.