Upgrade (move to a larger size)
- Instance detail page → Resize → pick the new size.
- Suji reboots the VM into the larger shape (~30–90 s of downtime), confirms.
- The new hourly rate kicks in immediately for that VM, charged from your credit balance.
Downgrade (move to a smaller size)
- Instance detail page → Resize → pick the smaller size.
- Disk-size constraint: the new size’s disk must be ≥ the data currently used. Disks can’t shrink below the data on them.
- If your data exceeds the smaller size’s disk: snapshot → restore into a fresh smaller VM → destroy the old one. The dashboard surfaces this as the next step.
- Suji reboots into the smaller shape, confirms.
- The new lower hourly rate kicks in immediately.
Examples
You have: one Large VM running 24/7. You want: to cut your bill by running only during business hours. ⚠️ Stop / Start doesn’t save you money. The cloud provider keeps the disk and IP reserved while a VM is stopped, so we still bill the full hourly rate. To genuinely pay less you have to either downsize, or destroy the VM and restore from a snapshot in the morning (~3–5 minute round-trip, plus a small snapshot-storage charge). A managed-schedule feature is on the roadmap. You have: a Small VM, traffic doubled, apps are getting OOM’d. You want: more headroom without overpaying. Resize to Medium. The new €0.0274/hour rate kicks in. Apps don’t lose state — they restart inside the larger shape. You have: a Medium VM, sized it generously for a one-time migration, migration is done. You want: to go back down. Resize to Small. As long as your data fits in Small’s 40 GB disk, it just works.What about “downgrading the plan”?
That concept doesn’t exist on Suji — there’s no plan to downgrade. You only have VMs, each with its own size. Smaller bill = smaller / fewer / destroyed VMs.Next
Resize details
Operational steps + edge cases.
VM pricing
Per-size hourly rates.