VPS Plans

A plan is the size of virtual machine a product sells, and the shape the platform actually builds. It carries the cores, memory, disks and addresses, the operating systems a customer may choose, an optional script to run inside the guest at first boot, the resource ceilings, and the rule about which of your machines may host it. Nothing can be ordered until a product has one.

There is no VPS Plans page

A VPS plan is edited from the product that sells it, and nowhere else. The module's tab strip has no Plans tab, and an old link to one lands on Products. If you are looking for a list of plans, you are looking for your list of VPS products.

How to reach the plan editor

Open Products, edit (or create) a product whose category is a VPS category, and open the Configuration section. A VPS Configuration block appears there with the plan summary and a button that opens the plan editor.

The plan takes the product's own name, so the editor has no separate name box — the product's Name on the General section is the plan's name too.

Note: every VPS product owns its plan. If you point a product at a plan that belongs to another product, or at one several products already sell, saving creates a copy owned by this product and re-points this product at the copy. The other products keep selling the original, unchanged. The form tells you before you type, not after you save.

The plan fields

Size

Resources a plan sells

Field	What it does
vCPUs	Virtual cores given to the machine. Minimum 1.
Memory (MB)	Memory in megabytes. Minimum 128.
IP addresses	How many addresses are taken from IPAM when a machine is built from this plan. 0 allocates none.
Disks	One row per disk. Each row has a size in GB, an optional storage type and an optional pool name. Add disk adds another row. Leaving type and pool blank lets each node use its own default pool, which is what almost every plan should do.

Warning: naming a storage pool on a plan means only nodes that offer a pool with that exact name can host it. Pool names are per node. Prefer leaving the pool blank and pinning pools on each node instead — see Clusters.

Resource limits

Ceilings are applied when a machine is built: they are sent to the hypervisor as soon as the machine exists. They are not re-applied to machines that already exist, and a machine whose ceilings were tuned by hand is never overwritten — change those on that machine's own Settings section.

Ceilings a plan can set, and the units the field uses

Field	What it does
CPU ceiling (%)	The share of the machine's total vCPU time it may use. 100 on a 2-vCPU plan is both cores flat out. Blank means no ceiling.
Inbound (Mbit/s)	Rate ceiling on traffic into the machine.
Outbound (Mbit/s)	Rate ceiling on traffic out of the machine.
Disk read IOPS / Disk write IOPS	Operations per second on the machine's disks.
Disk read throughput (bytes/s) / Disk write throughput (bytes/s)	Disk transfer ceilings. The field is in bytes per second, not bits — 100 MB/s is 104857600.
Snapshots per VPS	Enforced by the platform rather than by the node: the panel and the client area refuse to go past it. Blank inherits the module default; 0 means no snapshots on this plan.

Bandwidth

Two fields sit under an explicit warning that they are informational only: they are recorded and displayed beside the measured traffic, and nothing throttles, suspends or bills on them.

• Bandwidth (Mbps) — the port speed you advertise for the plan.
• Monthly transfer (GB) — the transfer allowance you advertise.

Warning: do not sell either of these as a cap. If you need a real limit on throughput, use the Inbound and Outbound ceilings above, which are enforced on the machine. There is no enforcement at all for a monthly transfer allowance.

Units used elsewhere in the panel

Two different units are in play, and the panel is careful to keep them apart. Read the suffix, not the number:

• Network rates are bits per second, shown as bps, Kbps, Mbps or Gbps on machine cards, node cards and every network chart. These match the units on the plan's inbound and outbound fields.
• Disk throughput is bytes per second, shown as MB/s and similar. These match the plan's disk throughput fields.
• Traffic totals (the monthly figures on a machine, a node and the dashboard) are volumes in bytes, shown as GB or TB.

Operating systems this plan offers

Tick the installers a customer may pick on this plan and mark one as the default. Nothing ticked means the plan offers every image that is enabled for virtual machines — which is what a plan you never configure does.

The images themselves come from the platform's own catalogue and are enabled for VPS use under OS Images, where each one needs a source image address before it can be offered. If no image is enabled for virtual machines yet, the plan editor says so.

If an image this plan references is later disabled or removed, the editor lists it under Images this plan still references that are no longer deployable and blocks saving until you remove it — with a Remove button per image and a Remove all button. Saving is also blocked while the image catalogue cannot be read, rather than risking a half-written plan.

Install recipe

A recipe is a script run inside the guest at first boot — after the hostname, remote access and networking are set up — and again after every reinstall. Use one to have every machine on a plan come up with your own software already installed. Without one, a plan delivers the bare operating system.

Pick one from the Install recipe dropdown, or open Manage recipes from the same row to write one. In the recipe editor:

• Slug — a permanent identifier, 3 to 120 lowercase letters, digits or hyphens. It cannot be changed after creation.
• Interpreter — the interpreter line put at the top of the script. It has to exist inside the guest.
• OS families this suits — tick the families the script works on. Ticking nothing claims it suits every image. If a plan offers a family the recipe does not cover, the plan form flags it.
• Script — the body. It runs with full privileges inside every machine built from a plan that uses it.
• Available for plans to use — untick to retire a recipe. A retired recipe is skipped at build time and starts working again if you reactivate it; plans keep their link to it.

A recipe that fails does not stop the machine coming up: it writes a log inside the guest and the boot carries on. Nothing in the panel reads that log, so test a recipe on a machine you build yourself before you attach it to a selling plan.

Recipes published with the platform are read-only here — duplicate one to get an editable copy. Deleting a recipe that plans use leaves those plans selling and provisioning with no recipe at all; retire it instead if you only want to stop new builds running it.

Targeting

Three multi-selects restrict which of your machines may host this plan: Locations, Migration pools (groups) and Clusters. Nothing selected means any.

Warning: targeting is an allowlist, and it is the most common reason an online, idle machine never receives an order. A node that is not in a targeted group — including a node in no group at all — is excluded even when it is the only machine in that location. Read the worked example in Groups, then confirm with Clusters → Capacity preview.

Availability

• Enabled — offered for new VMs — untick to stop the plan being used for anything new. Existing machines are untouched.
• Sort order — the order plans appear in.

Saving a plan that is already selling

If machines were built from the plan or other products sell it, the editor says so before you save, and asks you to confirm the specific fields you changed. Existing machines are not touched — a plan records what a machine was built from, it is not a live link, and resizing one machine is a per-machine operation. Everything ordered from that point on gets the new shape.

Deleting a plan is refused while any machine or product still references it. Detach it from those products first.

The product's own VPS settings

Beside the plan, the same Configuration section carries fields that belong to the product rather than to the plan.

Product-level VPS fields

Field	What it does
OS image	Forces one image on every order of this product. Leave it empty to let the customer pick from the plan's catalogue. If you force an image the plan does not offer, the panel warns you: an order with no operating system chosen will be refused at build time and the customer ends up paid-for and unbuilt.
Custom image URL	An escape hatch used only when nothing else resolves an image — an order-time choice, the forced image and the plan default all come first. A raw address carries no checksum: the node fetches it and writes whatever the other end answers with, and it bypasses the plan's catalogue entirely. Prefer a catalogue image.
Cluster placement	Automatic (by location + capacity) picks an active cluster with an online agent in the service's location, preferring free memory. Frozen clusters are never used. Pinned cluster always uses one named machine, and refuses the build if it is not active and online.
Cluster	Shown when placement is pinned — which machine to use.
Default location	Shown when placement is automatic. Any — from the order or the service lets the order decide.

What a customer may do to a machine — power buttons, console, reinstall, password reset and snapshots — is not set on the product. It is set once for the whole module in VPS Settings.

Per-location pricing

A premium site can cost more than a cheap one. On the product's Delivery section:

1. Under Available locations, pick the sites this product is offered in. Leave it empty to offer every active location.
2. In the Location Pricing panel, set Extra / month and Extra setup per location. Blank or zero means no surcharge.

Amounts are always per month. Other cycles are scaled automatically — annual is twelve times the monthly figure — hourly is derived from the monthly figure, and setup fees are waived on hourly. The surcharge is folded into the order amount and snapshotted onto the service, so renewals keep charging it.

On the order page the customer sees each location as a chip, cheapest first, with the surcharge shown in the price breakdown. Only locations this plan's targeting actually admits are offered.

What the customer sees

On the storefront the customer picks a plan, then an operating system (grouped by family, with versions inside each family — anything outside the selected plan's catalogue is dimmed), then a location, then optionally a hostname, then any product options. The price breakdown shows the plan price, the location surcharge and any options. See Placing an Order.

Tip: if the storefront says no operating systems are available for a product, the plan references only images that are no longer enabled for virtual machines, or none have been enabled at all. Enable one under OS Images and give it a source image address.

Where to go next

• Groups — what targeting actually matches.
• Products — the rest of the product editor.
• Virtual Machines — what a built machine looks like, and how to change one.