# Migrate from DigitalOcean Droplets to Quake AI Compute Source: https://docs.quake.ai/docs/compute/migration/migrate-from-droplets Markdown: https://docs.quake.ai/docs/compute/migration/migrate-from-droplets.md --- # Migrate from DigitalOcean droplets to Quake AI compute This guide covers migrating compute workloads from DigitalOcean Droplets to Quake AI (OpenStack Nova). DigitalOcean does not support image export, so the recommended approach is rebuild and rsync: provision a fresh Nova instance, install your application stack, and transfer data. ## Service mapping ## 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 Droplets - An SSH key pair imported to Quake AI (`openstack keypair create --public-key`) ## Image portability DigitalOcean does not provide an API or UI for downloading Droplet snapshots. A `dd`-based workaround exists but is impractical for most migrations: it captures the entire disk (including empty space), requires a temporary Droplet, and produces images with no guarantee of bootability on OpenStack. **Recommendation:** Do not attempt image export. Rebuild and rsync is faster and more reliable. ## Flavor mapping DigitalOcean plan families map to Quake AI flavor families by their RAM-to-vCPU ratio. Basic (shared) maps to s1a, General Purpose (4:1) maps to m2a, CPU-Optimized (2:1) maps to c2a, and Memory-Optimized (8:1) maps to r2a. | DO Droplet Plan | vCPUs | RAM (GiB) | Quake AI Flavor | vCPUs | RAM (GiB) | Notes | |---|---|---|---|---|---|---| | s-1vcpu-1gb (Basic) | 1 | 1 | s1a.micro | 1 | 1 | Exact match | | s-1vcpu-2gb (Basic) | 1 | 2 | s1a.small | 1 | 2 | Exact match | | s-2vcpu-4gb (Basic) | 2 | 4 | s1a.medium | 2 | 4 | Both shared CPU | | s-4vcpu-8gb (Basic) | 4 | 8 | s1a.large | 4 | 8 | Both shared CPU | | gd-2vcpu-8gb (General) | 2 | 8 | m2a.large | 2 | 8 | Exact ratio match | | gd-4vcpu-16gb (General) | 4 | 16 | m2a.xlarge | 4 | 16 | Exact ratio match | | gd-8vcpu-32gb (General) | 8 | 32 | m2a.2xlarge | 8 | 32 | Exact ratio match | | c-2vcpu-4gb (CPU-Optimized) | 2 | 4 | c2a.large | 2 | 4 | Exact ratio match | | c-4vcpu-8gb (CPU-Optimized) | 4 | 8 | c2a.xlarge | 4 | 8 | Exact ratio match | | c-8vcpu-16gb (CPU-Optimized) | 8 | 16 | c2a.2xlarge | 8 | 16 | Exact ratio match | | m-2vcpu-16gb (Memory-Optimized) | 2 | 16 | r2a.large | 2 | 16 | Exact ratio match | | m-8vcpu-64gb (Memory-Optimized) | 8 | 64 | r2a.2xlarge | 8 | 64 | Exact ratio match | Larger Basic Droplets (s-8vcpu-16gb) do not have a clean s1a match because s1a maxes out at 8 vCPU / 8 GiB. Step up to m2a.2xlarge (8 vCPU / 32 GiB) for production workloads at that scale. General Purpose slugs come in two variants: `g-` (standard SSD) and `gd-` (Premium NVMe SSD). Both variants share the same vCPU and RAM ratios; the `gd-` variant adds NVMe storage and up to 10 Gbps network. The flavor mapping applies to both. ## Migration approach ### Option 1: Containerized workloads (recommended) If your Droplets run Docker containers, migrate images and redeploy. 1. Push images from DigitalOcean Container Registry (or Docker Hub) to a portable registry: ```bash docker pull registry.digitalocean.com/MY_REGISTRY/MY_APP:latest docker tag registry.digitalocean.com/MY_REGISTRY/MY_APP:latest \ registry.example.com/MY_APP:latest 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) For traditional LAMP/LEMP or custom application stacks. 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 on the Quake AI instance. Reuse cloud-init configs or provisioning scripts from your Droplet setup. 4. Transfer application data: ```bash rsync -avz --progress -e "ssh -i ~/.ssh/MY_KEY" \ root@DROPLET_IP:/path/to/app/data \ ubuntu@FLOATING_IP:/path/to/app/data ``` 5. Migrate databases: ```bash # PostgreSQL pg_dump -h DROPLET_IP -U MY_USER MY_DATABASE | \ psql -h FLOATING_IP -U MY_USER MY_DATABASE # MySQL mysqldump -h DROPLET_IP -u MY_USER -p MY_DATABASE | \ mysql -h FLOATING_IP -u MY_USER -p MY_DATABASE ``` DigitalOcean Droplet plans include data transfer bandwidth, from 500 GiB to 11,000 GiB per month depending on plan type and size. Migration egress is typically within the included bandwidth for most workloads. ## Key pair and security setup ### Import your SSH key Import your existing SSH public key to Quake AI: ```bash openstack keypair create --public-key ~/.ssh/id_ed25519.pub my-key ``` ### Translate Cloud Firewalls to security groups DigitalOcean Cloud Firewalls apply at the network level or via tags. Neutron security groups apply per instance (per port). Re-create your firewall rules as security group 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 ``` This example allows SSH from any IP. In production, replace `0.0.0.0/0` with your specific IP range or bastion host IP: `--remote-ip YOUR_IP/32`. If you used DigitalOcean tag-based firewall targeting, apply the equivalent security group to each Quake AI instance individually. ## 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 to replace DO Monitoring) - [ ] Managed Database data migrated to self-managed instances on Quake AI (if applicable) - [ ] SSL/TLS certificates installed and renewed ## Provider-specific gotchas | Topic | Detail | |---|---| | Snapshots not portable | DO snapshots are internal-only. Do not plan migration around snapshot transfer. | | Reserved IPs | DO Reserved IPs cannot be transferred. Update DNS to point to new Quake AI floating IPs. | | Managed services | Managed Databases, App Platform, and Functions have no Quake AI equivalent. Self-host on VMs. | | Container Registry | DO Container Registry is private to your DO account. Push images to a portable registry before decommissioning. | | Bandwidth model | DO includes 500 GiB to 11,000 GiB/month per Droplet depending on plan (transfer allowances are pooled across Droplets in the same account). Quake AI allocates bandwidth per instance (0.5 Gbps per 2 vCPUs). No pooling. | ## See also - [Migrating from DigitalOcean to Quake AI](/resources/migration/from-digitalocean): full cross-service migration hub - [Coming from DigitalOcean](/resources/migration/coming-from-digitalocean): 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 - [Object storage migration](/docs/object/migration): if you also need to move DigitalOcean Spaces data to Quake AI Object Storage