Flavors
Coming from another cloud?
▸AWS·Instance Types
Instance Types
- Fixed predefined configurations only; no custom flavor creation.
- Extensive families for GPU/HPC/ARM etc.
- InstanceType as string param in API, not ID reference.
- Tied to specific hardware generations (Nitro/Xen).
▸Azure·VM sizes
VM sizes
- Predefined hardware-optimized series (e.g., D-family general purpose) with complex naming (e.g., Standard_D4as_v5), not user-defined vCPU/RAM like OpenStack flavors.
- Sizes listed via API /providers/Microsoft.Compute/locations/{location}/vmSizes, region-specific availability.
- Includes accelerator features (GPU, FPGA) baked into sizes, unavailable in basic OpenStack flavors without extensions.
- Cannot create custom sizes; selection from catalog, limiting flexibility vs OpenStack flavor creation.
▸DigitalOcean·Droplet sizes (plans)
Droplet sizes (plans)
- A Droplet must select a predefined “size” bundle (RAM/vCPU/disk/transfer) rather than choosing from an OpenStack flavor catalog that many clouds let you customize/extend at the project level.
- The size object exposes explicit monthly pricing (price_monthly) and per-hour pricing (price_hourly) in the API response, whereas OpenStack clouds typically separate pricing from the Nova flavor definition.
- DigitalOcean sizes embed transfer allowance and region availability directly in the size metadata, while OpenStack flavors generally describe compute resources and rely on separate networking/quotas/policies for bandwidth and availability.
- DigitalOcean size classes are described in the API as categories like Basic, General Purpose, CPU-Optimized, Memory-Optimized, and Storage-Optimized rather than OpenStack’s provider-defined flavor naming/extra-specs approach.
▸Google Cloud·Machine types
Machine types
- Organized by families/series (e.g. N2 general-purpose); OpenStack flavors flat list.
- Custom types +5% premium for N/E series; no such billing in OpenStack.
- Naming 'n2-standard-4'; shared-core bursting types absent in OpenStack.
▸Hetzner·Server Types
Server Types
- Fixed predefined types (e.g. CX11, CPX31) with shared_vcpu (noisy neighbors) vs dedicated_vcpu.
- GET /v1/server_types lists all; no custom flavor creation like OpenStack.
- Includes pricing (hourly/monthly net/gross), included_traffic, architecture (x86/amd64/arm).
- Resize via change_type action, but limited to compatible types.
Flavors
Flavors define the resource shape of an instance: vCPU count, memory, root disk size, and optional ephemeral or swap storage. The Compute service (OpenStack Nova) exposes flavors as named resource profiles. You choose a flavor when you create or resize an instance, and the platform allocates those resources on the compute node that hosts it.
What a flavor specifies#
Each flavor is a named combination of five resource dimensions. vCPUs set the number of virtual CPU cores available to the instance. RAM determines how much memory the operating system and applications can use. The root disk provides the primary storage where the OS and system files live. Some flavors include an ephemeral disk: temporary local storage that disappears when the instance is deleted, useful for scratch data or caches. A swap disk may also be present as overflow virtual memory when physical RAM is fully utilized.
Flavors are predefined by cloud administrators. You cannot create custom flavors, but the existing set covers many workloads.
Flavor categories on Quake AI#
Quake AI organizes flavors into four categories:
- General Purpose: balanced vCPU-to-memory ratio for web servers, small databases, and development environments.
- Compute Optimized: higher vCPU count relative to memory for batch processing, CI/CD runners, and CPU-bound applications.
- Memory Optimized: more RAM per vCPU for in-memory caches, analytics engines, and large databases.
- Shared Resources: shared vCPUs for lightweight workloads, testing, and personal projects.
See List of flavors for the full specification table.
How to choose#
Start with the workload's requirements. A web application serving moderate traffic fits General Purpose. A build server compiling large projects benefits from Compute Optimized. A Redis cache or data warehouse query engine needs Memory Optimized. A personal blog or staging environment can run on Shared Resources at the lowest cost.
If you outgrow a flavor, you can resize the instance to a larger one, though resizing requires a brief restart. Choosing slightly above your baseline avoids frequent resizes while keeping costs in line with your plan tier. See How to resize a Quake AI VM to a dedicated-CPU plan for the shared-to-dedicated walkthrough.
Further reading#
On this platform:
- Instances: how flavors define the resource shape of each VM
- Flavors console: specification table for available flavors
- Flavors CLI reference:
openstack flavorcommands - Flavors API reference: API endpoints for listing and inspecting flavors
External resources:
- OpenStack Nova flavors documentation: upstream reference for flavor definitions and extra specs
Quick answers
- Why does `openstack image save` write a 0-byte file for my boot-from-volume instance?CLI
- Why does `openstack server create` fail with "Only volume-backed servers are allowed for flavors with zero disk"?CLIAPITerraform
- Why does my project still have a 10 GiB Cinder volume after I deleted my instance?CLIAPI
Related content
Pages
How-tos
Explanations
Reference
migration
Compute migration guides
Compute
Migrate from AWS EC2 to Quake AI compute
Compute
Migrate from Azure Virtual Machines to Quake AI Compute
Compute
Migrate from DigitalOcean Droplets to Quake AI Compute
Compute
Migrate from GCP Compute Engine to Quake AI compute
Compute
Migrate from Hetzner Cloud Servers to Quake AI Compute
Compute
Migrate from Linode compute instances to Quake AI compute
Compute
Migrate from Vultr to Quake AI compute
Compute