Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.suji.fr/llms.txt

Use this file to discover all available pages before exploring further.

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.

​
Auto-snapshot

Suji takes a snapshot before every resize automatically. If anything goes wrong (very rare) you can restore in one click. The auto-snapshot has a 30-day retention.

​
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.
The auto-snapshot has you covered. The dashboard will offer a one-click restore.
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.