Compute migration guides
Coming from another cloud?
▸AWS·EC2 Instances
EC2 Instances
- Uses EC2 RunInstances API instead of Nova servers.create.
- Requires predefined instance type selection.
- Supports per-second On-Demand billing and Spot/Reserved options.
- Includes hibernation state not standard in OpenStack.
▸Azure·Virtual Machines
Virtual Machines
- Uses Azure Resource Manager (ARM) REST API at /providers/Microsoft.Compute/virtualMachines instead of OpenStack Nova API at /v2.1/servers.
- Tightly integrated with Azure services like Azure Active Directory for authentication, unlike OpenStack's Keystone.
- VM creation requires specifying size from predefined series with hardware-specific features (e.g., AMD/Intel/ARM), not custom flavor configs.
- Billed per second with complex pricing tiers based on series/reservation options, vs OpenStack's typically hourly or usage-based.
▸DigitalOcean·Droplets
Droplets
- API surface is DigitalOcean’s proprietary REST/CLI/Terraform tooling rather than OpenStack Nova/Neutron/Glance APIs (Droplets are managed via DigitalOcean UI/CLI/API/Terraform).
- Billing is usage-based with per-second billing (60-second minimum and monthly cap) rather than the typical per-hour, quota-based charge model users often see in OpenStack-based clouds.
- Droplets include a bundled outbound transfer allowance with each plan (starting at 500 GiB/month) rather than a separate bandwidth quota/metering model users often encounter in OpenStack deployments.
- Droplets are described as Linux-based VMs on virtualized hardware with local SSD storage, whereas OpenStack deployments commonly expose distinct block storage (Cinder) and image services (Glance) and may not bundle bandwidth/monitoring/firewalls into the instance offering.
▸Google Cloud·VM instances
VM instances
- Uses REST API 'instances.insert' instead of Nova 'servers.create' with different auth via service accounts vs Keystone.
- Supports bare metal instances (no hypervisor), not in standard OpenStack Nova.
- Network interfaces tied to VPC subnets; differs from Neutron ports/floating IPs.
▸Hetzner·Cloud Servers
Cloud Servers
- Servers provisioned individually via Hetzner API (hcloud), not OpenStack Nova flavors; fixed instance types like CX11 (1 vCPU, 2GB RAM, 20GB NVMe).
- No flavor customization; choose from predefined shared/dedicated vCPU series.
- Billing hourly with monthly cap per server (e.g., €3.29/mo cap for CX11), charged even when powered off until deleted, unlike typical OpenStack stop-to-pause billing.
- Custom REST API at api.hetzner.cloud/v1/servers instead of OpenStack Nova /v2.1/servers (different auth, payloads, response formats).
▸Linode·s (Compute Instances)
Linodes (Compute Instances)
- Provisioned via the Linode API v4 (/v4/linode/instances) instead of OpenStack Nova /v2.1/servers; auth is a Personal Access Token rather than a Keystone token.
- Plan selection is fixed (Shared, Dedicated, High Memory, Premium, GPU, Accelerated) with predefined vCPU/RAM/storage; OpenStack flavors can be cloud-defined.
- Billing is hourly with a monthly cap per plan; powered-off Linodes continue to bill until deleted, unlike pause/suspend semantics common in OpenStack stop-billing setups.
- Distribution images and StackScripts are first-class; OpenStack uses Glance images and arbitrary userdata.
▸Vultr·Cloud Compute / Bare Metal Instances
Cloud Compute / Bare Metal Instances
- Provisioned via the Vultr API v2 (/v2/instances and /v2/bare-metals) instead of OpenStack Nova /v2.1/servers; auth is a Personal Access Token rather than a Keystone token.
- Plan selection is fixed (Regular Performance, High Performance, High Frequency, CPU Optimized, Memory Optimized, Bare Metal) with predefined vCPU/RAM/storage; OpenStack flavors can be cloud-defined.
- Billing is hourly with a monthly cap per plan; powered-off Vultr instances continue to bill until destroyed, unlike pause/suspend semantics common in OpenStack stop-billing setups.
- Marketplace one-click apps and ISO library are first-class; OpenStack uses Glance images and arbitrary userdata.
Compute migration guides
You move virtual machines and compute workloads to Quake AI from another provider. Major cloud providers do not offer one-click VM migration to OpenStack, so you use rebuild and rsync: you provision a fresh Nova instance from a standard image, install your application stack, and transfer data.
For containerized workloads, you push container images to a portable registry, provision Nova instances, and deploy.
Choose your source provider#
Migrate from AWS EC2
Image export via VM Import/Export, full flavor mapping from M6i/C6i/R6i/T3 to Quake AI families, and rsync-based data transfer.
Migrate a Docker container app from AWS
Move ECS, Fargate, or EC2+Docker workloads to Quake AI. ECS concept translation, image export from ECR, and Docker Compose deployment.
Migrate from DigitalOcean Droplets
Rebuild and rsync from Droplets to Nova instances. Clean flavor mapping from Basic/General/CPU-Optimized plans.
Migrate from Hetzner Cloud Servers
Rebuild and rsync from CX/CPX/CCX servers. Closest operational model to Quake AI of any provider.
Migrate from GCP Compute Engine
QCOW2 image export via Cloud Build (no manual qemu-img step), full flavor mapping from N2/E2/C2 machine types.
Migrate from Azure Virtual Machines
VHD export via SAS URL, full flavor mapping from D-series/E-series/F-series/B-series VM sizes.
Migrate from Linode Compute Instances
Rebuild and rsync from Linodes (Akamai Cloud Computing). Plan-family mapping from Shared CPU, Dedicated CPU, High Memory, and Premium to Quake AI flavors.
Migrate from Vultr Cloud Compute
Rebuild and rsync from Vultr Cloud Compute and Bare Metal. Plan-family mapping from Regular Cloud Compute, High Frequency, High Performance, CPU Optimized, and Optimized Cloud Compute to Quake AI flavors.
Migration approaches#
You typically choose one of three approaches, depending on your workload type.
Containerized workloads (recommended)#
You push container images from any source registry (ECR, GCR, ACR, Docker Hub) to a portable registry. You provision Nova instances on Quake AI, install your container runtime, and deploy. This path stays the same no matter which provider you leave.
Non-containerized workloads (rebuild and rsync)#
You provision a fresh Nova instance from a Quake AI public image (Ubuntu, Debian, Rocky Linux). You install your application stack with your existing configuration management tooling (Ansible, cloud-init, shell scripts). You transfer application data and databases with rsync or standard dump/restore tools.
Image export (special cases only)#
AWS, GCP, and Azure support exporting VM images. GCP exports disk images to QCOW2, OpenStack Glance's preferred format, through the Cloud Build pipeline, so you do not run a manual qemu-img conversion step. AWS and Azure require a manual qemu-img conversion step after download. DigitalOcean and Hetzner do not support image export. Use image export only for custom images with many manual changes that are difficult to rebuild.
Quake AI flavor families#
Quake AI offers four flavor families. Use this reference to pick the right target size for your workload.
| Family | Naming | RAM per vCPU | Use case |
|---|---|---|---|
| General Purpose | m2a.{size} | 4 GiB | Balanced workloads, web servers, application servers |
| Compute Optimized | c2a.{size} | 2 GiB | CPU-bound workloads, CI/CD, batch processing |
| Memory Optimized | r2a.{size} | 8 GiB | Databases, caching, in-memory analytics |
| Shared Resources | s1a.{size} | 1-2 GiB | Dev/test, low-traffic services, personal projects |
Each per-provider guide includes a detailed flavor mapping table with at least 8 common sizes.
What transfers and what does not#
| Component | Portable? | Notes |
|---|---|---|
| Application data (files, configs) | Yes | rsync over SSH from source to Quake AI |
| Databases (PostgreSQL, MySQL) | Yes | Standard pg_dump / mysqldump and restore |
| Container images | Yes | Push to any OCI-compatible registry; pull on Quake AI with your existing runtime |
| SSH public keys | Yes | Import via openstack keypair create --public-key |
| cloud-init configs | Partial | Remove provider-specific datasource references |
| VM images | Varies | GCP exports QCOW2 via Cloud Build (no manual qemu-img step); AWS/Azure require qemu-img conversion; DO/Hetzner do not support image export |
| IAM credentials | No | Replace with OpenStack application credentials |
| Provider-specific metadata | No | Instance metadata paths differ between providers |
See also#
- Migrate to Quake AI: cross-service migration hub
- Kubernetes migration guides: migrate GKE, EKS, and AKS clusters
- Create an instance: provision your first Nova instance
- Flavors: detailed flavor specifications
- Object storage migration: if you also need to move storage
Usage Guidelines
The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.
Comparisons to third-party providers in this material reflect publicly documented behavior as of the validation date below. Pricing, quotas, service limits, and feature availability change frequently on every cloud. Verify provider-specific claims against the provider's own current documentation before relying on them for a procurement, architecture, or migration decision.
For the full policy, see Usage Guidelines.
Last validated: 22.06.2026
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
See Also
Migrate from Azure Virtual Machines to Quake AI Compute
Shares: Flavors, Images
Migrate from DigitalOcean Droplets to Quake AI Compute
Shares: Flavors, Images
Migrate from AWS EC2 to Quake AI compute
Shares: Flavors, Images
Migrate from GCP Compute Engine to Quake AI compute
Shares: Flavors, Images
Migrate from Hetzner Cloud Servers to Quake AI Compute
Shares: Flavors, Images