Migrating from Vultr to Quake AI
Coming from another cloud?
▸Vultr·Cloud Compute / Bare Metal Instances, Block Storage, Object Storage, VPC 2.0, Firewall Groups, Load Balancers, Kubernetes Engine (VKE) Cluster
Cloud Compute / Bare Metal Instances
- Provisioned via the Vultr API v2 (/v2/instances and /v2/bare-metals) instead of OpenStack Nova /v2.1/servers; auth is a Personal Access Token rather than a Keystone token.
- Plan selection is fixed (Regular Performance, High Performance, High Frequency, CPU Optimized, Memory Optimized, Bare Metal) with predefined vCPU/RAM/storage; OpenStack flavors can be cloud-defined.
- Billing is hourly with a monthly cap per plan; powered-off Vultr instances continue to bill until destroyed, unlike pause/suspend semantics common in OpenStack stop-billing setups.
- Marketplace one-click apps and ISO library are first-class; OpenStack uses Glance images and arbitrary userdata.
Block Storage
- Managed via /v2/blocks on the Vultr API; OpenStack uses Cinder /v3/{project_id}/volumes.
- Block Storage offers two performance tiers (HDD and NVMe) selected at create time; OpenStack Cinder uses volume types defined by the cloud operator.
- Volumes are region-scoped and attach to a single instance at a time; the OpenStack multi-attach pattern is not exposed.
- Size increases only (no shrink); same restriction exists on OpenStack but Vultr enforces it as a hard API rule.
VPC 2.0
- VPC 2.0 networks are region-scoped Layer-2 segments with customer-defined CIDR; OpenStack Neutron networks are project-scoped with explicit subnets and routers.
- Instances attach to a VPC 2.0 by configuration interface rather than via Neutron ports; trunking is not the same model.
- VPC 2.0 has no integrated router object; routing between VPCs requires an instance acting as a router, while OpenStack uses Neutron routers natively.
- Legacy 'Private Network' and VPC 2.0 are distinct products on Vultr; OpenStack collapses these into Neutron network types (vlan, vxlan, geneve).
Firewall Groups
- Firewall Groups are managed at the account level and attached to one or more instances by reference; OpenStack security groups are per-port and project-scoped.
- Rules apply only to inbound traffic on the public interface; outbound traffic is allowed by default with no rule surface, unlike Neutron security groups which have explicit ingress and egress rules.
- Default policy is implicit-deny inbound on any port without a matching rule; OpenStack security groups follow the same default-deny model but allow explicit egress shaping.
- Firewall Groups are free and have no per-instance attach limit documented; OpenStack security groups are likewise free but have different rule semantics (port + protocol + remote group).
Vultr Load Balancers
- Vultr Load Balancers are a managed L4/L7 product configured per region with forwarding rules, health checks, and sticky sessions. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
- A Vultr Load Balancer contains one or more frontend and backend forwarding rules. Self-managed Quake AI edges define listeners and upstreams in proxy or ingress configuration.
- Vultr configures TLS termination with an inline certificate and key. Quake AI users manage TLS on the self-managed edge.
- Vultr prices each managed Load Balancer separately. Size the compute used by a self-managed Quake AI edge instead.
Vultr Kubernetes Engine (VKE) Cluster
- VKE provides a free managed control plane with optional HA upgrades; on Quake AI you provision the cluster through Magnum or self-managed Kubernetes on Nova instances (OpenTofu plus kubeadm, k3s, or RKE2) and operate it yourself.
- VKE clusters are created and managed through the Vultr API or Customer Portal with a single cluster object. Quake AI offers Magnum as a managed-cluster API, or you can compose a cluster from compute instances, a private network, a CNI, and a self-managed control-plane endpoint.
- VKE ships an integrated Vultr cloud controller manager and Vultr CSI driver for Block Storage out of the box; on Quake AI you install openstack-cloud-controller-manager and the Cinder CSI driver yourself.
- VKE node pools auto-recycle when you upgrade the Kubernetes version; Quake AI node lifecycle is managed by you (OpenTofu replace, manual drain, or cluster API operator).
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 for the full mapping table.
Before you migrate#
- Read the concept-translation guide 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 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) andPublicStatic(private network + Neutron router + Floating IP). Production migrations should targetPublicStatic; see migrate from Vultr VPC. - VKE strategy. Quake AI provisions Kubernetes through Magnum 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 for both paths.
2. Account setup#
Create your Quake AI project, generate application credentials, and install the OpenStack CLI.
- Quickstart
- Generate application credentials
- Access & Credentials for the OpenStack CLI
Keep the Vultr API reference and the vultr-cli handy on the source side; you will use them to enumerate the resources you migrate.
3. Object storage#
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
<region>.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 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.
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.
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 (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, edge WAF, or 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: 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 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.
9. Infrastructure as code (vultr provider to openstack provider)#
If you use OpenTofu or Terraform with the vultr provider, the migration is a provider swap (vultr/vultr to terraform-provider-openstack/openstack) and a resource rename. Full procedure: Migrate from Vultr automation.
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: concept translation
- How Quake AI uses OpenStack: project-level mapping
- Migration Explorer: interactive comparison table
Usage Guidelines
The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.
Comparisons to third-party providers in this material reflect publicly documented behavior as of the validation date below. Pricing, quotas, service limits, and feature availability change frequently on every cloud. Verify provider-specific claims against the provider's own current documentation before relying on them for a procurement, architecture, or migration decision.
For the full policy, see Usage Guidelines.