Game Hosting Overview

What game hosting is

Game hosting sells one game server — a container running a single game instance — to one customer, on machines you own. The customer gets an address to hand to their players, a live console, a file manager, backups, scheduled restarts and, where the game supports it, a mod installer. You get a product to price, a plan to size it with, and a capacity model that tells you how many more you can sell before a machine is full.

It is not a separate product from your virtual machines. It is a section of the same module, running on the same machines, watched by the same people. A machine that runs virtual servers also runs game servers unless you tell it not to.

Note: Game hosting is switched on per company. When it is on, a Game Hosting tab appears inside the VPS module and game products become sellable. If you do not see it, it is not part of your current setup.

How to reach it

Open VPS in the sidebar — see VPS Overview. The module's tab strip runs across the top: Overview, Clusters, All VPS, Groups, Game Hosting, Jobs, Settings, with a Create button at the end. Choose Game Hosting.

A second strip then appears underneath it, and it stays on every game page including the two detail pages:

• Overview — the module dashboard described below.
• Nodes — every machine you own, whether it runs game servers, and how much of it is left. See Game Nodes.
• Servers — every game container, billed or not. See Game Servers.
• Catalogue — the games you can sell and anything waiting on your approval. See Game Catalogue.
• Settings — module behaviour, the storefront seeds, mod sources and the game calendar. See Game Settings.

There is no Plans tab. A game plan is edited on the product that sells it, on the product's own Game server configuration section — see Game Plans. Old links to a plans page redirect to Products.

The relationship to the VPS module

Three things are shared, and understanding them saves a lot of confusion later.

The same machines

A game node is a machine on your own infrastructure — bare metal, or a virtual machine this module built. When you add a machine (see VPS Clusters) and its agent reports in, the platform registers it as a game node on its own within a few minutes. You do not add a machine twice. The Nodes tab lists every machine and gives each one a Turn off / Turn on switch so a box can be kept for virtual servers only.

Because the two products share the physical memory of a machine, the capacity figures subtract each other. What one module has committed is not offered again by the other.

The same licence

Every game node consumes one game node entitlement on top of the VPS cluster slot the same machine already uses. The panel says so before it installs anything, so an entitlement problem never leaves you with a converted machine you cannot attach. Both are bought together on your own licence — see License.

When more nodes are registered than the licence covers, the nodes past the limit are marked Frozen. Servers already on a frozen node keep running and customers keep their console and their files; creating a server there and changing an existing one are blocked. Nothing is deleted and nothing is stopped.

The same people

Two permissions gate the whole module, listed under the Game Hosting category when you edit a department: View Game Nodes and Edit Game Nodes. View is enough to read every page and to watch a console; editing anything — power, files, settings, plans, approvals — needs the edit permission, and the console re-checks it every time somebody attaches, so a view-only member can watch a console but not type into it. See Departments.

The sidebar row is shown to anyone holding either the VPS or the game permission, so a member who only runs game hosting still reaches it.

The Overview dashboard

Everything on this page comes from a single reading taken at one moment, refreshed about once a minute, with an Updated timestamp under the title. If a refresh fails, the figures already on screen are kept and a line appears saying they are older than they look.

Sold and used are never mixed

Two different numbers are shown for memory and they mean different things. Sold is what has been committed to customers. Used is what the machines are actually doing. A node at 40% used and 200% sold is what overselling looks like and is fine; the same node at 95% used is not. Where nothing has reported a figure, the page prints Not reported rather than a zero — an unmeasured machine must never read as an idle one.

The tiles

Dashboard tiles

Tile	What it shows
Active nodes	Nodes currently active, out of every node registered.
Game servers	Total game servers, with how many are running.
Memory sold	Committed to customers against usable memory — physical memory times the oversell ratio, less what each node reserves for itself.
Memory in use	What the machines themselves report, against their physical memory.
Free ports	Ports free right now, out of the total seeded, with how many are cooling down. If nothing has been seeded anywhere, it says so — nothing can be provisioned without port inventory.
Disk sold	Disk committed to customers.
Unbilled servers	Servers that are running but linked to no billing service, so nobody is paying for them.
Awaiting approval	Catalogue entries whose newly published content has not been approved yet.

Needs attention

Underneath sits the alert list, each entry marked Critical, Warning or Notice, with a count of each in the subtitle. Six show at a time with a Show all link. Where an alert has a place to send you, the row carries a link — to the node, to the server, or to the server list already filtered. When nothing is wrong the panel says so plainly.

What can appear here:

• No node has ever registered, so nothing can be sold yet.
• A node is unreachable, its agent is offline, or it has not reported for hours while claiming to be online.
• A node is frozen by the licence limit, is in maintenance, or has been closed to new servers.
• A node is short of disk, short of free ports, or has no port inventory at all.
• Memory is committed at more than the machine physically has, or the host itself is under memory pressure.
• Servers in an error state, servers whose install failed, suspended servers, orphaned servers, and servers nobody is being charged for.
• Catalogue entries with new executable content waiting for approval.
• Agent jobs that failed in the last 24 hours.
• Schedules that have failed several times in a row and so have stopped running.
• A node whose network protection has never been applied, is failing to apply, or keeps being rebuilt.

The rest of the page

Sold capacity over time plots memory sold and server count over the window you pick — Last 24 hours or Last 7 days. It is what was sold, not what the machines are doing. Servers by status breaks the total down, with counts of jobs waiting for an agent and jobs that failed in the last day. At the foot, a short node table with an All nodes link.

The runtime banner

A banner sits above everything else when the module is doing bookkeeping without building anything. It has two forms, and they need different actions:

• No game node is online, so nothing is being built. Add a machine, or wait for an existing one to check in. The button takes you to Nodes.
• The node runtime is in stub mode. No containers are being built. Somebody has deliberately held the module still. The button takes you to Game Settings.

While either is true, orders still invoice and settle, and customers are told these features are not switched on — so a sale made now delivers nothing. The platform works the first case out for itself: the runtime goes live the moment a game node's agent starts reporting, and holds again when the last one goes away. There is nothing to switch on after adding a node.

From nothing to a first sale

1. Get a machine in. Add it from the module's Create menu, or use Games-only node on the Nodes page for a box that should run nothing else. Read Game Nodes first — the wizard's review step is where you learn whether disk limits can be enforced on that machine, and no game plan will build on one where they cannot.
2. Seed port inventory. Ports are handed out of a pool declared in advance, never discovered while an order is running. A node with no ports can never provision anything, and the first symptom is a paid order that will not build.
3. Check the catalogue. Entries arrive with your licence and can also be imported. Approve anything waiting. See Game Catalogue.
4. Build the storefront. Either seed products and add-ons from Game Settings → Storefront, or create a product by hand and fill in its plan. See Game Plans.
5. Sell it. A game server is created by an order, not by a button in this module — the module's Create → Game server entry opens the order form filtered to game products. See New Order.

What happens between payment and a running server

When a game order is paid, the platform:

1. Checks that game hosting is switched on. If it is not, the order is refused and nothing is charged for a server that does not exist.
2. Reads the sizing from the plan and the product only. Nothing a customer sends with an order can change memory, disk, CPU, slots or ports.
3. Resolves which game to install: the plan's catalogue entry, overridden by the product's forced entry, overridden by the customer's own choice only when that product allows it.
4. Picks a node. Candidates are filtered to the location the customer chose, judged one by one, and the node with the most genuinely free memory wins. Every rejected candidate keeps its reason.
5. Creates the server record, reserves its ports and its file-transfer account in one step. Either all of it commits or none of it does.
6. Folds in any add-ons bought with the order, so paid memory and slots are in the container from its first boot rather than arriving as a change a minute later.
7. Asks the node to build it, and waits. The service is not marked active at this point.

When the node reports the build finished, the service goes active and the welcome email goes out. That letter is the only place the customer ever sees their file-transfer password, because nothing stores it in a form anyone can read back.

When a build fails

The service is marked Provisioning failed and the reason is written on it in plain words. The reasons are specific: no node could take it, the node had no free port, the plan gives less memory than the game needs to start, the product names no plan or a plan that has been deactivated, or the game is waiting on an approval. Ports reserved for the attempt are handed back. Nothing is charged for a server that does not exist, and the customer is told a matching sentence on their own page.

To retry, open the service and use Retry deployment — see Service Details. The retry starts fresh; it does not build a second server for a service that already has one. Fix the cause first: seed ports, free capacity, reactivate the plan, or approve the catalogue change.

One outcome is not a failure. If the name the customer chose was already taken on that node, the server is built under a slightly different name and everything else is exactly as ordered. The name is a label only.

What the customer gets

A game service appears in the customer's portal under their services, alongside everything else they buy from you — see Managing Your Services. On it they see the server's status and whether the game itself is up, power buttons, the connect address to hand to players, their plan, any add-ons they can buy, the settings the game exposes, their file-transfer details, and a tab strip carrying Console, Files, Backups, Schedules and Mods. Anything their plan or their situation does not allow is shown greyed with a plain sentence saying why, never as a control that fails when pressed.

Game Servers covers every one of those surfaces from both sides.

Limits and exclusions

Stated plainly, so you do not promise any of it:

• There is no reinstall and no per-server resize control. A server's size changes by buying an add-on or moving to another plan through an upgrade path, not by editing the container.
• A plan change cannot change the game. Moving a server to a plan that runs a different game or version is refused on both sides; that is a new server, ordered as one.
• There is no player list and no per-server player management. Player slots are a number the plan sells and writes into the game's own configuration; the platform does not read who is connected.
• There are no sub-users on a game server. Access follows the account that owns the service.
• Backups live on the same machine as the server. They protect against a bad update, a broken mod or a wipe nobody meant to run — not against the loss of the machine. There is no backup download; restore it, or fetch individual files over SFTP.
• No mod file passes through the platform. The panel resolves a download and the node fetches it directly.
• Turning a machine off for game hosting moves nothing. Servers already on it keep running; the machine simply stops being chosen for anything new.
• You cannot edit vendor-published catalogue entries. You approve or reject what they publish, and you own anything you import yourself.