> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.ibee.co.in/docs/infrastructure/cloud-vms/resize-a-vm/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.ibee.co.in/_mcp/server.

# Resize a VM

> Move a Cloud VM to a different plan — upgrade CPU, RAM, and disk, or downgrade CPU and RAM — without rebuilding.

You can move a Cloud VM to a different plan from **Settings → Change Plan**. The VM is briefly stopped, resources are changed in place, and it restarts on the new plan. Upgrades can grow CPU, RAM, and disk; downgrades can reduce CPU and RAM but never shrink the disk.

> **Info**
>
> **Settings tab availability.** **Change Plan**, **IPv4 & Reserved IP**, **VPC Networks**, and **Access** are available. **Change OS** and **Hostname** show "This section is under development" — changing the OS or hostname of an existing VM isn't available in the portal yet. Set the hostname inside the guest, or deploy a new VM with the OS you need.

## When to resize

* CPU sustained near 100% over the **24h** range in [Monitoring](/docs/infrastructure/cloud-vms/monitoring).
* Memory pressure: high used / total ratio with no free RAM.
* Disk full on the root volume and you don't want to attach a separate [Block Storage](/docs/infrastructure/block-storage) volume.
* The VM is consistently over-provisioned and a smaller CPU/RAM plan would do.

If only data is growing, attaching a block storage volume is usually a better fit than resizing the whole plan.

## Before you begin

* You need write access to the workspace — read-only members see the current plan but not **Change Plan**.
* The dropdown lists the other plans available in the VM's region.
* Root disks can't shrink. A plan with a smaller disk than the VM's current disk is blocked.

## Steps

### 1. Open Settings

On the VM detail page, open the **Settings** tab. **Change Plan** is selected by default.

### 2. Review your current plan

The **Current Plan** card shows your existing vCPU, RAM, and disk.

### 3. Pick a plan

Open the **Available Upgrades** dropdown and select a plan. Each entry shows the plan name and its vCPU, RAM, and disk. The count above the dropdown tells you how many plans are available for the region.

After selection, a **Selected Plan** summary confirms the new specs, and a **Billing term** selector lets you choose the term for the new plan (the options depend on the plan).

### 4. Confirm the change

What you see next depends on the target plan:

| Target plan                          | What the portal shows                                                                                                                                      | Button             |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
| Larger CPU, RAM, or disk             | **Upgrade Process** — the server is briefly stopped, CPU, RAM, and disk are upgraded, it restarts automatically, and billing moves to the new rate.        | **Upgrade Plan**   |
| Less CPU or RAM, same or larger disk | **Downgrade Process** — the server is stopped, CPU and RAM are adjusted, the disk stays at its current size, the server restarts, and billing is adjusted. | **Downgrade Plan** |
| Smaller disk                         | **Downgrade Not Possible** — disk shrinking isn't supported because it risks data loss.                                                                    | —                  |

Click **Upgrade Plan** or **Downgrade Plan**. The portal shows **Verifying…** while it checks the resize. If the resize can't be done in place, a **Resize not possible** message lists the reasons.

### 5. Confirm the resize

In the **Confirm Resize** dialog, review the current and target vCPU, RAM, and disk, plus the **Downtime notice**, then click **Confirm Resize**:

* A running VM is stopped, resized, and started automatically.
* A stopped VM is resized without being started.

## What changes

| Resource                | Behavior                                                                                                                                                                       |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **vCPU / RAM**          | Updated during the brief stop.                                                                                                                                                 |
| **Root disk**           | Grows to the new plan's size on an upgrade; stays the same on a CPU/RAM downgrade. You may need to extend the filesystem inside the guest if it doesn't auto-grow (see below). |
| **Public IP**           | Preserved.                                                                                                                                                                     |
| **Attached volumes**    | Preserved and remain attached.                                                                                                                                                 |
| **Snapshots / backups** | Preserved.                                                                                                                                                                     |
| **Hostname / SSH keys** | Preserved.                                                                                                                                                                     |

## Extend the root filesystem (Linux)

Most cloud images use `cloud-initramfs-growroot` and resize automatically on boot. If `df -h /` still shows the old size after resize, run:

```bash
# Identify the root device
lsblk

# Grow the partition (adjust device/partition number)
sudo growpart /dev/vda 1

# Extend the filesystem
sudo resize2fs /dev/vda1     # ext4
sudo xfs_growfs /            # XFS
```

Reboot if any tool reports the partition is busy.

## Downgrade

You can downgrade CPU and RAM in place with **Downgrade Plan**, as long as the target plan's disk is at least as large as the current disk. To move to a plan with a **smaller disk**:

1. Deploy a new VM on the smaller plan ([Create a VM](/docs/infrastructure/cloud-vms/create-a-vm)).
2. Migrate your data to the new VM.
3. Cut DNS over to the new VM and delete the old one when verified.

## Troubleshooting

**No alternative plans available for this region**
The VM's region has no other plan to move to. Check [Regions and locations](/docs/getting-started/overview/regions-and-locations) for plan availability.

**Resize not possible**
The pre-check found a blocker and lists the reasons under the dropdown. Resolve them, or pick a different plan.

**Resize stuck**
Open the [Activity feed](/docs/infrastructure/cloud-vms/monitoring#activity-feed). A failed resize will surface as `Operation Failed` with a message.

**Disk space didn't grow**
Run the `growpart` / `resize2fs` commands above. Some images don't auto-extend on resize.

## Related pages

* [Instance types](/docs/infrastructure/cloud-vms/instance-types)
* [Power actions](/docs/infrastructure/cloud-vms/power-actions)
* [Block Storage](/docs/infrastructure/block-storage)
* [Snapshots](/docs/tools/snapshots)

> Move a Cloud VM to a different plan — upgrade CPU, RAM, and disk, or downgrade CPU and RAM — without rebuilding.