# How to resize a Quake AI VM to a dedicated-CPU plan

Source: https://docs.quake.ai/docs/compute/how-to/resize-to-dedicated-plan
Markdown: https://docs.quake.ai/docs/compute/how-to/resize-to-dedicated-plan.md

---

# How to resize a Quake AI VM to a dedicated-CPU plan

Move a VM from a shared vCPU flavor (the Developer plan's starting point) to a dedicated vCPU flavor (Basic and custom dedicated packs). A flavor resize keeps the instance ID, boot volume, attached volumes, and disk contents. The target flavor sets the new vCPU count, RAM, and network cap.



Record the instance ID before the resize, then compare it with the ID after the resize. The matching values confirm that the Compute service resized the existing instance.



<PrerequisiteBlock methods={["console", "cli"]}>

- A running instance on a shared vCPU flavor (for example `s1a.micro`)
- Sufficient dedicated vCPU quota on the project for the target flavor
- A maintenance window that tolerates a brief restart during the resize

</PrerequisiteBlock>

## Upgrade your resource tier

Dedicated vCPU flavors draw from your project's dedicated vCPU quota. If your project is still on the Developer plan, add dedicated vCPUs, RAM, and any storage you need before you resize the instance.

Follow [Upgrade or downgrade resource tiers](/docs/account/projects#upgrade-or-downgrade-resource-tiers) to add dedicated vCPUs to your project through the portal checkout flow. This step is billing only; it does not touch the running instance.

## Pick the target flavor

Quake AI groups dedicated flavors into three families, each tuned for a different vCPU-to-RAM ratio: [General Purpose (`m2a`)](/docs/compute/concepts/flavors) for balanced web and API workloads, [Compute Optimized (`c2a`)](/docs/compute/concepts/flavors) for CPU-bound jobs, and [Memory Optimized (`r2a`)](/docs/compute/concepts/flavors) for caches and in-memory workloads. See [Flavors](/docs/compute/concepts/flavors) for the full comparison and the specification table.

Available sizes vary by flavor family and region. List the flavors available to your project, then copy the exact target flavor name from the output:

```bash
openstack flavor list --long
```

For example, select `m2a.large` only when that exact name appears in the list. Confirm that your resource tier has enough dedicated vCPUs and RAM for the selected flavor before continuing.

## Snapshot before you resize

Take a snapshot so you have a rollback point if the new flavor misbehaves:

Follow [How to create an instance snapshot](/docs/compute/how-to/create-snapshot).

## Resize the instance

Record the instance ID and current flavor before you start, so you can confirm the resize did not rebuild the instance.

```bash
openstack server show INSTANCE_NAME -c id -c flavor
```

<MethodTabs>
<Method label="Console">

1. Open **Compute** > **Instances** and select the instance.
2. From the instance action menu, choose **Resize Instance**.
3. Select the target dedicated flavor, then submit the resize. The instance restarts during the operation.
4. When the instance reaches the resize verification state, test the workload.
5. Choose **Confirm Resize** to keep the new flavor. If the workload check fails, choose **Revert Resize** instead.

</Method>
<Method label="CLI">

```bash
openstack server resize --wait --flavor TARGET_DEDICATED_FLAVOR INSTANCE_NAME
openstack server show INSTANCE_NAME -c id -c flavor -c status
```

The server enters `VERIFY_RESIZE` when it is ready for your checks. Test the workload before accepting the new flavor.

If the workload runs correctly, confirm the resize:

```bash
openstack server resize confirm INSTANCE_NAME
```

If the workload check fails, revert the resize before confirming it:

```bash
openstack server resize revert INSTANCE_NAME
```

</Method>
</MethodTabs>

See [How to maintain a Quake AI VM over its lifetime](/docs/compute/how-to/maintain-vm#resize-or-change-flavor) for the general resize reference, including notes on volume-backed instances.

### Verify the instance was not rebuilt

```bash
openstack server show INSTANCE_NAME -c id -c flavor -c status
```

The `id` value matches the value you recorded before the resize, `flavor` shows the new dedicated flavor, and `status` is `ACTIVE`.

## Move to production networking (optional)

If the instance still runs on the `PublicEphemeral` network from the Developer-plan quickstart, its public address remains tied to the instance. Deleting the instance releases that address.

The resize leaves the network configuration unchanged. For a private network behind a router and a floating IP that persists independently of the instance, follow [How to create a VM on a private network](/docs/compute/how-to/create-vm-private-network) and [How to allocate floating IP addresses](/docs/network/how-to/allocate-floating-ips).

## Related documentation

- [Resource tiers](/docs/account/resource-tiers): Developer, OpenClaw Starter, and Basic specifications and when to upgrade
- [Manage cloud projects](/docs/account/projects#upgrade-or-downgrade-resource-tiers): changing a project's resource tier in the portal
- [Flavors](/docs/compute/concepts/flavors): flavor families and how to choose one
- [How to maintain a Quake AI VM over its lifetime](/docs/compute/how-to/maintain-vm): the general resize, storage, and decommission reference
- [How to create an instance snapshot](/docs/compute/how-to/create-snapshot): rollback point before a production resize
- [How to create a VM on a private network](/docs/compute/how-to/create-vm-private-network): the production networking pattern
- [How to allocate floating IP addresses](/docs/network/how-to/allocate-floating-ips): a public IP that persists independently of the instance