Migrate from Vultr to Quake AI compute

This guide covers migrating compute workloads from Vultr to Quake AI (OpenStack Nova). Vultr's snapshot tools are designed for intra-Vultr portability and do not export to a format Glance can import directly. The reliable path is rebuild and rsync. Vultr users typically provision from public images or Marketplace one-click apps with configuration management (cloud-init, Ansible, shell scripts), which makes rebuild the natural fit.

Service mapping#

Prerequisites#

• A Quake AI account with application credentials
• The OpenStack CLI installed and configured
• SSH access to your Vultr instances
• An SSH key pair imported to Quake AI (openstack keypair create --public-key)

Image portability#

Vultr supports snapshots generated from a running instance and limited to Vultr-region targets. Snapshots do not export to a format that imports cleanly into OpenStack Glance.

Recommendation: do not attempt image export. Vultr instances are typically provisioned from public Vultr images or Marketplace one-click apps with config management; rebuild is the right approach.

Plan mapping#

Vultr publishes several plan families: Regular Performance (shared vCPU, general purpose), High Performance (newer-generation shared CPU with NVMe), High Frequency (3+ GHz dedicated cores), CPU Optimized (dedicated vCPU, CPU-bound workloads), Memory Optimized (8 GiB RAM per vCPU and up), and Bare Metal. The current sizes per family are documented at Cloud Compute and Bare Metal; confirm the exact vCPU and RAM of your Vultr instance in the Customer Portal before mapping, since plan SKUs are added and renamed over time.

The Quake AI flavor families map onto the Vultr families as follows:

Pick the closest Quake AI flavor by vCPU count and RAM-per-vCPU ratio. See Flavors for the full list.

Migration approach#

Option 1: Containerized workloads (recommended)#

If your Vultr instance runs Docker containers, migrate the container images and redeploy.

1. Push images to a portable registry:

docker push registry.example.com/MY_APP:latest

1. Provision a Nova instance on Quake AI:

openstack server create \
  --image "Ubuntu-22.04" \
  --flavor m2a.xlarge \
  --network MY_NETWORK \
  --key-name MY_KEY \
  --security-group MY_SECURITY_GROUP \
  MY_INSTANCE_NAME

1. Install Docker and deploy:

ssh ubuntu@FLOATING_IP
sudo apt update && sudo apt install -y docker.io
sudo docker pull registry.example.com/MY_APP:latest
sudo docker run -d -p 80:8080 registry.example.com/MY_APP:latest

Option 2: Rebuild and rsync (non-containerized)#

1. Provision a Nova instance with the same base OS:

openstack server create \
  --image "Ubuntu-22.04" \
  --flavor m2a.xlarge \
  --network MY_NETWORK \
  --key-name MY_KEY \
  --security-group MY_SECURITY_GROUP \
  MY_INSTANCE_NAME

1. Assign a Floating IP:

openstack floating ip create PublicStatic
openstack server add floating ip MY_INSTANCE_NAME FLOATING_IP

1. Install your application stack. Replay Ansible playbooks, cloud-init configs, or provisioning scripts.

2. Transfer application data:

rsync -avz --progress -e "ssh -i ~/.ssh/MY_KEY" \
  root@VULTR_IP:/path/to/app/data \
  ubuntu@FLOATING_IP:/path/to/app/data

1. Migrate databases:

pg_dump -h VULTR_IP -U MY_USER MY_DATABASE | \
  psql -h FLOATING_IP -U MY_USER MY_DATABASE

Key pair and security setup#

Import your SSH key#

openstack keypair create --public-key ~/.ssh/id_ed25519.pub my-key

Translate Vultr Firewall Groups to security groups#

Vultr Firewall Groups attach to one or more instances and define inbound rules; outbound traffic is allowed by default with no rule surface. Neutron security groups apply per instance port and are allow-only (no explicit DROP rules), with both ingress and egress rule support. Translate your inbound rules:

openstack security group create web-tier
openstack security group rule create web-tier \
  --protocol tcp --dst-port 22 --remote-ip 0.0.0.0/0
openstack security group rule create web-tier \
  --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0
openstack security group rule create web-tier \
  --protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0

By default a fresh Neutron security group has an allow-all egress rule. Restrict egress explicitly if you want stricter control than Vultr's default-allow outbound behavior.

Block Storage migration#

If your Vultr instances have attached Block Storage volumes, provision an equally sized Cinder volume on Quake AI, attach it to the new instance, format and mount it, then rsync the data:

openstack volume create --size 100 my-data-vol
openstack server add volume MY_INSTANCE_NAME my-data-vol
# on the instance:
sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /mnt/data && sudo mount /dev/vdb /mnt/data
rsync -avz --progress -e ssh root@VULTR_IP:/mnt/data/ /mnt/data/

Validation checklist#

After migrating each workload, verify:

• Application responds correctly on the Quake AI instance
• All expected ports are accessible through the security group
• Data integrity: compare file checksums or row counts between source and destination
• Database connectivity from the application to any migrated databases
• DNS records updated to point to the new Quake AI Floating IP
• Monitoring in place (self-managed Prometheus + Grafana)
• cloud-init or configuration management runs cleanly on the new instance
• SSL/TLS certificates installed and renewed

Provider-specific gotchas#

See also#

• Migrating from Vultr to Quake AI: full cross-service migration hub
• Coming from Vultr: concept translation reference
• Create an instance: full instance provisioning workflow
• Compute migration guides: all provider guides