Migrate from Vultr VPC 2.0 and Firewall Groups to Quake AI
Coming from another cloud?
▸Vultr·VPC 2.0, Firewall Groups, Load Balancers
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.
Migrate from Vultr VPC 2.0 and Firewall Groups to Quake AI
Vultr exposes a compact networking surface: VPC 2.0, account-level Firewall Groups, Reserved IPs, and Vultr Load Balancers. Quake AI's OpenStack Neutron provides explicit networks, subnets, routers, floating IPs, and security groups. Replace Vultr Load Balancers with a reverse proxy or external edge service.
Service mapping#
Vultr to Quake AI
| Vultr service | Quake AI equivalent | Key difference |
|---|---|---|
| Reserved IPs | Floating IPs | Vultr models the resource as an account-scoped Reserved IP rather than an OpenStack-style floating IP pool object. The doc says Reserved... see details |
| NAT Gateway | NAT | Vultr documents NAT as a separate managed feature inside VPC Networks rather than an OpenStack Neutron router construct. The canonical page... see details |
| Load Balancers | Network | Vultr Load Balancers are a managed L4/L7 product configured per region with forwarding rules, health checks, and sticky sessions. Quake AI... see details |
| VPC Networks | Networking | Vultr’s base private networking primitive is a region-scoped VPC network, described as a private, isolated network for Vultr resources,... see details |
| VPC 2.0 | Networks | VPC 2.0 networks are region-scoped Layer-2 segments with customer-defined CIDR; OpenStack Neutron networks are project-scoped with explicit... see details |
| VPC Networks | Ports | Vultr describes this model as a "private, isolated network" for communication between Vultr resources, rather than an OpenStack... see details |
| N/A (No equivalent — Vultr VPC Networks do not expose an OpenStack-style router resource; routing is handled with a dedicated network gateway instance and static routes) | Routers | Vultr’s VPC docs do not define a first-class router object like OpenStack Neutron routers. Instead, the FAQ says VPC does not support... see details |
| Firewall Groups | Security Groups | Vultr Firewall Groups are the supported managed firewall product; there is no separate Neutron FWaaS-style abstraction on Vultr. A single... see details |
| VPC 2.0 | Subnets | Vultr exposes subnet settings as fields on the VPC resource rather than as a standalone subnet object. In the deprecated VPC 2.0 API, `POST... see details |
Prerequisites#
- A Quake AI account with application credentials
- The OpenStack CLI installed and configured
- An inventory of your Vultr resources: VPC 2.0 networks, Firewall Groups, Reserved IPs, Load Balancers, and DNS zones
- An SSH key pair imported to Quake AI (
openstack keypair create --public-key)
Topology mapping#
Vultr VPC 2.0 is an account-level L2 segment with a customer-defined CIDR and no integrated router; routing between VPC 2.0 networks requires an instance acting as a router. Firewall Groups apply at the account level and attach to instances by reference. Quake AI exposes the same shape as four independent Neutron objects: network, subnet, router, and security group.
| Vultr concept | Neutron equivalent | Notes |
|---|---|---|
| VPC 2.0 | Network + Subnet | Vultr VPC 2.0 is an L2 segment with customer-defined CIDR; Neutron exposes network and subnet as separate objects. |
| Legacy Private Network | Tenant network (no router) | Legacy Private Network is free intra-region L2; on Quake AI use a Neutron network without attaching it to a router for the same effect. |
| Region | Region | Direct mapping. |
| Vultr public IP | PublicEphemeral or Floating IP | Vultr public IPs are static while the instance exists; map to PublicEphemeral for throwaway instances or a Floating IP allocated from PublicStatic for production. |
| Reserved IP | Floating IP | Same operating model: static, reassignable, region-scoped. |
| Outbound NAT | Router (SNAT) | VPC 2.0 routes outbound through the instance's public NIC by default; Neutron's router provides SNAT. |
| Firewall Group | Security Group | Allow-only inbound, stateful; similar model. Outbound is allow-all on Vultr with no rule surface; Neutron supports explicit egress rules. |
| Firewall Group attached to multiple instances | Security Group applied to multiple ports | Vultr attaches the same Firewall Group ID to many instances; Neutron attaches the same SG to many ports. |
| Vultr Load Balancer | Self-managed reverse proxy or external edge | Feature comparison below. |
| VPC peering | No equivalent | Vultr does not offer VPC peering; Quake AI has no peering either. Use a VPN overlay for cross-network communication. |
Set up the Neutron equivalent#
openstack network create my-network
openstack subnet create my-subnet \
--network my-network \
--subnet-range 192.168.0.0/24 \
--gateway 192.168.0.1 \
--dns-nameserver 8.8.8.8
openstack router create my-router
openstack router set my-router --external-gateway PublicStatic
openstack router add subnet my-router my-subnetSecurity rule translation#
Vultr Firewall Groups and Neutron security groups share the same core inbound model: stateful, allow-only, deny-all inbound by default. Outbound behavior differs: Vultr allows all outbound with no rule surface; Neutron security groups have explicit egress rules and default to allow-all egress.
| Dimension | Vultr Firewall Group | Neutron Security Group |
|---|---|---|
| Enforcement level | Instance (attached by reference) | Port (per interface) |
| Statefulness | Stateful | Stateful |
| Rule model | Allow-only (inbound) | Allow-only (ingress + egress) |
| Inbound default | Deny-all | Deny-all |
| Outbound default | Allow-all (no rule surface) | Allow-all (configurable) |
| Source types | CIDR (IPv4 / IPv6) | CIDR, Security Group ID |
The key vocabulary difference: Vultr Firewall Groups are attached by instance reference with one rule set per group. Neutron uses security group references (--remote-group) to express tier-to-tier allow rules.
3-tier app example#
Vultr source:
fw-web: inbound TCP 80, 443 from any CIDRfw-app: inbound TCP 8080 from the web tier's VPC 2.0 CIDRfw-db: inbound TCP 5432 from the app tier's VPC 2.0 CIDR
Neutron target:
openstack security group create sg-web
openstack security group rule create sg-web \
--protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0 --ingress
openstack security group rule create sg-web \
--protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0 --ingress
openstack security group create sg-app
openstack security group rule create sg-app \
--protocol tcp --dst-port 8080 --remote-group sg-web --ingress
openstack security group create sg-db
openstack security group rule create sg-db \
--protocol tcp --dst-port 5432 --remote-group sg-app --ingressApply sg-web to all web tier ports, sg-app to all app tier ports, and sg-db to all database tier ports. This replaces the account-level Firewall Group model with port-level security group references.
Vultr Load Balancer migration#
Replace a Vultr Load Balancer with a reverse proxy such as HAProxy, Nginx, Caddy, Traefik, or Envoy. Assign a floating IP to the proxy instance and route requests to application instances over a private network.
Configure forwarding, health checks, sticky sessions, and Proxy Protocol in the proxy. Use Certbot or Caddy for certificate issuance and renewal. Use an external CDN or WAF when the application needs edge caching or managed request filtering.
Floating IP setup#
| Vultr Reserved IP | Neutron Floating IP |
|---|---|
| Static, region-scoped public IPv4 | Static, region-scoped public IPv4 |
| Free while attached to an instance; charged when idle. See Reserved IP. | Public IPs (used for Floating IPs) are an add-on; dedicated-vCPU plans include one. See the pricing model. |
| Re-assignable across instances in the same region | Re-assignable across ports in the same region. |
| One per resource at a time | One per port at a time. |
| IPv6 supported per instance | IPv6 not documented on Quake AI at this time. |
Allocate and associate a Floating IP:
openstack floating ip create PublicStatic
openstack server add floating ip MY_INSTANCE FLOATING_IP_ADDRESSDNS cutover#
Vultr offers a free DNS service. Quake AI has no managed DNS. Migrate your zones to an external provider.
- Export zone file. From the Vultr Customer Portal, export each zone as a BIND zone file (or use
vultr-cli dns records listand convert to BIND). - Lower TTLs. Set all record TTLs to 300 seconds on Vultr; wait for the current TTL window to expire.
- Import at new provider. Most DNS providers (Cloudflare, NS1, Route 53) accept BIND zone-file imports.
- Validate.
dig @NEW_NAMESERVER example.com A - Update registrar NS records. Point to the new nameservers.
- Monitor for 48 hours. Keep Vultr DNS active during monitoring; revert via the registrar if issues arise.
- Restore TTLs. Raise to 3600+ after a successful cutover.
Validation checklist#
- Neutron network, subnet, and router are operational
- Security group rules match your Firewall Group rules (compare port/CIDR combinations)
- Firewall-Group-attached instances are replaced by security group assignments on the correct ports
- Floating IPs are associated with the correct instance ports
- Reverse proxy health checks pass for application backends
- TLS termination and renewal work on the proxy or external edge
- DNS records resolve to the proxy floating IP or external edge hostname
- Applications respond correctly through the full network path
Provider-specific gotchas#
| Topic | Detail |
|---|---|
| Bandwidth allowance to flat egress | Vultr instances include a per-month bandwidth allowance that varies by plan; overage is per-GiB. Quake AI includes bandwidth in flavor pricing with no per-GB charge. |
| No resource-attached firewalls | Firewall Groups attach to instances by reference. Neutron requires per-port security group assignment. Use OpenTofu or Ansible to make the assignment declarative. |
| No outbound rule surface on Vultr | Vultr Firewall Groups have no outbound rule surface. If you need egress controls on Quake AI, define explicit Neutron egress rules. |
| Vultr Load Balancer is a single object | A self-managed proxy stores forwarding rules, backend pools, and health checks in its configuration. Keep that configuration in version control and deploy it through automation. |
| No VPC peering | Vultr does not offer VPC peering; Quake AI has no equivalent either. Use a VPN overlay (WireGuard or IPsec on a Nova instance) for cross-network communication. |
| Public IP semantics | Vultr public IPs are stable while the instance exists. Quake AI's PublicEphemeral model rotates on instance recreate; for stable addressing, allocate a Floating IP from PublicStatic. |
See also#
- Migrating from Vultr to Quake AI: full cross-service migration hub
- Migrate from Vultr Cloud Compute: compute workload migration
- Network migration guides: all provider guides
- Create a security group: Neutron security group setup
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.