# Migrating from Vultr to Quake AI Source: https://docs.quake.ai/docs/platform/migration/from-vultr Markdown: https://docs.quake.ai/docs/platform/migration/from-vultr.md --- # Migrating from Vultr to Quake AI This guide walks you through moving workloads from Vultr to Quake AI, service by service. The two platforms share a self-managed ethos, so most migrations are a translation of API calls and a remap of resource names. Networking and Kubernetes are the largest shifts. If you have not reviewed the concept differences yet, start with [Coming from Vultr](/docs/platform/migration/coming-from-vultr) for the full mapping table. ## Before you migrate - Read the [concept-translation guide](/docs/platform/migration/coming-from-vultr) for how Vultr services map to Quake AI. - Inventory your Vultr resources end to end: Cloud Compute and Bare Metal instances, Block Storage volumes, Object Storage buckets, VPC 2.0 networks, Firewall Groups, Load Balancers, Reserved IPs, and VKE clusters. - Identify managed-service dependencies that need self-managed alternatives on Quake AI: **Vultr Managed Databases** (PostgreSQL, MySQL, Redis, Kafka), **Vultr Backups** (automated per-instance snapshots), and **VKE** itself. Each of these maps to a self-managed pattern on Nova instances. - Decide your sequencing: object storage first (cheapest to move and easiest to validate), then networking, then compute, then Kubernetes. ## Migration phases ### 1. Evaluate and plan Inventory the seven Vultr primitives. For each one, note the region, plan or volume size, attached resources, and any managed-service dependencies. Vultr's [news feed](https://www.vultr.com/news/) is useful for confirming the current feature set on the source side; do not migrate on stale assumptions. The two biggest decisions to make upfront: - **VPC topology.** Vultr VPC 2.0 is an account-level L2 segment with a customer-defined CIDR and no integrated router. On Quake AI you choose between `PublicEphemeral` (DHCP-assigned public IP, no router) and `PublicStatic` (private network + Neutron router + Floating IP). Production migrations should target `PublicStatic`; see [migrate from Vultr VPC](/docs/network/migration/migrate-from-vultr-vpc). - **VKE strategy.** Quake AI provisions Kubernetes through [Magnum](/docs/kubernetes) from a curated cluster template; pick that path for the closest VKE-like experience. For teams that need a custom CNI, custom kubelet flags, custom CRI, or a Kubernetes version outside the template catalog, **self-managed RKE2 or k3s on Nova** is documented as an alternative. See [migrate from VKE](/docs/kubernetes/migration/migrate-from-vke) for both paths. ### 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 Keep the [Vultr API reference](https://www.vultr.com/api/) and the [vultr-cli](https://github.com/vultr/vultr-cli) handy on the source side; you will use them to enumerate the resources you migrate. ### 3. Object storage [Vultr Object Storage](https://docs.vultr.com/vultr-object-storage) is S3-compatible. The transfer is an endpoint swap and an `rclone sync` from Vultr to Quake AI Object Storage (Swift with the S3 gateway). Plan for these differences: - **Endpoint format.** Vultr uses `.vultrobjects.com`; Quake AI exposes the Swift endpoint listed in your project credentials. - **Lifecycle and bucket policies.** The Swift backend does not implement every S3 lifecycle and policy feature. Confirm against the [S3 feature compatibility matrix](/docs/object/migration/plan-your-migration#s3-feature-compatibility) before you cut over. - **Bandwidth allowances.** Vultr Object Storage subscriptions include a fixed bandwidth allowance; budget for the one-time sync only. Full procedure: [Migrate from Vultr Object Storage](/docs/object/migration/migrate-from-vultr). ### 4. Networking (VPC 2.0 and Firewall Groups) Translate Vultr VPC 2.0 to explicit Neutron objects (network, subnet, router) and Firewall Groups to Neutron security groups attached to instance ports. Reserved IPs map to Floating IPs on `PublicStatic`. Full procedure: [Migrate from Vultr VPC](/docs/network/migration/migrate-from-vultr-vpc). ### 5. Compute (Vultr instances to Nova instances) The recommended path is **rebuild and rsync**: provision a Quake AI flavor that matches your Vultr plan, install your application stack with your existing configuration management, and transfer data with `rsync`. Vultr image export through the snapshot API is limited, and disk-image compatibility (cloud-init datasource, kernel choice, drivers) is often imperfect even when an export is available. Full procedure: [Migrate from Vultr](/docs/compute/migration/migrate-from-vultr) (compute). ### 6. Load balancing (Vultr Load Balancers to a self-managed edge) Translate each Vultr Load Balancer into routes, backend lists, and health checks on an [edge reverse proxy](/build/iac-templates/edge-reverse-proxy), [edge WAF](/build/iac-templates/edge-waf), or [API gateway](/build/iac-templates/api-gateway). Provision a floating IP for the edge VM. ### 7. Block storage (Vultr Block Storage to Cinder volumes) Provision a Cinder volume that matches the source size, attach it to the new instance, partition and mount, then `rsync` the data over SSH. Cinder volumes are NVMe-backed (StorageClass `cinder-flash` on Kubernetes). ### 8. Kubernetes (VKE to Magnum, or self-managed on Nova) Provision your target cluster on Quake AI. The primary path is [Magnum](/docs/kubernetes): `openstack coe cluster create` builds the control plane, workers, security groups, and load-balanced API endpoint from a curated template. **Self-managed RKE2 or k3s on Nova** is the alternative when you need a custom CNI, kubelet flags, CRI, or a Kubernetes version outside the template catalog; that path uses the [openstack-cloud-controller-manager](https://github.com/kubernetes/cloud-provider-openstack) and the Cinder CSI driver. Restore workloads via Helm charts or `kubectl apply`; for stateful data, use `velero` (with the Restic plugin) or migrate the underlying PersistentVolumes with `rsync` from a debug pod. Full procedure: [Migrate from VKE](/docs/kubernetes/migration/migrate-from-vke). ### 9. Infrastructure as code (vultr provider to openstack provider) If you use OpenTofu or Terraform with the [vultr provider](https://registry.terraform.io/providers/vultr/vultr/latest), the migration is a provider swap (`vultr/vultr` to `terraform-provider-openstack/openstack`) and a resource rename. Full procedure: [Migrate from Vultr automation](/docs/automation/migration/from-vultr). ### 10. Validate and cut over - Verify each application responds correctly on the Quake AI side. - Point DNS at the new Floating IPs (or behind your edge / CDN of choice). - Confirm monitoring, alerting, and backups are in place on the Quake AI side before decommissioning Vultr resources. ## See also - [Coming from Vultr](/docs/platform/migration/coming-from-vultr): concept translation - [How Quake AI uses OpenStack](/docs/platform/migration/openstack): project-level mapping - [Migration Explorer](/docs/platform/migration): interactive comparison table