Skip to content
CatalystCatalyst Docs

Overview

A node is a Linux machine that runs game servers. The panel never runs games itself — it tells nodes what to run, and the agent on each node does it.

Lifecycle

Section titled “Lifecycle”
  1. Register — create the node in the panel and copy the install command it shows (registering a node).
  2. Install — run that command on the machine; the agent connects back to the panel (installing the agent).
  3. Allocate — define the IP addresses and port ranges servers may use, so they get join addresses.
  4. Operate — create servers on it, watch health, and apply agent updates (updating a node).
  5. Retire — migrate servers off, then remove the node.

Registering comes first on purpose: the panel issues the credential the agent authenticates with, so the node record must exist before you run anything on the machine.

How panel and node communicate

Section titled “How panel and node communicate”
  • The agent calls the panel (outbound HTTPS/WebSocket). Nodes do not need inbound panel ports — useful behind NAT.
  • Players connect directly to the node on game ports.
  • If the link drops, running servers keep running; the panel shows the node as unreachable until the agent reconnects. See node issues.
  • The agent reports its version on every check-in. When the panel is newer, the node’s page flags an update and offers Update Agent.

Capacity thinking

Section titled “Capacity thinking”

Nodes are divided by memory first, CPU second, disk third. Overcommitting memory causes the worst failures (the kernel kills game processes), so keep headroom and set per-server limits honestly. Node-level over-allocation is a percentage you set when registering: 0 disables it and -1 treats capacity as unlimited. Monitoring shows when a node is full before your players notice.

Section titled “Related”