# Migrate from Vultr to Quake AI compute

Source: https://docs.quake.ai/docs/compute/migration/migrate-from-vultr
Markdown: https://docs.quake.ai/docs/compute/migration/migrate-from-vultr.md

---

# 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

<MigrationTable provider="vultr" service="compute" />

## Prerequisites

- A Quake AI account with [application credentials](/docs/tools/generate-app-credentials)
- The [OpenStack CLI](/docs/tools/install-openstack-client) 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](https://docs.vultr.com/products/compute/instances) and [Bare Metal](https://docs.vultr.com/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:

| Vultr plan family | Quake AI flavor family | RAM-per-vCPU ratio | Notes |
|---|---|---|---|
| Regular Performance (shared, small) | `s1a` | 1-2 GiB | Smallest shared sizes; cheapest entry point on both. |
| Regular Performance (larger general-purpose) | `m2a` | 4 GiB | General-purpose web/app workloads. |
| High Performance | `m2a` | 4 GiB | NVMe storage on both; pick `m2a` for the closest ratio. |
| High Frequency | `c2a` | 2 GiB | High clock speeds on both; `c2a` is the compute-optimized choice. |
| CPU Optimized | `c2a` | 2 GiB | Direct fit. |
| Memory Optimized | `r2a` | 8 GiB | Direct fit. Cinder volumes provide additional disk for in-memory workload spillover. |
| Bare Metal | No managed equivalent | n/a | Quake AI does not currently expose dedicated bare-metal flavors. Plan a rebuild on the closest virtualized flavor, or consult Quake AI support for capacity options. |

Pick the closest Quake AI flavor by vCPU count and RAM-per-vCPU ratio. See [Flavors](/docs/compute/concepts/flavors) for the full list.



Vultr bills hourly with a monthly cap; Quake AI uses fixed monthly plans tied to a resource tier, plus a small list of per-resource add-ons (see the [pricing model](/docs/platform#pricing)). Vultr Object Storage subscriptions include a fixed bandwidth allowance; Quake AI has no separate egress charge.



## 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:

```bash
docker push registry.example.com/MY_APP:latest
```

2. Provision a Nova instance on Quake AI:

```bash
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
```

3. Install Docker and deploy:

```bash
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:

```bash
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
```

2. Assign a Floating IP:

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

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

4. Transfer application data:

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

5. Migrate databases:

```bash
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

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

### Translate Vultr Firewall Groups to security groups

[Vultr Firewall Groups](https://docs.vultr.com/products/network/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:

```bash
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:

```bash
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

| Topic | Detail |
|---|---|
| Billing for powered-off instances | Vultr bills hourly while an instance exists, regardless of power state; only destruction stops billing. Plan the cutover window so you destroy the source instance promptly after validating the Quake AI instance. |
| Vultr-only snapshot migrate | Vultr's snapshot tooling is Vultr-to-Vultr and cannot target OpenStack. |
| Managed services | **Vultr Managed Databases** (PostgreSQL, MySQL, Redis, Kafka) and **Vultr Backups** have no managed equivalent on Quake AI. Run Postgres/MySQL/Redis on a Nova instance with a Cinder data volume; replace Backups with `openstack server image create` and Cinder volume snapshots. |
| Bare Metal | Vultr Bare Metal plans have no managed Quake AI equivalent today. |
| vultr-cli | Keep [vultr-cli](https://github.com/vultr/vultr-cli) installed during the cutover to enumerate source resources. |

## See also

- [Migrating from Vultr to Quake AI](/resources/migration/from-vultr): full cross-service migration hub
- [Coming from Vultr](/resources/migration/coming-from-vultr): concept translation reference
- [Create an instance](/docs/compute/how-to/create-instance): full instance provisioning workflow
- [Compute migration guides](/docs/compute/migration): all provider guides