# Coming from Vultr

Source: https://docs.quake.ai/docs/platform/migration/coming-from-vultr
Markdown: https://docs.quake.ai/docs/platform/migration/coming-from-vultr.md

---

# 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](/docs/platform/migration/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](/docs/compute/concepts/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](/docs/kubernetes/migration/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](https://docs.openstack.org/nova/latest/) 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](https://docs.vultr.com/products/compute/instances) and [Bare Metal](https://docs.vultr.com/bare-metal). Quake AI exposes four flavor families:

- `m2a`: general purpose, 4 GiB RAM per vCPU
- `c2a`: compute-optimized, 2 GiB RAM per vCPU
- `r2a`: memory-optimized, 8 GiB RAM per vCPU
- `s1a`: 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](/docs/platform#pricing)); 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](/docs/block). 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](https://docs.vultr.com/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](/docs/object/migration/migrate-from-vultr).

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](/docs/object/migration/plan-your-migration#s3-feature-compatibility).
- **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](/docs/platform#pricing) and [Object Storage concepts](/docs/object/concepts/object-storage).

## Networking: Vultr VPC 2.0 + Firewall Groups to Neutron

This is the largest conceptual shift. Vultr [VPC 2.0](https://docs.vultr.com/products/network/vpc-networks) 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 `PublicStatic` and bound to a port.
- **Security Group.** Stateful, allow-only, per-port. The equivalent of a Vultr [Firewall Group](https://docs.vultr.com/products/network/firewall-groups).

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](/docs/network/migration/migrate-from-vultr-vpc).

## Load balancing: Vultr Load Balancers to a self-managed edge

[Vultr Load Balancers](https://docs.vultr.com/vultr-load-balancers) cover TCP, HTTP, and HTTPS with forwarding rules, health checks, and sticky sessions. On Quake AI, run 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) 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](https://docs.openstack.org/magnum/latest/), which selects a **cluster template** the way [VKE](https://docs.vultr.com/products/kubernetes) 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](/docs/kubernetes). For cluster migration steps, see [migrate from VKE](/docs/kubernetes/migration/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](/docs/block) and `openstack server image create` for 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](/docs/platform/migration/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](/docs/platform/migration/openstack) to translate any Vultr API calls in your tooling to the equivalent OpenStack project.