Migrate from Linode VPC and Cloud Firewall to Quake AI
Coming from another cloud?
▸Linode·VPC, Cloud Firewalls, NodeBalancers
VPC
- VPCs are region-scoped and isolate Linodes from the public internet and from other customers; OpenStack networks are project-scoped Neutron networks.
- A VPC contains one or more subnets, each with a CIDR block defined at create time; routing between subnets is implicit within the VPC.
- Linodes attach to a VPC by configuration interface rather than via Neutron ports; trunking is not the same model.
- VLANs and VPCs are distinct products; OpenStack collapses these into Neutron network types (vlan, vxlan, geneve).
Cloud Firewalls
- Cloud Firewalls are a managed stateful firewall service attached to Linodes and NodeBalancers; OpenStack uses Neutron security groups per port.
- Rules are evaluated as inbound and outbound policy sets per firewall, not as additive security group memberships.
- Default policy can be set to ACCEPT or DROP per direction at the firewall level; OpenStack security groups default-deny inbound.
- Cloud Firewalls are free; OpenStack security groups are also free but have different rule semantics (port + protocol + remote group).
NodeBalancers
- NodeBalancers are a managed L4/L7 load balancer product. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
- A NodeBalancer contains one or more port and protocol configurations plus backend nodes. Self-managed Quake AI edges define listeners and upstreams in proxy or ingress configuration.
- NodeBalancers configure TLS termination with an inline certificate and key. Quake AI users manage TLS on the self-managed edge.
- Linode prices NodeBalancers separately. Size the compute used by a self-managed Quake AI edge instead.
Migrate from Linode VPC and Cloud Firewall to Quake AI
Linode (now branded Akamai Cloud Computing) exposes a compact networking surface: a VPC that bundles a network and a single subnet, a free intra-region L2 VLAN for private traffic, a stateful Cloud Firewall, Reserved IPs for stable public addressing, and the NodeBalancer for L4/L7 load balancing. Quake AI's OpenStack Neutron provides explicit networks, subnets, routers, floating IPs, and security groups. Replace NodeBalancer with a reverse proxy or external edge service.
Service mapping#
Linode to Quake AI
| Linode service | Quake AI equivalent | Key difference |
|---|---|---|
| Additional IPv4 addresses | Floating IPs | Linode does not model this as a separate Neutron floating IP pool resource. The canonical guide describes adding, deleting, transferring,... see details |
| Allow public IPv4 access (1:1 NAT) | NAT | Linode exposes this as a per-VPC-interface option called Allow public IPv4 access (1:1 NAT), not as a standalone managed NAT gateway... see details |
| NodeBalancers | Network | NodeBalancers are a managed L4/L7 load balancer product. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer... see details |
| VPC | Networks | VPCs are region-scoped and isolate Linodes from the public internet and from other customers; OpenStack networks are project-scoped Neutron... see details |
| interfaces | Ports | Linode does not expose a standalone Neutron-style port object; the documented network interface model is per-Linode, and interfaces are... see details |
| Cloud Firewalls | Security Groups | Akamai/Linode Cloud Firewalls are the supported managed firewall product; there is no separate Neutron FWaaS-style abstraction. Each... see details |
Prerequisites#
- A Quake AI account with application credentials
- The OpenStack CLI 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.
| 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#
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#
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 CIDRfw-app: inbound TCP 8080 from the web tier's Linode private IPsfw-db: inbound TCP 5432 from the app tier's Linode private IPs
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 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 for current rates. | Public IPs (used for Floating IPs) are an add-on; dedicated-vCPU plans include one. See the pricing model. |
| 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:
openstack floating ip create PublicStatic
openstack server add floating ip MY_INSTANCE FLOATING_IP_ADDRESSDNS cutover#
Linode includes a free DNS Manager. Quake AI has no managed DNS. Migrate your zones to an external provider.
- Export zone file. From the Linode Cloud Manager, export each zone as a BIND zone file (or use
linode-cli domains records-listand convert to BIND). - Lower TTLs. Set all record TTLs to 300 seconds on Linode; 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 Linode 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 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. |
| 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: full cross-service migration hub
- Migrate from Linode Compute Instances: 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.