# Migrating from DigitalOcean to Quake AI Source: https://docs.quake.ai/docs/platform/migration/from-digitalocean Markdown: https://docs.quake.ai/docs/platform/migration/from-digitalocean.md --- # Migrating from DigitalOcean to Quake AI This guide walks you through moving workloads from DigitalOcean to Quake AI, service by service. If you have not reviewed the concept differences, start with [Coming from DigitalOcean](/docs/platform/migration/coming-from-digitalocean) for the full mapping table. This page assumes you understand the translation and are ready to execute. ## Before you migrate - Review the [concept translation guide](/docs/platform/migration/coming-from-digitalocean) for concept-by-concept mapping - Inventory your DigitalOcean resources: Droplets, Spaces buckets, Volumes, VPCs, Cloud Firewalls, Load Balancers, and any managed databases - Identify App Platform and Managed Database dependencies that need self-managed alternatives on Quake AI ## Migration phases ### 1. Evaluate and plan Inventory your DigitalOcean resources: Droplets, Spaces buckets, Volumes, VPCs, Cloud Firewalls, Load Balancers. Identify managed services with no direct Quake AI equivalent (App Platform, Managed Databases, Managed Redis) and plan self-managed replacements. ### 2. Account setup Create your Quake AI project, generate application credentials, and install the OpenStack CLI. - [Quickstart](/docs/quickstart) - [Generate application credentials](/docs/platform/access/generate-app-credentials) - [Access & Credentials](/docs/platform/access/) for the OpenStack CLI ### 3. Object storage (Spaces → Swift) Spaces to Swift is the most straightforward migration on this list. Both expose an S3-compatible API, so the same tools (rclone, aws-cli, s3cmd) work with an endpoint and credential change. **What transfers cleanly:** Buckets (containers on Quake AI), objects, keys, prefixes, metadata. Point your S3 client at `object..rumble.cloud` with Quake AI credentials and the same operations work. Replace `` with your Quake AI region: `us-east-1`, `us-east-2`, or `us-west-1`. **What does not transfer:** Spaces CDN (use Cloudflare or another CDN in front of Swift). Spaces CORS policies need re-creation as Swift CORS headers. For the full cutover procedure, see [Migrate from DigitalOcean Spaces](/docs/object/migration/migrate-from-digitalocean). ### 4. Infrastructure as code (doctl and DigitalOcean provider → OpenTofu) DigitalOcean uses its own Terraform provider (`digitalocean`). Resources need to be rewritten using the `openstack` provider. No automatic conversion tool exists. **Practical approach:** 1. Export your current resource inventory with `doctl compute droplet list --format ID,Name,Memory,VCPUs,Region --no-header` (and similar for volumes, firewalls, load balancers) 2. Document the resource inventory as a migration checklist 3. Rewrite each resource using OpenTofu with the `openstack` provider **Key resource mappings:** | DigitalOcean (Terraform) | Quake AI (OpenTofu) | |---|---| | `digitalocean_droplet` | `openstack_compute_instance_v2` | | `digitalocean_volume` | `openstack_blockstorage_volume_v3` | | `digitalocean_firewall` | `openstack_networking_secgroup_v2` | | `digitalocean_vpc` | `openstack_networking_network_v2` + `openstack_networking_subnet_v2` | | `digitalocean_reserved_ip` | `openstack_networking_floatingip_v2` | | `digitalocean_loadbalancer` | Edge reverse proxy, WAF, or API gateway on Nova with a Neutron floating IP | Get started with [Infrastructure as Code with OpenTofu](/docs/automation/how-to/getting-started-iac). ### 5. Compute (droplets → Nova) DigitalOcean Droplet snapshots cannot be exported or downloaded (DigitalOcean does not support snapshot portability to external platforms). The practical migration approach is to provision new instances and migrate application data: **Containerized applications:** If your workload runs in Docker, migrate container images and deploy them on Nova instances. For DOKS workloads, self-managed Kubernetes on Nova (via RKE2 or k3s) is the recommended path; see [Migrate from DOKS to Kubernetes on Quake AI](/docs/kubernetes/migration/migrate-from-doks) for the full guide. **Non-containerized applications:** Provision a new Nova instance with the same base image, install your application stack, and rsync data from the Droplet. Use cloud-init or OpenTofu to make the provisioning repeatable. **Snapshots:** DigitalOcean Snapshots are not portable. Treat them as backups for rollback on the source side, not as migration artifacts. See [Create an instance](/docs/compute/how-to/create-instance) for the full workflow. For the full guide, see [Migrate from Droplets to Quake AI Compute](/docs/compute/migration/migrate-from-droplets). ### 6. Networking (VPC → Neutron) Re-create your VPC as a **network**, **subnet**, and **router** in Neutron. The model is more explicit: you configure network, subnet, and router as distinct objects. **Cloud Firewall → Security Groups:** DigitalOcean applies firewalls at the network level or via Droplet tags; Quake AI applies security groups per instance (per port). Re-create your firewall rules as Neutron security group rules with the same protocol, port, and CIDR values. **Reserved IP → Floating IP:** Same concept, different API. Allocate a floating IP from the external pool and associate it with your instance's port. Key how-to guides: - [Create a network](/docs/network/how-to/create-network) - [Create a security group](/docs/network/how-to/create-security-group) - [Allocate floating IPs](/docs/network/how-to/allocate-floating-ips) For topology diagrams, three-tier security rule translation, and public-address migration, see [Migrate from DigitalOcean VPC to Quake AI](/docs/network/migration/migrate-from-do-vpc). Translate forwarding rules and targets into an [edge reverse proxy](/build/iac-templates/edge-reverse-proxy) or [API gateway](/build/iac-templates/api-gateway). ### 7. Validation and cutover Before decommissioning DigitalOcean resources: - [ ] Verify that applications respond on Quake AI instances with the expected behavior - [ ] Confirm object storage data integrity between Spaces and Swift - [ ] Update DNS records to point to Quake AI floating IPs; use low TTLs during the transition - [ ] Validate security group rules match your Cloud Firewall configuration - [ ] Confirm monitoring and alerting are in place (self-managed Prometheus, Grafana, or equivalent) - [ ] If using Managed Databases, verify that self-managed database instances on Quake AI are replicating or have imported data correctly ## Service mapping reference The table below shows how DigitalOcean services map to Quake AI equivalents, with confidence ratings and documented divergences. The `` component reads from the platform knowledge graph. ## Self-managed services and deployment patterns | DigitalOcean service | Status on Quake AI | Alternative | |---|---|---| | App Platform | Not available | Deploy on VMs with Docker or Kubernetes | | Managed Database | Not available | Self-managed on VMs with [automation templates](/build/iac-templates) | | Managed Redis | Not available | Self-managed Redis on a VM | | Functions (serverless) | Not available | Containers on VMs or Kubernetes | | Monitoring / alerts | Not available | Self-managed Prometheus + Grafana | | Spaces CDN | Not available | Cloudflare or self-managed caching | For the full comparison, see [Coming from DigitalOcean: What Quake AI doesn't have](/docs/platform/migration/coming-from-digitalocean#what-rumble-doesnt-have). ## Next steps - [Coming from DigitalOcean](/docs/platform/migration/coming-from-digitalocean): concept translation reference - [Infrastructure as Code with OpenTofu](/docs/automation/how-to/getting-started-iac) - [Resource tiers](/docs/platform/account/resource-tiers): Developer Plan details and upgrade paths - [All migration guides](/docs/platform/migration)