VM tiers & scaling
Five shared/burstable tiers — micro (0.25 vCPU / 0.25 GB) → large (4 vCPU / 8 GB). scale_vm resizes in place with no rebuild; list_vms suggests a right-size. Exact specs + rates come from the pricing tool.
Superjolt has five VM tiers. All are shared / burstable vCPU — the vCPU figure is your guaranteed share under contention, and a VM can burst above it when the host is idle. For exact specs and current per-second rates, ask the pricing tool or hit GET /v1/pricing; see Pricing for the model.
The five tiers
| Tier | vCPU | RAM | Fits |
|---|---|---|---|
| micro | 0.25 | 0.25 GB | Idle glue: a webhook receiver, a cron shim, a single always-on daemon. 256 MB OOMs build steps — opt in deliberately |
| tiny | 0.5 | 0.5 GB | Cron jobs, a bot, a tiny static site, a low-traffic API |
| small | 1 | 1 GB | A typical Node/Python web app, a side project, a small Postgres/Redis |
| medium | 2 | 4 GB | A build-step app (Next.js), a busy database, a VS Code dev box (the floor for that image) |
| large | 4 | 8 GB | Heavier workloads, larger datasets, a build server, parallel work |
The default tier is tiny when create_vm is called without a size; micro is the opt-in floor.
Size up vs size out
- Up (bigger tier) — one process that needs more CPU/RAM: a database, a build, an in-memory cache. Use
scale_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.
Live scaling
bump vm-abc123 to medium
scale_vm resizes a running VM in place — no rebuild, no new VM, no IP change. Scale down the same way when load drops.
list_vms reports each VM’s CPU/RAM usage and a right-size recommendation so you (or your agent) can spot an over- or under-provisioned VM. get_vm_metrics gives the detailed time series.
Dev boxes are the exception: don’t downsize a
vscode-1.96VM on idle stats —mediumis the working floor, because installs, builds, and language servers burst well above idle.