Manage servers

Game servers run in workspaces, each with its own files, start command, resources, ports, and members.

Create a server

You need Panel administrator access and an online node with Running Docker and current inventory.

1. Select Create workspace in Workspaces.
2. Enter a name and choose a node with enough capacity.
3. Select an enabled image matching the node's architecture; add or enable one in Images if needed.
4. Set CPU and memory limits.
5. Set container ports, host ports, and TCP/UDP protocols for the game; use a public host address only for ports players need to reach. Panel checks host ports before saving; occupied or unverified ports block the operation.
6. Choose an outbound network policy and DNS servers. Private-network isolation requires a Linux node and public DNS; unrestricted access can inherit node DNS. DNS changes require container recreation.
7. Enter the start command; leave it empty if game files are not ready.
8. Review the settings, select Save, and wait for creation. If the result is uncertain, inspect the operation before submitting another request.

Upload server files to /workspace in Files, complete the start command, and start the service, following the game's setup and licensing requirements.

You can also prepare server files with a plugin.

Daily operations

Action	Details
Start, Restart, Stop	Control the primary service; starting and restarting require a start command
Console	Read the primary service's output and send commands supported by the game server
Terminal	Create or reconnect to a separate Shell command session inside the workspace; requires operator or administrator access
Files	Upload, download, edit, copy, move, and extract files under /workspace; available while the service is stopped
Start command	Operators and administrators can edit the command; saving may restart the service
Members	Administrators assign access; see Users and permissions

Stopping the primary service leaves Terminal sessions and Files available. If the start command is empty, prepare the files and command before starting the game.

The start command runs from /workspace, for example exec ./server. Use Panel’s Start and Restart controls to keep game status and output visible.

Even when the service reports running, check Console and try connecting to the game. An offline node reports unknown state; this does not mean the service has stopped.

Editing container settings can rebuild the workspace, preserving /workspace and replacing other container files; keep game data in /workspace and back up before rebuilding.

Deleting a workspace permanently deletes its containers, volumes, and all data, including when an offline node reconnects; select Stop to retain data.

Arrange workspace tools

On desktop, open Customize tabs in the workspace tools area, select which tools to show, and drag to reorder them. Enable Workbench mode to place tools on the right or at the bottom and view two tool areas alongside the conversation. Drag the dividers to resize them. Reset restores the default arrangement and layout. Preferences stay in the current browser.

On a phone, use the tools button at the top of the conversation, then select Console, Files, or a plugin. Viewers can inspect Console and Files; interactive Shell sessions require operator or administrator access.

Console and Shell sessions

Use Console for game commands and Terminal for system commands. Select an existing Terminal session to reconnect.

After a brief disconnection, Panel resumes retained output. Completed Terminal sessions remain available for seven days. Reopen recent output if it cannot resume. If input delivery is uncertain, check the result before retrying; Panel does not automatically resend input.

While your login remains valid, Panel refreshes it before opening terminal connections or downloading files. Sign in again when prompted if the session has expired.

Files, variables, and secrets

Files manages data under /workspace. Leave the reserved .gamex directory untouched; links outside the workspace cannot be accessed.

• Use upload/download transfers for large files. ZIP, TAR, and TAR.GZ archives support inspection and extraction; select a filename encoding when older archives display incorrect names. Extraction preserves existing files, so choose a new destination or resolve conflicts first.
• Uploads and plugin imports share the system file upload limit, which defaults to 2 GiB. Ask an administrator to check File upload hard maximum in system settings if a file exceeds it.
• Save application configuration in Variables and secrets. Secret values override variables with the same name and are redacted from captured output. Existing processes keep their launch environment: open a new Shell session or restart the service through Panel after changes.
• The assistant can inject only the Secrets needed by a Shell command. This selection does not isolate files or processes within the shared container.
• /workspace/WORKSPACE.md holds shared instructions for the AI assistant. Operators can edit it in Files; existing content is preserved during initialization.

Scheduled tasks

1. Select Create task in the workspace's Automation tasks.
2. Choose a console command, shell script, service start/stop/restart, or AI prompt.
3. Set a one-time or recurring schedule and timezone, or a server start/stop trigger.
4. Save the task.
5. Check the result in Run history.

Tasks use the creator's current permissions. Losing write access or disabling the account pauses schedules that can no longer run. Select Disable to stop future runs; deleting a task preserves its run history. Cancelling a run does not undo completed changes.

AI tasks require a configured model. See AI schedules for related settings.

If it does not work

• No node or image available: check connectivity, inventory, Docker, scheduling state, version compatibility, and image architecture.
• Cannot start: check the start command, game files, Docker, available memory, port conflicts, and Console errors.
• Players cannot connect: check the listener, published TCP/UDP ports, host address, and firewall. A host endpoint check confirms only what the Daemon host can reach; it does not prove public reachability. UDP needs an application response.
• Controls are unavailable: check workspace permissions, node connectivity, and active operations. Rebuilds, repairs, and restores wait for conflicting work; a queued request has not yet completed.
• Quarantined or missing runtime: inspect the status explanation and operation audit before repair. Ask an administrator to verify container identity and retained data.