# Migrate from Vultr VPC 2.0 and Firewall Groups to Quake AI

Source: https://docs.quake.ai/docs/network/migration/migrate-from-vultr-vpc
Markdown: https://docs.quake.ai/docs/network/migration/migrate-from-vultr-vpc.md

---

# Migrate from Vultr VPC 2.0 and Firewall Groups to Quake AI

Vultr exposes a compact networking surface: [VPC 2.0](https://docs.vultr.com/products/network/vpc-networks), account-level [Firewall Groups](https://docs.vultr.com/products/network/firewall-groups), [Reserved IPs](https://docs.vultr.com/products/network/reserved-ips), and [Vultr Load Balancers](https://docs.vultr.com/vultr-load-balancers). Quake AI's [OpenStack Neutron](/resources/migration/openstack) provides explicit networks, subnets, routers, floating IPs, and security groups. Replace Vultr Load Balancers with a reverse proxy or external edge service.

## Service mapping

<MigrationTable provider="vultr" service="network" />

## Prerequisites

- A Quake AI account with [application credentials](/docs/tools/generate-app-credentials)
- The [OpenStack CLI](/docs/tools/install-openstack-client) 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.

<Figure caption="Vultr VPC 2.0 with instances, Firewall Groups, and Reserved IPs maps to a Neutron network with router, Floating IPs, and per-port security groups">

```d2
direction: down

vultr: Vultr VPC 2.0 {
  vultr_vm: Cloud Compute Instance
  public_nic: Public NIC
  vpc_nic: VPC 2.0 NIC
  fw_group: Firewall Group
  reserved_ip: Reserved IP
  vultr_vm -> public_nic
  vultr_vm -> vpc_nic
  fw_group -> vultr_vm: attached
  reserved_ip -> public_nic
}

neutron: Quake AI Neutron {
  network: Tenant Network
  subnet: Subnet
  router: Router (SNAT)
  fip: Floating IP
  sg: Security Group
  port: Port
  network -> subnet
  router -> network
  port -> network
  sg -> port: port-level
  fip -> port
}

vultr -> neutron: maps to
```

</Figure>

| 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

```bash
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-subnet
```

## Security 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 CIDR
- `fw-app`: inbound TCP 8080 from the web tier's VPC 2.0 CIDR
- `fw-db`: inbound TCP 5432 from the app tier's VPC 2.0 CIDR

**Neutron target:**

```bash
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 --ingress
```

Apply `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](https://docs.vultr.com/products/network/reserved-ips). | Public IPs (used for Floating IPs) are an add-on; dedicated-vCPU plans include one. See the [pricing model](/docs/platform#pricing). |
| 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:

```bash
openstack floating ip create PublicStatic
openstack server add floating ip MY_INSTANCE FLOATING_IP_ADDRESS
```

## DNS cutover

Vultr offers a free [DNS service](https://docs.vultr.com/introduction-to-vultr-dns). Quake AI has no managed DNS. Migrate your zones to an external provider.

1. **Export zone file.** From the Vultr Customer Portal, export each zone as a BIND zone file (or use `vultr-cli dns records list` and convert to BIND).
2. **Lower TTLs.** Set all record TTLs to 300 seconds on Vultr; wait for the current TTL window to expire.
3. **Import at new provider.** Most DNS providers (Cloudflare, NS1, Route 53) accept BIND zone-file imports.
4. **Validate.** `dig @NEW_NAMESERVER example.com A`
5. **Update registrar NS records.** Point to the new nameservers.
6. **Monitor for 48 hours.** Keep Vultr DNS active during monitoring; revert via the registrar if issues arise.
7. **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](/resources/migration/from-vultr): full cross-service migration hub
- [Migrate from Vultr Cloud Compute](/docs/compute/migration/migrate-from-vultr): compute workload migration
- [Network migration guides](/docs/network/migration): all provider guides
- [Create a security group](/docs/network/how-to/create-security-group): Neutron security group setup