Game Configuration: Execution & Docker
This is Part 3 of the Game Configuration series. Here we cover how GameCP actually runs your game server — the startup command, runtime mode, and Docker container settings.
Execution Configuration
Command
The Command field is the executable that starts your game server. This is the binary or script that Docker (or the host) will run.
Examples:
java— for Java-based games (Minecraft, etc.)./ValheimServer— for standalone executables/home/container/start.sh— for shell script entry points
Command Type
GameCP supports four command types, which change how the command string is executed:
| Type | How It Runs | Best For |
|---|---|---|
| Direct Command | Runs the executable with arguments passed separately | Simple executables like java or ./server |
| Bash Script | Runs via /bin/bash -c | Commands needing pipes, redirects, or shell features |
| Shell Script | Runs via /bin/sh -c | Minimal containers that may not have bash |
| PowerShell | Runs as PowerShell script | Windows-based game servers |
Most games use Direct Command. Switch to Bash or Shell when you need shell features like &&, pipes (|), or environment variable expansion within the command itself.
Game Folder
The directory inside the container where game files are stored. This is the path where installation downloads go and where the game expects to find its data.
Common examples:
/home/container— default for most Docker-based setups/opt/game— alternative convention
Working Directory
An optional subdirectory within the game folder where the command should actually execute. Leave this empty to run from the game folder root.
For example, if the game folder is /home/container but the executable is in a bin/ subfolder, set working directory to bin.
Mode
Two options:
- Docker (recommended) — runs the game inside a Docker container with full isolation, resource limits, and volume management
- Native — runs directly on the host system without containerization. Use only when Docker is not suitable for the game.
Command Preview
When using Direct Command type, the editor shows a live preview of the full command that will be executed, including any environment variable substitutions. This is useful for verifying your configuration before saving.
Docker Configuration
The Docker section controls how the container is built and managed.
Docker Image
The container image to use (e.g., itzg/minecraft-server, steamcmd/steamcmd:latest). This is pulled from Docker Hub or any configured registry.
Volumes
Volume mappings connect directories on the node to directories inside the container. The default mapping is:
${SERVER_FOLDER} → /home/container
This maps the game server's data folder on the node to /home/container inside the container. You can add additional volume mappings if the game needs access to other directories.
Resource Limits
Set limits on what the container can use:
| Resource | Description |
|---|---|
| CPU Limit | Maximum CPU cores (e.g., 2.0 for two cores) |
| CPU Shares | Relative CPU weight (higher = more CPU time) |
| Memory Limit | Maximum RAM (e.g., 4G for 4 gigabytes) |
| Swap Limit | Maximum swap memory (set to 0 to disable) |
| I/O Weight | Disk I/O priority |
| GPU Limit | GPU access configuration |
| Disk Limit | Maximum disk space |
| Network Limit | Network bandwidth cap |
These limits are enforced by Docker and prevent a single game server from consuming all node resources.
Additional Options
- Use Image Entrypoint — use the Docker image's built-in entrypoint instead of overriding it with the command
- Cache Enabled — enable Docker layer caching for faster container rebuilds
- Interactive Mode — keep stdin open (needed for games that accept console commands)
Tips
- Always test your command configuration by creating a single server first before deploying at scale
- The Command Preview is your best friend — check it before saving
- If a game fails to start, the first thing to check is the command and working directory
- Resource limits are optional but strongly recommended in multi-tenant environments
- When using Bash/Shell command type, the command and arguments fields merge into a single script — the command line editor isn't relevant