Server Management

Servers are the core resource in BadgerPanel. Each server represents a game server instance running on either a Linux/Windows node (daemon deployment) or a Kubernetes cluster. This guide covers creating, configuring, and managing servers from the admin panel.

Creating a Server

Navigate to Admin > Servers > New Server. The creation wizard walks through the following steps:

1. Select Deployment Type -- Choose between daemon (runs on a node) or kubernetes (runs on a cluster).
2. Select Node or Cluster -- For daemon deployments, pick a node with sufficient available resources. For Kubernetes, select an orchestrator and namespace.
3. Select Egg -- Choose the game template (egg) that defines the Docker image, startup command, and configuration variables. The egg determines which game the server runs.
4. Select Allocation -- For daemon deployments, choose an available IP:port allocation on the selected node. If the egg defines a default port, allocations matching that port are shown first.
5. Configure Resources -- Set memory (MB), disk (MB), CPU limit (%), swap, I/O weight, and optional CPU thread pinning. Also set backup, database, and allocation limits.
6. Assign Owner -- Select the user who will own this server.
7. Set Startup Variables -- Override any egg variables (server name, version, etc.) if needed.
8. Review and Create -- Confirm settings. The server enters installing status while the install script runs.

Power Actions

From the server detail page (Admin > Servers > [server]), the following power actions are available:

• Start -- Sends a start signal to the daemon or creates the Kubernetes pod.
• Stop -- Sends a graceful stop command (configurable per egg via config_stop).
• Restart -- Performs a stop followed by a start.
• Kill -- Forcefully terminates the process (SIGKILL on Linux, TerminateProcess on Windows, pod delete on Kubernetes).

Power actions are also available from the server list using the actions menu on each row.

Resource Modification

To change a server's resource limits, open the server detail page and edit the Resources section. You can modify memory, disk, CPU, swap, I/O weight, and thread pinning. Changes take effect on the next server restart. For Kubernetes servers, resource requests and limits on the pod spec are updated accordingly.

Suspension

Suspending a server stops it and prevents the owner from starting it. Navigate to the server detail page and toggle the Suspended switch. Suspended servers show a suspended status badge. To unsuspend, toggle the switch off. The server does not automatically restart after unsuspension; the user must start it manually.

Server Transfers

To move a server between nodes, use the Transfer action on the server detail page. Select the destination node and a target allocation. BadgerPanel copies server files to the new node, updates the allocation, and then removes files from the source. During transfer, the server is stopped and locked to prevent modifications. If both nodes support live migration via CRIU, the transfer can be performed without downtime.

Reinstallation

Reinstalling a server re-runs the egg's install script. This is useful when a server's game files are corrupted. The server is stopped, the install script executes in a temporary container, and the server returns to offline status when complete. Existing server files in the data directory are preserved unless the install script explicitly removes them.

Bulk Operations

From the server list (Admin > Servers), select multiple servers using the checkboxes, then choose a bulk action from the toolbar:

• Bulk Start / Stop / Restart / Kill -- Sends power actions to all selected servers.
• Bulk Suspend / Unsuspend -- Toggles suspension on all selected servers.
• Bulk Delete -- Permanently removes all selected servers and their files.

Bulk operations are processed concurrently. Progress is displayed in a status overlay.

Docker vs. Kubernetes Differences

Feature	Daemon (Docker/Windows)	Kubernetes
Isolation	Docker containers or Windows Job Objects	Kubernetes pods
Networking	IP:port allocations managed per node	NodePort or LoadBalancer services
Storage	Local disk on the node	Persistent Volume Claims (PVCs)
Resource limits	Docker cgroup limits / Job Object limits	Pod resource requests and limits
Scaling	Manual (add more nodes)	Cluster auto-scaling supported
Live migration	CRIU-based (Linux only)	Pod rescheduling

Server Statuses

Servers can be in the following statuses: installing, install_failed, suspended, restoring_backup, offline, starting, running, stopping. The status is updated in real time via WebSocket heartbeats from the daemon or orchestrator.