Game Nodes

What a game node is

A game node is a machine you own that runs customers' game containers. It is not a special class of hardware and it is not a separate inventory: it is one of the machines already in your infrastructure, doing a second job. The same machine can carry virtual servers and game servers at once, and the capacity arithmetic subtracts both from the same physical memory.

Because of that, you do not add a machine to game hosting. You add a machine once, and the platform brings it into game hosting on its own unless you say otherwise.

How to reach it

Open VPS → Game Hosting → Nodes. The page is titled Game Nodes, subtitled “Every machine this panel owns — whether it runs game servers, and what capacity is left on it”.

The machine list

One row per machine, whether or not it has become a game node yet. That is deliberate: a list of game nodes alone would silently drop the machine that has not converted yet and the machine somebody switched off, which are exactly the two rows you go looking for.

Columns

Column	What it shows
Machine	Its name, with its location and the role its agent runs underneath.
Game hosting	One of five states, described below, plus the reason when it is not running games. Also carries Closed to new servers, and a warning when the machine's guest-network protection is failing or has never been checked.
Servers	Game servers on the machine, shown against the server ceiling when one is set.
Memory sold	Committed to customers against usable memory. Reads Not reported where the machine has never reported its capacity, with the full sentence on hover.
Memory in use	The machine's own sample against its physical memory. Not reported means nobody has measured it, not that it is idle.
Oversell	The memory oversell multiplier in force on that machine.
Free ports	Free against total seeded, highlighted when it drops to eight or fewer. A machine with no inventory reads No ports seeded.
Last seen	When the machine last reported, from its game node or, before it has one, from its agent.
Switch	Turn off / Turn on for game hosting on that machine. A games-only box has no virtual-server side to switch to, so it shows a dash.

The five states

Game hosting state

State	Meaning
Running games	The machine is a live game node and can take new servers.
Preparing	It is being converted. Machines are prepared one at a time, a few minutes apart.
Not prepared yet	Queued. One machine is prepared every few minutes so the guest network can be checked between each.
VPS only	Somebody switched game hosting off for this machine.
Blocked	Something about the machine prevents it, and the reason is printed in the cell.

Common blocking reasons, written out in the row: no agent is installed; the agent has not been heard from; the machine is bare metal handed to a customer, so it never runs your containers; or the agent reports a role the panel does not recognise.

Filtering

A search box matches machine name, location, agent role, node name and tags. A dropdown filters by state. Both reset with Clear filters. Clicking a row opens the game node when it has one, and otherwise opens the machine itself — which is the screen that explains why it has no node yet.

Bringing a machine into game hosting

The usual way: add the machine once

Use Create → Node in the module's tab strip to install the agent on a machine and add it to your infrastructure — see VPS Clusters. Once its agent reports, a background pass registers it as a game node by itself — one machine per pass, every few minutes. The row moves from Not prepared yet to Preparing to Running games.

Machines are converted one at a time on purpose. Converting a machine that already carries customer virtual machines is not a free operation, so the pass stops at the first sign of trouble rather than working through the list.

A machine is skipped, quietly and correctly, when it has no agent, when its agent is not one that can run containers, when it belongs to another panel, when the switch on the row is off, or when the licence has no game node entitlement left.

The exception: a games-only machine

Games-only node, at the top right of the Nodes page, opens a four-step wizard for a box that should run game servers and nothing else. Its steps are Host → Install → Review → Done.

Step 1 — Host

List the machines to convert. Each row takes Host or IP, SSH port, SSH user and SSH password. Paste a list of hosts into the first field to fill several rows at once. Pick a Location; leaving it alone uses the first one you have. Root SSH access is required.

The password is used once, to write the agent's encrypted credentials, and is never stored. That is why a retry has to ask for it again.

The panel states what it will install: the runtime, the container engine, the disk-quota tooling and the firewall tooling — and nothing from the bare-metal set: no remote-console viewer, no IPMI, no SNMP, no DHCP or TFTP. If any package fails, the install stops and names it rather than leaving a half-built machine reporting healthy.

Warning: A machine that already runs a hypervisor is refused outright. Installing the container engine beside live guest bridges is not something the wizard will do next to customer virtual machines. Use a machine that is not a hypervisor.

The licence is checked before anything is installed, so an entitlement problem never leaves you with a converted machine you cannot attach.

Step 2 — Install

One pipeline per machine, each independent, so a machine that fails never stops the others. The stages are named as they pass: Waiting to start, Checking the licence, Installing the agent, Waiting for the agent to check in, Reading the host, Waiting for you, Creating the node, Seeding the port inventory, Waiting for the licence certificate, then Attached or Failed. A stage history is shown under each machine. On a fresh host the install takes a few minutes.

Step 3 — Review

This is a real stop, and the most important screen in the wizard. Everything before it is reversible and touches only the machine; everything after it consumes a licence slot and creates records. Nothing has been created yet.

The panel reports what it found: kernel, container engine (installed and answering, installed but not answering, or absent), firewall tooling, capacity (memory, threads, disk), storage root and its backend, addresses, and how many ports on the machine are already in use by something else.

The Disk quota block is the one to read carefully. It has three outcomes:

• Disk limits will be enforced on this node. Game data sits on storage the kernel can hold to a quota. A plan sold with a 10 GB disk gets 10 GB.
• No plan can be sold on this node. Game data sits on a plain directory, which cannot be held to a quota. Every game plan is sold with a disk figure, and the machine refuses to build a server against a limit it cannot enforce — so each order routed there fails on the machine rather than shipping a limit nobody honours. The fix is named on screen: put the game data root on a filesystem that supports quotas, then retry. You may attach the node anyway, and placement will refuse it until then; a checkbox makes you acknowledge that.
• Whether disk limits can be enforced here is unknown. Nobody read the machine. That is a gap, not a finding — check the storage before you sell on it.

Below the findings, the attach form: Node name (defaults to the host name), Memory oversell ratio, Server ceiling, Memory reserved for the host, CPU reserved for the host, Public addresses (one per line), and Port inventory to seed — one or more ranges, each with an address, a first and last port, and a protocol. A running count says how many ports each range will seed.

Two buttons finish the step. Attach the node creates it — live immediately if the machine was read, or as Provisioning and taking no servers if it was not, in which case check it and mark it active afterwards. Discard this host creates nothing and leaves the agent installed.

Warning: Attaching with no port ranges is allowed and the panel warns you. Nothing can be provisioned on that machine until ports are seeded from its own page.

Step 4 — Done

Each machine reports whether it attached and how many ports were seeded, with a link to open the node. Machines that did not finish can be retried individually. A retry picks up whatever already succeeded — the agent, the node record and any seeded ports are reused, never duplicated — but it needs the password again.

Taking a machine out of game hosting

Turn off on the machine's row makes it virtual-servers-only. Servers already on it keep running and customers see no change; it simply stops being chosen for anything new. Turn on puts it back, and the machine is prepared within a few minutes.

To stop new placements without changing the machine's role, use Stop taking new servers on the node's own Settings tab instead — see below.

The node page

Click a machine that has a game node to open it. The header carries its name, a status chip, its location and its agent. Underneath, a banner appears when the node is frozen, unreachable, or in maintenance, each stating the consequence, and maintenance also shows its reason and end date.

Node statuses

Active, Provisioning, Maintenance, Frozen, Unreachable. Frozen and Unreachable are set by the licence check and the agent heartbeat — they are not something you choose. Frozen means servers keep running while creating and reconfiguring are blocked. Unreachable means no job can run on the machine at all.

Overview tab

Four tiles — Memory sold, Memory in use, Disk sold and Oversell ratio — then a Capacity card with three bars: memory sold against usable, memory in use against physical, and ports allocated, with a line reading free, cooling down and total seeded.

A Node details card lists location, agent, memory reserved for the host, CPU reserved for the host, the server ceiling (or No ceiling), last seen, the public addresses, and any notes.

Ports tab

Port inventory is the constraint most people meet first. Ports are handed out of a pool declared in advance, never discovered while an order is running, so a node with no seeded ports can never provision anything. A banner says so, with a seed button in it.

Four tiles: Seeded, Free now, Allocated and Cooling down. Cooling down means released but held back, so the previous owner's players cannot reach a stranger — free and not-allocated are two different numbers and both are shown. The hold period is set in Game Settings.

The table lists every seeded port with its Address, Port, Protocol, what it is Allocated to (or Free, or cooling down until a time), whether it is the server's Primary, and a Label.

Seeding a range

Seed ports opens a dialog taking Address to seed on, First port, Last port and Protocol — TCP and UDP, TCP only or UDP only. A live count says how many ports the range will add. Every port in the range becomes one allocation entry, so declare only what the machine will really publish.

Note: Ports below 1024 are refused. The container runs unprivileged and could never bind one.

Servers tab

The game servers placed on this machine, with a link into each. Empty on a machine nothing has been placed on yet. The full list, with filters, is on Game Servers.

Backups tab

Backups are a machine-level fact as well as a customer one. A per-plan ceiling bounds one customer; what fills a machine is the sum, and the first symptom of a machine whose disk has gone to archives is a paid order that cannot provision.

Tiles cover Backup storage used, Backups held, Failed backups and Near a ceiling. A Per node chart shows how much of each machine is archives rather than servers, largest first, tinted by how much of the machine's remaining space its backups account for; a machine that has never reported storage is left out rather than drawn at zero. A Servers near a ceiling list names servers at or above a threshold of either their backup count or their byte limit. The table underneath gives per-server storage, backup count, failures and last backup, against both plan ceilings, with Plan sells none where backups are not part of the plan.

Settings tab

Nothing here saves until you press Save, and an unsaved-changes line sits beside the button.

Node settings

Field	What it does
Accept new game servers	Turning it off leaves every existing server running and stops the placer choosing this machine for anything new.
Server ceiling	A hard stop on the number of servers, on top of the memory arithmetic, for a machine whose real limit is something the panel cannot measure. Leave blank for no ceiling.
Oversell ratio	Usable memory is physical memory times this ratio. Must be between 1 and 10. 1.00 promises no more memory than the machine has; above that, the same memory is sold more than once. Raise it deliberately.
Reason shown to operators	A maintenance note shown on every page that touches this machine. It does not change what the machine does; it tells the next person why.
Notes	Free text for your own team.

Stop taking new servers sits beside Save and acts immediately after a confirmation. Existing servers keep running and customers see no change; only new placements are affected.

Network fence

Its own card on this tab, and not behind the Save button — re-applying it is an immediate action on the machine, not a field on a form. The fence is a set of firewall rules that stop game containers reaching your management network and the cloud metadata endpoint. Re-apply the fence rebuilds it from the agent's own configuration and writes it back to the persisted ruleset; the result appears once the agent answers.

Four states are reported:

• Applied and holding. Nothing to do. The last-applied time is shown.
• Applied and failing. Whatever rules are in the kernel right now are the ones that were there before the last attempt.
• Never applied. Containers on this machine have no egress restriction at all.
• This node's agent does not report the fence, so nothing can say whether one is loaded.

A rebuild count is shown when the ruleset keeps being flushed. Re-applying fixes the moment, not the cause — check whether the persisted ruleset is being loaded at boot.

How capacity is worked out

Three numbers decide whether a machine can take another sale, and they are kept apart everywhere:

• Usable memory = physical memory, less what is reserved for the host, times the oversell ratio.
• Sold = what has been committed to customers on that machine, from both products.
• Used = the machine's own sample of what it is actually doing.

Free memory is usable less sold, and it is what ranks candidates during placement: the machine with the most genuinely free memory wins, so servers spread rather than piling onto the first machine in the list.

Why a node is refused a server

The same admission check runs during a real order and inside the Placement preview you can open from a plan — see Game Plans. It reports every blocking reason for every candidate, not the first, so fixing one does not just uncover the next.

Placement refusals

Reason	What to do
The game hosting module is switched off on this instance.	Nothing on this page will help until it is on.
That game node no longer exists.	The plan or product points at something that has gone.
The node is not active.	Check its status banner — frozen, unreachable, provisioning or in maintenance.
The node is draining and takes no new servers.	Turn Accept new game servers back on.
The node has no agent attached.	Nothing can be built on it.
The node is already at its server cap.	Raise or clear the server ceiling.
The node has no sellable memory left for this plan.	Free capacity, raise the oversell ratio deliberately, or add a machine.
The node declares no public address, so it cannot serve a dedicated IP plan.	Add a public address to the node.
The node cannot enforce a disk quota, so it refuses every disk-limited plan — and every game plan is disk-limited.	Fix the machine's storage, as the onboarding review describes.

Warnings are shown separately and are not refusals: memory never reported so the ceiling is not being enforced, most of the CPU already sold (players feel that as lag before anything runs out of memory), a host reserve that leaves nothing to sell, and a machine whose quota support nobody has measured.

Common problems

• A paid order will not build and the reason is ports. Seed a range on the node, or move the order to a machine that has inventory, then retry the deployment from the service.
• A machine sits at Not prepared yet for a long time. Machines convert one at a time; check the row's reason, and check that its agent is reporting.
• Memory in use reads Not reported. Nothing has sampled that machine. Treat it as a gap and check the agent, not as an idle machine.
• Every plan is refused on one machine. Look at the disk quota finding for that machine first; it refuses every disk-limited plan, which is all of them.
• Nodes went frozen after adding hardware. More nodes are registered than the licence covers. Servers keep running; new work is blocked until the entitlement is raised.

Related: Game Hosting Overview, Game Servers, Game Settings, Locations, Local Agents.