VM sizing

You choose the size — create_vm takes vcpuMillicores + memMib, and resize_vm changes both live with no reboot and no IP change. Billing meters exactly the allocation you chose. A per-image floor sets the minimum; your account's per-VM cap sets the maximum (requests above it are clamped). Exact rates come from the pricing tool.

You pick the size. create_vm takes a vcpuMillicores and a memMib, and you can change both at any time with resize_vm — live, with no reboot and no IP change. Nothing resizes a VM on its own: the allocation stays exactly where you put it until you move it. Billing meters that allocation, per second. vCPU is shared / burstable — your allocation is the guaranteed share you get under contention, and a VM can burst above it when the host is idle.

For unit rates and worked-example prices, ask the pricing tool or hit GET /v1/pricing; see Pricing for the model.

Choosing a size at create

Sizes are continuous, not a menu — vcpuMillicores is thousandths of a vCPU (1000 = 1 vCPU), and memMib is mebibytes.

create_vm({ name: "api", image: "nodejs-24", vcpuMillicores: 1000, memMib: 2048 })

Omit them and the VM seeds at 0.5 vCPU / 512 MiB — enough for a small service, and easy to raise the moment you need to. Some starting points:

You are not locked in. Start small, watch it with get_vm_metrics, and resize.

Resizing, live

resize_vm names the size it wants, whole — both vcpuMillicores and memMib are required, so you always know what you ended up with:

resize_vm({ id: "vm-abc123", vcpuMillicores: 4000, memMib: 8192 })

CPU and memory both change in place: no reboot, no downtime, no broken connections, no IP change, no agent retries. The next metering tick simply prices the new allocation.

list_vms reports each VM’s current CPU/memory allocation, its run-rate (“trending ~$X/mo”), and month-to-date spend. get_vm_metrics gives the detailed time series — that’s how you tell whether you sized it right.

Floors and caps

Three bounds apply to any size you ask for:

• A per-image floor. Every image has a minimum that lets it actually boot. The platform floor is 0.25 vCPU / 256 MiB; some images set their own, higher (a vscode-* image floors at 1 vCPU / 4 GiB — VS Code Server unpacks, indexes the workspace, and runs language servers, and it OOMs below that). Asking for less than the floor is refused — it would boot a VM that immediately dies.
• Your account’s per-VM cap. Each account has a ceiling on how large any single VM may be. Asking for more than the cap is clamped, not refused — you get the most you’re allowed. account_status shows yours.
• The platform ceiling — 8 vCPU / 16 GiB for a single VM. Beyond that, size out.

Size up vs size out

• Up — one process that needs more CPU/RAM: a database, a build, an in-memory cache. Call resize_vm.
• Out (more VMs) — independent units of work: a worker fleet, or splitting a database off its app onto a sibling VM in the same project network. Call create_vm again.

Disk

Disk is separate from CPU/memory and is not separately billed. A new VM’s rootfs defaults to 4 GiB; ask for more at create with create_vm({ diskGib }), up to your account’s per-VM disk cap. For large or long-lived storage that should outlive the VM, attach a volume.

Stopping costs nothing

stop_vm releases the VM’s CPU, memory, and IP entirely and archives its disk — a stopped VM bills nothing. start_vm restores it. So the cheapest size for a VM you aren’t using is “stopped”. See Pricing.