# Migrate from Linode VPC and Cloud Firewall to Quake AI

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

---

# Migrate from Linode VPC and Cloud Firewall to Quake AI

Linode (now branded **Akamai Cloud Computing**) exposes a compact networking surface: a [VPC](https://techdocs.akamai.com/cloud-computing/docs/vpc) that bundles a network and a single subnet, a free intra-region L2 [VLAN](https://techdocs.akamai.com/cloud-computing/docs/vlans) for private traffic, a stateful [Cloud Firewall](https://techdocs.akamai.com/cloud-computing/docs/cloud-firewall), [Reserved IPs](https://techdocs.akamai.com/cloud-computing/docs/reserved-ip-addresses) for stable public addressing, and the [NodeBalancer](https://techdocs.akamai.com/cloud-computing/docs/create-a-nodebalancer) for L4/L7 load balancing. Quake AI's [OpenStack Neutron](/resources/migration/openstack) provides explicit networks, subnets, routers, floating IPs, and security groups. Replace NodeBalancer with a reverse proxy or external edge service.

## Service mapping

<MigrationTable provider="linode" 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 Linode resources: VPCs, VLANs, Cloud Firewalls, Reserved IPs, NodeBalancers, and DNS zones
- An SSH key pair imported to Quake AI (`openstack keypair create --public-key`)

## Topology mapping

Linode's VPC bundles a network and a single subnet into one API object, with a separate Cloud Firewall per Linode or NodeBalancer. Quake AI exposes the same shape as four independent Neutron objects: network, subnet, router, and security group.

<Figure caption="Linode VPC with Linodes, Cloud Firewalls, and Reserved IPs maps to a Neutron network with router, Floating IPs, and per-port security groups">

```d2
direction: down

linode: Linode (Akamai) VPC {
  linode_vm: Linode
  public_nic: Public NIC
  vpc_nic: VPC NIC
  cloud_fw: Cloud Firewall
  reserved_ip: Reserved IP
  linode_vm -> public_nic
  linode_vm -> vpc_nic
  cloud_fw -> linode_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
}

linode -> neutron: maps to
```

</Figure>

| Linode concept | Neutron equivalent | Notes |
|---|---|---|
| VPC | Network + Subnet | Linode VPC is a single object with one subnet; Neutron exposes them separately. |
| VLAN | Tenant network (no router) | Linode VLAN 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. |
| Linode public IP | PublicEphemeral or Floating IP | Linode public IPs are static while the Linode 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) | Linode VPC routes outbound through the Linode's public NIC by default; Neutron's router provides SNAT. |
| Cloud Firewall | Security Group | Allow-only, stateful; similar model. |
| Cloud Firewall attached to multiple Linodes | Security Group applied to multiple ports | Linode attaches the same Cloud Firewall ID to many Linodes; Neutron attaches the same SG to many ports. |
| NodeBalancer | Self-managed reverse proxy or external edge | Feature comparison below. |
| VPC peering | **No equivalent** | Linode VPC peering is not GA on Linode at this time; 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

Linode Cloud Firewalls and Neutron security groups share the same core model: stateful, allow-only, deny-all inbound by default, allow-all outbound by default (unless you write explicit egress rules).

| Dimension | Linode Cloud Firewall | Neutron Security Group |
|---|---|---|
| Enforcement level | Linode or NodeBalancer (resource attached) | Port (per interface) |
| Statefulness | Stateful | Stateful |
| Rule model | Allow-only | Allow-only |
| Inbound default | Deny-all (configurable) | Deny-all |
| Outbound default | Allow-all (configurable) | Allow-all |
| Source types | CIDR (IPv4 / IPv6) | CIDR, Security Group ID |

The key vocabulary difference: Linode Cloud Firewalls are attached **by resource ID** (Linode ID or NodeBalancer ID) and group rules into ingress/egress policies. Neutron uses **security group references** (`--remote-group`) to express tier-to-tier allow rules.

### 3-tier app example

**Linode source:**
- `fw-web`: inbound TCP 80, 443 from any CIDR
- `fw-app`: inbound TCP 8080 from the web tier's Linode private IPs
- `fw-db`: inbound TCP 5432 from the app tier's Linode private IPs

**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 resource-attached Cloud Firewall model with security group references.

## NodeBalancer migration

Replace NodeBalancer 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 HTTP or TCP 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

| Linode Reserved IP | Neutron Floating IP |
|---|---|
| Static, region-scoped public IPv4 | Static, region-scoped public IPv4 |
| Free while assigned to a Linode; charged when idle. See [Linode pricing](https://www.akamai.com/cloud/pricing) for current rates. | 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 Linodes 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 Linode | 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

Linode includes a free [DNS Manager](https://techdocs.akamai.com/cloud-computing/docs/dns-manager). Quake AI has no managed DNS. Migrate your zones to an external provider.

1. **Export zone file.** From the Linode Cloud Manager, export each zone as a BIND zone file (or use `linode-cli domains records-list` and convert to BIND).
2. **Lower TTLs.** Set all record TTLs to 300 seconds on Linode; 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 Linode 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 Cloud Firewall rules (compare port/CIDR combinations)
- [ ] Cloud Firewall-attached groups 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 |
|---|---|
| Transfer pool to flat egress | Linodes include a per-month transfer pool that varies by plan; overage is per-GiB. Quake AI includes bandwidth in flavor pricing with no per-GB charge. See [Linode pricing](https://www.akamai.com/cloud/pricing). |
| No resource-attached firewalls | Cloud Firewalls attach to a Linode or NodeBalancer by resource ID. Neutron requires per-port security group assignment. Use OpenTofu or Ansible to make the assignment declarative. |
| NodeBalancer is a single object | A self-managed proxy stores listeners, backend pools, and health checks in its configuration. Keep that configuration in version control and deploy it through automation. |
| No VPC peering | Linode VPC peering is not GA at this time; Quake AI has no equivalent either. Use a VPN overlay (WireGuard or IPsec on a Nova instance) for cross-network communication. |
| Public IP semantics | Linode public IPs are stable while the Linode exists. Quake AI's `PublicEphemeral` model rotates on instance recreate; for stable addressing, allocate a Floating IP from `PublicStatic`. |

## See also

- [Migrating from Linode to Quake AI](/resources/migration/from-linode): full cross-service migration hub
- [Migrate from Linode Compute Instances](/docs/compute/migration/migrate-from-linode): 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