GSManager runs Steam game servers from a web panel instead of a shell script

The panel is a rewrite, and the old versions are still linked

GameServerManager, shortened to GSManager, describes itself as a modern one-click deployment panel for game servers, focused on making deployment, management and maintenance simple, with emphasis on one-click server startup for Steam and Minecraft games.

The version history is worth understanding before anything else. GSM 3.0 is the current architecture, built on React, TypeScript and Node.js. GSM 2.0 was the classic version based on Python and Flask, and its source is still linked in a separate repository. GSM 1.0 was a game container, linked in another. So the project has been rebuilt once already, from a Python and Flask application to a TypeScript stack, and both predecessor code bases are still available.

That history explains a detail in the current tree. The server directory contains a Python/ subdirectory alongside the TypeScript sources, which suggests some functionality was carried over rather than rewritten, and it also means the project has had to support two very different deployment models over its life.

The stated features of the 3.0 rewrite are a modern web management panel built on Ant Design with a responsive layout, a real-time terminal built on Xterm.js that supports command execution and log viewing, real-time resource monitoring of server usage and game instance status, and a permission system based on JWT authentication. On the operations side it claims support for 40+ Steam game server titles with continued updates, unified management of game data and configuration files, WebSocket communication for immediate state updates, a full containerised deployment scheme, and a graphical editor for game configuration files.

The project is developed and maintained independently by a single author, and it is GPL-3.0 licensed with the licence file at the top of the repository. The site is gsmanager.cn and the documentation is on a separate docs host, with a QQ group for support and a GitHub Issues tracker for bugs.

The npm scripts show a three-part build with per-architecture targets

The build system is a workspace with a root package.json and one in each of client and server, and the scripts make the shape clear.

The install:all script runs npm install at the root and then in server and client, so the three dependency trees are separate. The dev script uses concurrently to run dev:server and dev:client at the same time, each of which changes into its own directory. The build script chains build:server and build:client, and the server build output is what start:prod runs from the dist directory.

The packaging is where the architecture support shows up. There is a package script that builds and then calls node scripts/package.js, and the target is passed as an argument:

"package:linux:x64": "npm run build && node scripts/package.js --target=linux-x64",
"package:linux:arm64": "npm run build && node scripts/package.js --target=linux-arm64",
"package:linux:riscv64": "npm run build && node scripts/package.js --target=linux-riscv64",
"package:windows": "npm run build && node scripts/package.js --target=windows",

Each of those has a matching no-zip variant with an extra --no-zip flag, which is a packaging detail that matters when you are producing artefacts for a system without the archive tools installed.

There is also a clean script that removes the dist directories with rimraf, and the repository contains start.sh, start-arm64.sh, dev-arm64.sh, install-gsm3.sh and a docker-compose-arm64.yml next to the main compose file, so the deployment paths are shell scripts and container definitions rather than a single installer.

The project also carries an AGENTS.md at the root and an opencode.config.json, and the contributor guidelines in the README explicitly allow AI-assisted contributions provided the editor has imported the project rules, alongside a rule prohibiting backdoors and behaviour that intrudes on the operating system.

The Docker image runs as root and maps the Steam directories

The docker-compose.yml is the deployment most people will use, and it makes a set of decisions that are worth reading carefully.

The service is called management_panel, built from the local Dockerfile, published as xiaozhu674/gameservermanager:latest, and it runs with user: root. The ports section maps 3001 to 3001 for the panel itself, with a comment about mapping game ports as needed, and 27015 to 27015 as the example, which is the default Source engine query port.

The volume layout is where the interesting comments are. The Steam user's config and local directories are mounted from ./game_data, and the Steam games directory from ./game_file, and the same two host paths are mounted again for the root user's config, local and steam games directories, with the annotation that these should not be modified. The panel's own data goes to a named volume, gsm3_data, mounted at /root/server/data, with a comment saying do not change it.

The environment sets TZ=Asia/Shanghai and SERVER_PORT=3001, and the service keeps stdin_open and tty true with a restart policy of unless-stopped. The named volume exists because the panel state is not just a directory of files you would want to keep in the repository, and separating it from the game data means a game wipe does not take the panel configuration with it.

The Dockerfile explains itself in stages. The base is debian:trixie-slim with a dependencies stage that installs the system packages, and the list is long: ca-certificates, locales, wget, curl, jq, gnupg, the Python toolchain with python3, python3-pip, python3-dev and python3-venv, then general system tools including nano, net-tools, netcat-openbsd, procps, tar, unzip, bzip2 and xz-utils, then Chinese fonts, then acl, sudo, and then libc++1 and libc++abi1 with a comment explaining that UE5 packaged game servers link against those C++ runtime libraries.

The architecture-specific work is conditional. On amd64 the build adds the i386 architecture with dpkg --add-architecture i386 and installs 32-bit libraries including libncurses6:i386, libbz2-1.0:i386, libicu-dev, libxml2:i386, libstdc++6:i386, libc6-i386, lib32stdc++6, libcurl4-gnutls-dev:i386, libgl1, libssl3:i386, libopenal1:i386 and libtinfo6:i386, along with .NET and Mono related packages such as libgdiplus, libc6-dev, libasound2 and libpulse0. This is the price of supporting game servers that ship 32-bit Linux binaries, and it only applies on x86_64.

SteamCMD, PTY and the live terminal are the reason a panel exists

The system integration layer in the README lists four things: SteamCMD, Docker, PTY support across platforms, and a unified file management system.

SteamCMD is the reason the whole project exists. Deploying a dedicated server for a Steam title means running the Steam command line tool, authenticating against the platform, downloading the dedicated server app and pointing it at the right directory, and then keeping the binary updated when the game patches. That is a script-shaped job, and the panel's value is turning it into a form.

The PTY piece is the part that is easy to overlook and hard to do without. A dedicated game server is a console program that expects a pseudo-terminal, reads commands from standard input and writes a live log to the terminal. Without a PTY, a game server started from a service manager or a container with no TTY either refuses to start or behaves incorrectly. The compose file sets stdin_open and tty precisely for this, and the server data directory holds runtime dependencies including the PTY and Zip-Tools binaries.

The web terminal built on Xterm.js then exposes that PTY to the browser, so an operator can type console commands into a running game server and watch the log, rather than only editing configuration files and restarting. Combined with the resource monitoring feature and the WebSocket channel for immediate state updates, the panel turns a server you manage over SSH into something you manage in a tab.

The data directory structure shows the same design at the file level. server/data holds games/, lib/ for runtime binaries such as the PTY and zip tools, and plugins/ for plugin data, which is where per-title installation recipes and configuration templates live.

ARM64 and RISC-V have different levels of support

The architecture story is not uniform, and the README is honest about the difference.

For ARM64 the project provides a full development path. If you are developing on ARM64, or need to emulate ARM64 on an x86_64 machine, the preparation is a QEMU user mode emulator and the ARM64 cross-compilation library:

sudo apt-get install qemu-user-static
sudo apt-get install libc6-dev-arm64-cross

The README notes that a specific ARM64 Node.js build, v20.19.0, must be installed at a given path, and points at scripts/arm/README.md for the full instructions. The shell scripts at the root give a set of modes, with install for dependencies only, dev-dual for a two terminal development environment, dev-simple for background mode and help for the usage list. The launcher script is start-arm64.sh, and there is a separate docker-compose-arm64.yml.

RISC-V is a different proposition. The README says a linux-riscv64 portable package is provided, and that it suits the web management panel and architecture adaptation testing. The package does not bundle Node.js, the PTY, the Zip-Tools or the 7z native assets, so the target system needs Node.js 18 or newer preinstalled, and the ZIP and 7z functions use the system unzip, zip and 7z or 7zz on demand.

That distinction is worth holding onto. RISC-V is a test node for the panel and for architecture work, not a supported place to run your game servers. The full support boundary is documented in a file under docs/ on multi-architecture support.

The stack is conventional, and the middleware is where the risk sits

The front end stack is React 18, TypeScript, Ant Design 5, Zustand for state, the Monaco Editor for editing configuration files, Xterm.js for the terminal, the Socket.IO client, Framer Motion for animation, Vite for the build and TailwindCSS for styling.

The back end is Node.js 18 or newer, TypeScript, Express, Socket.IO, JWT for authentication, Winston for logging, Multer for file uploads, node-cron for scheduled tasks, Axios for outbound HTTP and Joi for validation.

That is a sensible division. The editor choice is the one that carries the most product weight: putting Monaco in the browser means editing a game's config file with syntax highlighting and completion rather than in a text area, and it is why the graphical configuration editing feature is a real feature rather than a wrapper around a textarea. The JWT plus permission system means the panel is not a single-user tool on a home network, and node-cron means scheduled tasks such as restarts or updates can be part of the configuration.

The risk surface is the combination of JWT authentication with a server that runs game servers as root and shells out to SteamCMD. The panel authenticates a user, and that user can then reach a web terminal attached to a root process. The README does not describe session handling, token lifetime, rate limiting or an audit trail, so the security posture depends on configuration and on how you expose the panel, and the compose file publishes port 3001 to the host with no proxy or TLS in front of it.

Editorial conclusion

GSManager suits a person who runs one or more Steam game servers and wants a browser panel with a config editor and a live terminal instead of remembering SteamCMD arguments and editing files over SSH, and it is the wrong tool if you want a hardened production service, since the Docker compose file runs the container as root and mounts several host paths that the README explicitly says not to change. Before adopting it, check the architecture support document for your platform, since the RISC-V build is explicitly a panel and compatibility test node rather than a full deployment, and read the data volume layout because the panel stores its state under /root/server/data.

Frequently asked questions

Official sources

1. GSManagerXZ/GameServerManager on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases