How gsmanagerxz/gameservermanager works
1. Repository shape
- This is a monorepo with two primary runtime boundaries: client/ for the browser UI and server/ for the Node.js backend.
- The backend owns all privileged operations: filesystem access, process/PTY control, SteamCMD/game deployment, scheduling, and persistent data management.
2. Client-side application
- The frontend is a React 18 + TypeScript app built with Vite, Ant Design, TailwindCSS, Zustand, Monaco Editor, Xterm.js, and Socket.IO client.
- src/pages/ defines the main screens: home, login, file manager, instance manager, terminal, plugins, settings, deployment, scheduled tasks, environment management, and a developer page.
- src/components/ contains reusable UI and modal/dialog workflows for destructive actions, file editing conflicts, upload/compress confirmation, onboarding, network warnings, and system alerts.
3. Client state and live updates
- Zustand stores in src/stores/ hold cross-page application state such as auth, files, notifications, theme, wallpaper, console logs, network status, onboarding, and system alerts.
- The client uses a mixed data model: REST-style API utilities for transactional operations and Socket.IO for live terminal output, console logs, notifications, and status refreshes.
4. Backend application boundary
- The server is a TypeScript Node.js + Express app with modular routing under src/routes/.
- src/index.ts is the entry point, and middleware such as src/middleware/auth.ts enforces authenticated access to protected APIs.
- The server is the only layer that touches local OS resources directly.
5. Core backend domain modules
- The backend is organized around managers in src/modules/, each encapsulating a domain:
- auth for login/JWT/captcha flows
- instance for game instance lifecycle
- game and gameConfig for game-specific deployment and config handling
- file and task for file watching, uploads, compression, and background operations
- terminal for PTY-backed interactive shells
- rcon for remote console control
- scheduler for timed jobs
- system for system-level monitoring/state
- plugin for plugin lifecycle and API exposure
- backup for backup creation/management
- steamcmd and environment for runtime prerequisites and installers
6. Data and control flow
- User actions in the UI typically flow: page/component → client utility/store → backend route → module manager → filesystem/process/network side effect.
- Real-time flows, such as terminal output or instance status, go through Socket.IO instead of only polling.
- File uploads and long-running jobs are offloaded to task managers/workers so the UI can observe progress rather than block.
7. File, upload, and compression subsystem
- Large file handling is a major subsystem: chunkUploadManager, chunkUpload.ts, and related tests indicate resumable/chunked uploads with integrity and preservation concerns.
- Compression/extraction work is isolated into worker-based logic under server/src/modules/task/ and guarded by tar/zip security utilities.
- File watching is handled separately so UI state can reflect external edits or deletions.
8. Game deployment and configuration management
- Game-specific deployment is centralized in GameManager, InstanceManager, SteamCMDManager, and route handlers such as gameDeployment, games, minecraft, and moreGames.
- Configuration is treated as first-class data: gameConfig manages visual/config-file templates, with sample YAML configs stored under server/data/gameconfig/.
- This strongly suggests a deployment pipeline: select game/template → install via SteamCMD or game-specific logic → write instance/config files → start/manage the server process.
9. Terminal, RCON, and system integration
- Interactive server control uses a PTY abstraction in src/utils/ptyManager.ts and terminal session management modules.
- Game consoles can also be controlled through RCON, which is exposed as a separate backend concern rather than being mixed into the terminal layer.
- System utilities and environment managers cover prerequisites like Java, DirectX, VC++ redistributables, package installation, and general host inspection.
10. Plugin and extension architecture
- The repository supports plugins as a runtime extension boundary: server/data/plugins/ contains plugin packages and documentation, while pluginApi and PluginManager handle loading and exposure.
- There is also a dedicated developer module on both client and server sides, suggesting an internal admin/developer surface for inspecting or packaging the system.
11. Persistent storage layout
- Runtime data is concentrated under server/data/, including game state, plugin data, RCON state, startup markers, and game configuration templates.
- This means the backend is not stateless; the filesystem is part of the application model and should be treated as a primary persistence boundary in any diagram.
12. Operational and packaging layer
- Docker files, compose files, and ARM64 scripts show that deployment is containerized and also supports non-x86 environments.
- GitHub Actions workflows indicate CI for builds and PR checks, while the scripts/ tree contains platform-specific bootstrapping for ARM64 and packaging.
- Tests are present for critical utility areas like 7z tooling and chunk uploads, reinforcing that file operations and archive handling are operationally sensitive parts of the system.
Main entry points: routes Routes · App.tsx UI shell · utils API layer · index.ts Server entry
Components 23
Client
Browser UI runtime and shared state
- UI shell · Application bootstrap and route-level composition for the browser client
client/src/App.tsx - Pages · Main screens for login, files, instances, terminal, plugins, deployment, settings, and admin surfaces
client/src/pages - UI components · Reusable dialogs, modals, layout pieces, warnings, editors, and terminal widgets
client/src/components - Zustand stores · Cross-page state for auth, files, notifications, theme, wallpaper, console logs, network, onboarding, and alerts
client/src/stores - API layer · Client utilities for transactional API calls, file operations, and real-time Socket.IO events
client/src/utils - Developer module · Dedicated internal developer/admin surface with auth, tools, and packaging flows
client/src/modules/developer
Server
Node.js backend and privileged operations
- Server entry · Backend startup and top-level application wiring
server/src/index.ts - Routes · Modular route layer for auth, files, instances, deployment, plugins, tasks, system, terminal, and more
server/src/routes - Auth middleware · Authenticated access gate for protected backend APIs
server/src/middleware/auth.ts - Instance manager · Game instance lifecycle and orchestration
server/src/modules/instance/InstanceManager.ts - Game deployment · Game-specific install and deploy logic, including game adapters
server/src/modules/game/GameManager.ts - Game config · Visual and file-based game configuration templates and persistence
server/src/modules/gameConfig/GameConfigManager.ts - File & tasks · File watching, chunked uploads, compression, extraction, and background file operations
server/src/modules/file/FileWatchManager.ts - Terminal · PTY-backed interactive shell sessions and terminal control
server/src/modules/terminal/TerminalManager.ts - RCON · Remote game console control separate from PTY terminal sessions
server/src/modules/rcon/RconManager.ts - Scheduler · Timed and background job orchestration
server/src/modules/scheduler/SchedulerManager.ts - System & env · Host monitoring plus prerequisite and installer management such as Java, DirectX, VC++ redistributables, and packages
server/src/modules/system/SystemManager.ts - Plugin runtime · Plugin loading, plugin API exposure, and runtime extension management
server/src/modules/plugin/PluginManager.ts - Runtime data · Persistent application data under server/data including game state, plugins, RCON state, startup markers, and config templates
server/data - Developer API · Developer-specific backend controller, routes, middleware, and service layer
server/src/modules/developer - Task workers · Worker-based compression and file operation execution for long-running jobs
server/src/modules/task
Ops
Packaging, deployment, and CI
- CI workflows · Build and PR validation workflows
.github/workflows - Deploy scripts · Docker, compose, ARM64 bootstrap, and packaging scripts
docker-compose.yml
Connections 30
- UI shell → Pages: renders · UI shell composes the page-level application screens
- UI shell → UI components: uses · Shared UI building blocks and dialogs are assembled into the app
- UI shell → Zustand stores: reads/writes · Application state is coordinated through Zustand stores
- Pages → API layer: calls · Pages trigger REST actions and subscribe to live updates through the client API layer
- UI components → Zustand stores: binds · Global modals, banners, and widgets reflect store-backed state
- API layer → Routes: requests · Client utilities communicate with backend route handlers
- API layer → Server entry: socket connect · Realtime features connect to the server runtime for live events
- Developer module → API layer: uses · Developer UI talks to dedicated developer endpoints
- Server entry → Routes: mounts · Top-level Express bootstrap installs the route modules
- Routes → Auth middleware: protects · Protected APIs are gated by authentication middleware
- Routes → Instance manager: orchestrates · Instance-related endpoints delegate lifecycle control to the instance manager
- Routes → Game deployment: deploys · Deployment and game selection routes use game manager logic
- Routes → File & tasks: handles · File and task routes offload to file-watch and background job handling
- Routes → Terminal: opens · Terminal routes manage interactive PTY sessions
- Routes → RCON: controls · RCON routes expose remote console control
- Routes → Scheduler: schedules · Scheduled task routes delegate to the scheduler manager
- Routes → System & env: inspects · System and environment routes query host state and prerequisites
- Routes → Plugin runtime: exposes · Plugin and plugin API routes delegate to the plugin runtime
- Routes → Developer API: serves · Developer routes reach the backend developer module
- Game deployment → Game config: applies · Game deployment uses configuration templates and saved config data
- Game deployment → System & env: depends on · Game installation and runtime preparation require host tooling and prerequisites
- File & tasks → Task workers: offloads · Long-running archive and file operations run in workers
- Task workers → Runtime data: reads/writes · Workers and managers persist runtime files and state under server/data
- Plugin runtime → Runtime data: loads · Plugin packages and metadata are stored in the persistent data tree
- Terminal → Runtime data: persists · Terminal and startup-related state is stored on disk when needed
- RCON → Runtime data: persists · RCON state and credentials/data are stored under the runtime data tree
- CI workflows → Server entry: builds · CI validates the server and repo build pipelines
- CI workflows → UI shell: builds · CI validates the client build pipeline
- Deploy scripts → Server entry: packages · Docker and ARM64 scripts package and launch the backend
- Deploy scripts → UI shell: packages · Deployment scripts include the browser client build and runtime