Coming from Vultr
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).
Coming from Vultr
If you have been running on Vultr, you already know the primitives: Cloud Compute and Bare Metal instances, Block Storage, Object Storage (S3-compatible), VPC 2.0, Firewall Groups, Load Balancers, and Vultr Kubernetes Engine (VKE). Quake AI exposes compute, storage, networking, and Kubernetes through standard OpenStack services. See How Quake AI uses OpenStack for the full project map. The biggest conceptual shift is from Vultr's account-scoped resources and account-level Firewall Groups to OpenStack's explicit project model: networks, subnets, routers, and per-port security groups are independent objects you wire together.
Quick reference#
| Vultr | Quake AI | OpenStack project | Key difference |
|---|---|---|---|
| Cloud Compute / Bare Metal Instance | Instance | Nova | Vultr publishes fixed plans (Regular, High Performance, High Frequency, CPU Optimized, Memory Optimized, Bare Metal); Quake AI uses the m2a/c2a/r2a/s1a flavor families (Flavors). |
| Block Storage | Volume | Cinder | Both network block devices, single-attach. Vultr offers HDD and NVMe tiers selected at create time; Quake AI Cinder uses volume types. |
| Object Storage | Container | Swift | Both expose an S3-compatible API. Endpoint and credentials change; SDK code does not. |
| VPC 2.0 | Network | Neutron | Vultr VPC 2.0 is an account-level L2 segment with customer-defined CIDR; Neutron exposes networks, subnets, and routers explicitly. |
| Firewall Group | Security Group | Neutron | Vultr Firewall Groups are account-level and attached to instances by reference; Neutron security groups are per-port and project-scoped. |
| Load Balancer | Self-managed edge proxy or API gateway | Nova + Neutron | Translate routes, backends, and health checks into Caddy, SafeLine, or APISIX. |
| Reserved IP | Floating IP | Neutron | Same concept; Quake AI Floating IPs are allocated from PublicStatic and attached to a port via DNAT on a router. |
| SSH Key | Key Pair | Nova | Direct equivalent. |
| VKE Cluster | Kubernetes Cluster | Magnum | VKE auto-scales nodes and manages upgrades; Magnum workers are self-managed Nova instances. Self-managed RKE2 or k3s on Nova is also documented as an alternative. See migrate from VKE. |
Compute: Vultr instances (Cloud Compute and Bare Metal)#
What maps directly. You still pick an image, a region, a plan, and SSH keys. Quake AI instances are backed by OpenStack Nova and are provisioned through the Cloud Console, the OpenStack CLI, or the Nova API.
What is different. Vultr's plan families (Regular Performance, High Performance, High Frequency, CPU Optimized, Memory Optimized, Bare Metal) are documented at Cloud Compute and Bare Metal. Quake AI exposes four flavor families:
m2a: general purpose, 4 GiB RAM per vCPUc2a: compute-optimized, 2 GiB RAM per vCPUr2a: memory-optimized, 8 GiB RAM per vCPUs1a: shared, 1-2 GiB RAM per vCPU
Quake AI uses fixed monthly plans tied to a resource tier, plus a small list of per-resource add-ons (see the pricing model); Vultr bills hourly with a monthly cap.
Block storage: Vultr Block Storage to Cinder volumes#
Both products are network block devices that attach to a single instance at a time. The data path is the same: you create the volume, attach it to an instance, partition and mount the device. Vultr exposes Block Storage through the /v2/blocks API and the Customer Portal; on Quake AI you use openstack volume create and openstack server add volume. See Block Storage. The migration path is rebuild-and-rsync: provision a Cinder volume on the target, attach to the new instance, and copy with rsync over SSH.
Object storage: Vultr Object Storage to Swift#
Vultr Object Storage and Quake AI Object Storage are both S3-compatible. Standard tooling (rclone, aws-cli, s3cmd, mc, boto3) works against both endpoints with no code change. The data migration is an endpoint swap and an rclone sync from the Vultr bucket to the Quake AI container. See migrate from Vultr Object Storage.
Differences to plan for:
- Endpoint format. Vultr endpoints follow
<region>.vultrobjects.com; Quake AI uses the Object Storage endpoint documented in your project credentials. - Lifecycle and policy features. S3 lifecycle rules, bucket policies, and event notifications are not part of the Swift backend. If you depend on these, see the S3 feature compatibility matrix.
- Subscription tiers. Vultr Object Storage is sold as bundled GB-month and bandwidth tiers; Quake AI Object Storage is a per-TB add-on. See the pricing model and Object Storage concepts.
Networking: Vultr VPC 2.0 + Firewall Groups to Neutron#
This is the largest conceptual shift. Vultr VPC 2.0 is an account-level Layer-2 segment with a customer-defined CIDR; routing between VPCs requires an instance acting as a router. On Quake AI you build the topology from independent Neutron objects:
- Network. L2 broadcast domain (OVN-backed VXLAN).
- Subnet. IP range with DHCP and gateway, attached to a network.
- Router. L3 gateway. SNAT outbound; DNAT inbound via floating IPs.
- Floating IP. Static public IPv4 allocated from
PublicStaticand bound to a port. - Security Group. Stateful, allow-only, per-port. The equivalent of a Vultr Firewall Group.
Vultr Firewall Groups apply to inbound traffic on the public interface and are attached to instances by reference; Neutron security groups are per-port with explicit ingress and egress rules. See migrate from Vultr VPC.
Load balancing: Vultr Load Balancers to a self-managed edge#
Vultr Load Balancers cover TCP, HTTP, and HTTPS with forwarding rules, health checks, and sticky sessions. On Quake AI, run an edge reverse proxy, edge WAF, or API gateway on a VM with a floating IP. Translate Vultr forwarding rules into proxy routes, backend lists, and application health checks.
Kubernetes: VKE to Magnum#
What maps directly: You still get a Kubernetes API, worker nodes, and cluster-scoped resources. Clusters are provisioned through OpenStack Magnum, which selects a cluster template the way VKE selects a Kubernetes version and node pool profile.
Kubernetes Services with type: LoadBalancer keep the same workload-facing contract after migration. The cluster provisions the public endpoint without exposing a tenant-managed load balancer service.
What is different: VKE manages node pools, offers auto-scaling, and keeps the control plane fully hands-off. Magnum gives you a managed control plane from the template, but worker nodes are Nova instances you size, patch, and scale: there is no built-in node auto-scaling in the same shape as VKE. The platform also documents self-managed RKE2 or k3s on Nova instances as an alternative for teams that need a custom CNI, custom kubelet flags, custom CRI, or a Kubernetes version outside the template catalog.
Operations: You plan capacity, upgrades, and add-ons with OpenStack and Kubernetes APIs both in play. Cluster operations and templates are covered in Kubernetes. For cluster migration steps, see migrate from VKE.
Self-managed services and deployment patterns#
Be honest about the gaps before you plan a migration:
- Vultr Managed Databases (PostgreSQL, MySQL, Redis, Kafka). Quake AI has no managed database. Run Postgres, MySQL, or Redis on a Nova instance with Cinder-backed data volumes, or use an external managed DB provider over the public internet.
- Vultr Backups (automated per-instance snapshots). Use Cinder volume snapshots and
openstack server image createfor instance images. - Vultr DDoS Protection. Quake AI offers per-instance Neutron security groups; there is no equivalent of Vultr's edge DDoS mitigation in the Quake AI product surface.
Next steps#
- Read migrate from Vultr for the overall migration workflow.
- Inventory your Vultr instances, Block Storage volumes, Object Storage buckets, VPCs, Firewall Groups, Load Balancers, and VKE clusters before you start.
- Use the OpenStack mapping page to translate any Vultr API calls in your tooling to the equivalent OpenStack project.
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.