Regions and node groups
Regions
A region is a location. Servers keep their IP addresses when they move between nodes in the same region. Add them on the Regions page, under Fleet in the sidebar, with Add region. A fresh install has none. The page shows how many node groups, nodes and IP pools each region has. Staff who can manage nodes or platform settings can change regions.
| Field | Rules |
|---|---|
| Code | 2–16 characters, lowercase, starting with a letter, e.g. ams1. Can’t change once saved. |
| City | 1–60 characters. Customers see this, never node names. |
| Country | Two-letter ISO code, e.g. NL |
A region can’t be removed while it still has nodes, node groups, IP pools or waiting enrollments.
Node groups
Every node belongs to at most one node group, and packages are sold in node groups. The group’s placement rule picks the node for each new server. Nodes outside a group never receive new servers.
| Field | Notes | Default |
|---|---|---|
| Name | 2–48 characters, unique | |
| Description | Staff only, up to 240 characters | |
| Region | Its nodes must be in this region | |
| Visibility | Public: offered as a location at order time and through the billing module. Private: hidden from customers; staff and API tokens can still place servers there. | Public |
| Accepting servers | When off, no new servers are placed. Staff can still create servers there, with a warning; billing and resellers can’t. | On |
| Placement rule | See below | Most free memory |
| Memory limit | Allocation can’t pass this share of schedulable memory, 50–100% | 90% |
| Disk limit | Storage pools can’t fill past this, 50–100% | 90% |
| CPU load limit | Nodes with live CPU load above this are skipped, 50–100% | 85% |
Placement rules
| Rule | How it picks |
|---|---|
| Most free memory | Spreads servers so every node keeps headroom. A good default. |
| Most free disk | For storage-heavy plans, or when disk runs out before memory. |
| Lowest CPU load | Uses live load, so busy nodes are avoided. |
| Fewest servers | Evens out server counts, whatever the plan size. |
| Longest since last server | Takes turns by time, so a burst of orders spreads out. |
| Round robin | Strict rotation through the nodes in name order. |
| Fill in order | Packs each node to its limits before using the next, keeping spares empty. |
| Random | Any node with room, picked at random. |
Which nodes can take a server
A node is skipped, in this order, when:
- it’s offline, draining or in maintenance
- it has reached its server limit
- it doesn’t have enough free vCPUs
- the server would push allocated memory past the group’s memory limit
- it has no enabled storage pool of the package’s tier with room under the disk limit
- its live CPU load is above the group’s CPU limit
Allocation is measured against schedulable capacity, which applies each node’s overcommit ratios and the memory reserved for the host (see Nodes).
Where new servers would go
On a group page, the Where new servers would go card runs the rule as a dry run for any package, 1 to 20 servers at a time, including with unsaved changes. The CPU-load simulation assumes each new server keeps about a third of its vCPUs busy.
Room for new servers
The fleet overview ends with Room for new servers, one row per node group: memory, disk and IPv4 left within the group’s limits (counting only online nodes that aren’t in maintenance), how many more of the group’s typical package fit, and which of memory, disk, vCPUs or IPv4 runs out first. At the last 30 days’ pace it says roughly when that happens: amber at 30 days or less, red under 14 days.
A group of GPU container hosts is counted in its own terms: cards (switched on for containers, and how many instances have), the memory and /workspace space instances are given, forwarded ports (when an offer there uses them) or IPv4, and how many more instances fit of the offer most of its instances use (or the first offer selling it). When none fit, it says why, the same reason the Offers page shows.
A group that still has nodes can’t be deleted. Deleting a group also removes it from every package’s locations.