How game servers work

Egg to container: the full chain from template to running workload.

Repository-validated operator guidance View source ↗

#The chain

1. An egg defines the template: startup command, Docker images, install script, config, and file denylist. Egg variables are validated (UPPER_SNAKE names, typed rules). 2. POST /servers creates the server through placement, falling back to the egg's default memory. 3. Forge builds a provision target: resolved environment, mounts, allocations, image, limits. 4. The panel sends one signed HTTP command to Beacon — commands never travel over websockets. 5. Beacon materializes the container with the selected runtime (Docker is the verified production path) and reports observations back over /api/remote.

FLOW

Egg to container

01Egg templateplace

02Server createdbind port

03Allocation reservedsigned HTTP

04Beacon commandrun

05Container running

#Power and console

Server details dialog with live telemetry — Server details with live telemetry, power controls, and console access.

Power signals are start, stop, restart, and kill, with idempotency keys on the power route. Console input is line-limited and single-line. Console, stats, logs, backup, and install progress stream over ticketed websockets (60-second single-use tickets); everything else is HTTP.

Under /api/v1

GET|POST /nests  /nests/:id/eggs  /eggs/:id  (+ variables)
GET|POST /servers   GET|PATCH|DELETE /servers/:id
POST /servers/:id/power {signal}   /command   /install|/reinstall
GET  /servers/:id/startup  PUT .../startup/variable
POST /servers/:id/ws/ticket?stream=console|stats|logs

#Allocations

Allocations reserve IP plus port plus protocol (TCP or UDP, lowercase, default TCP) on a node. Container port defaults to the host port. An allocation cannot be deleted while assigned, the primary cannot be unassigned, and assignment requires the same node. Server transfers move servers between nodes with cancel support.