Skip to main content
You can change the size of a running VM without re-provisioning. From the instance detail page → Resize:
  1. Pick the new size (Small / Medium / Large / XL).
  2. Confirm.
  3. The VM reboots into the new shape. Downtime: typically 30–90 seconds.

​
What changes

ResourceUpDown
vCPU✅ Reboots into more cores✅ Reboots into fewer cores
RAM✅ Reboots with more RAM✅ Reboots with less RAM
Storage✅ Disk expands, filesystem auto-grows❌ Not supported — cloud provider doesn’t allow disk shrink
The resize-down case for storage is the only hard restriction. If you need a smaller disk, snapshot → restore into a fresh smaller VM → destroy the old.

​
Before you resize

Resize doesn’t take a snapshot for you. If you want a rollback point, take a manual snapshot first — then you can restore in one click if anything goes wrong (very rare).

​
Billing during resize

  • The reboot itself is billed at the new rate as soon as the resize commits.
  • Hourly billing is pro-rated to the minute.

​
When to resize

  • Up: you’re seeing OOM kills in dmesg, CPU sitting at 100%, or response times creeping up under load.
  • Down: idle CPU for weeks, RAM usage well below the size’s cap, and storage isn’t the bottleneck.
The dashboard’s Metrics tab (CPU / memory / network / disk over time) helps you decide.

​
Edge cases

Resize up if you need more storage. Resize-down for storage is unsupported.
No — resize is a reboot, not a rebuild. Volumes, containers, system config all persist.
A failed resize degrades to “still on the old plan, still up” — the VM is best-effort restarted on its previous size. If you took a manual snapshot first, you can restore from it in one click.
Not yet — resizes run immediately. Plan your maintenance window manually.

​
Next

Snapshots

The safety net behind resizes.

Billing & credits

How resize affects your hourly rate.