Migrating from Linode (Akamai Cloud Computing) to Quake AI

This guide walks you through moving workloads from Linode (now branded Akamai Cloud Computing) to Quake AI, service by service. The two platforms share a self-managed ethos, so most migrations are a translation of API calls and a remap of resource names. Networking and Kubernetes are the largest shifts.

If you have not reviewed the concept differences yet, start with Coming from Linode for the full mapping table.

Before you migrate#

• Read the concept-translation guide for how Linode services map to Quake AI.
• Inventory your Linode resources end to end: Linodes (Compute Instances), Block Storage Volumes, Object Storage buckets, VPCs (and VLANs), Cloud Firewalls, NodeBalancers, reserved IPs, and LKE clusters.
• Identify managed-service dependencies that need self-managed alternatives on Quake AI: Linode Managed Databases (PostgreSQL, MySQL), Linode Backups (per-instance managed snapshots), and LKE itself. Each of these maps to a self-managed pattern on Nova instances.
• Decide your sequencing: object storage first (cheapest to move and easiest to validate), then networking, then compute, then Kubernetes.

Migration phases#

1. Evaluate and plan#

Inventory the seven Linode primitives. For each one, note the region, plan or volume size, attached resources, and any managed-service dependencies. Linode's release notes are useful for confirming the current feature set on the source side; do not migrate on stale assumptions.

The two biggest decisions to make upfront:

• VPC topology. Linode VPC collapses subnets and routing behind a single API object. On Quake AI you choose between PublicEphemeral (DHCP-assigned public IP, no router) and PublicStatic (private network + Neutron router + Floating IP). Production migrations should target PublicStatic; see migrate from Linode VPC.
• LKE strategy. Quake AI provisions Kubernetes through Magnum from a curated cluster template; pick that path for the closest LKE-like experience. For teams that need a custom CNI, custom kubelet flags, custom CRI, or a Kubernetes version outside the template catalog, self-managed RKE2 or k3s on Nova is documented as an alternative. See migrate from LKE for both paths.

2. Account setup#

Create your Quake AI project, generate application credentials, and install the OpenStack CLI.

• Quickstart
• Generate application credentials
• Access & Credentials for the OpenStack CLI

Keep the Linode API reference and the Linode CLI handy on the source side; you will use them to enumerate the resources you migrate.

3. Object storage#

Linode Object Storage is S3-compatible. The transfer is an endpoint swap and an rclone sync from Linode to Quake AI Object Storage (Swift with the S3 gateway).

Plan for these differences:

• Endpoint format. Linode uses <region>.linodeobjects.com; Quake AI exposes the Swift endpoint listed in your project credentials.
• Lifecycle and bucket policies. The Swift backend does not implement every S3 lifecycle and policy feature. Confirm against the S3 feature compatibility matrix before you cut over.
• Egress. Quake AI has no egress fee; budget Linode's transfer pool for the one-time sync only.

Full procedure: Migrate from Linode Object Storage.

4. Networking (VPC and Cloud Firewalls)#

Translate the Linode VPC to explicit Neutron objects (network, subnet, router) and the Cloud Firewall to Neutron security groups attached to instance ports. Reserved IPs map to Floating IPs on PublicStatic. Full procedure: Migrate from Linode VPC.

5. Compute (Linodes → Nova instances)#

The recommended path is rebuild and rsync: provision a Quake AI flavor that matches your Linode plan, install your application stack with your existing configuration management, and transfer data with rsync. Linode image export is limited; Akamai does not publish a generic raw-disk export path that imports cleanly into Glance, and disk-image compatibility (cloud-init datasource, kernel choice, drivers) is often imperfect even when an image is available.

Full procedure: Migrate from Linode (compute).

6. Load balancing (NodeBalancers to a self-managed edge)#

Translate each NodeBalancer into routes, backend lists, and health checks on an edge reverse proxy, edge WAF, or API gateway. Provision a floating IP for the edge VM. Choose an external service or software appliance for UDP and other protocol-specific requirements.

7. Block storage (Linode Volumes → Cinder volumes)#

Provision a Cinder volume that matches the source size, attach it to the new instance, partition and mount, then rsync the data over SSH. Cinder volumes are NVMe-backed (StorageClass cinder-flash on Kubernetes).

8. Kubernetes (LKE to Magnum, or self-managed on Nova)#

Provision your target cluster on Quake AI. The primary path is Magnum: openstack coe cluster create builds the control plane, workers, security groups, and load-balanced API endpoint from a curated template. Self-managed RKE2 or k3s on Nova is the alternative when you need a custom CNI, kubelet flags, CRI, or a Kubernetes version outside the template catalog; that path uses the openstack-cloud-controller-manager and the Cinder CSI driver. Restore workloads via Helm charts or kubectl apply; for stateful data, use velero (with the Restic plugin) or migrate the underlying PersistentVolumes with rsync from a debug pod.

Full procedure: Migrate from LKE.

9. Infrastructure as code (Linode provider → openstack provider)#

If you use OpenTofu or Terraform with the linode provider, the migration is a provider swap (linode/linode -> terraform-provider-openstack/openstack) and a resource rename. Full procedure: Migrate from Linode automation.

10. Validate and cut over#

• Verify each application responds correctly on the Quake AI side.
• Point DNS at the new Floating IPs (or behind your edge / CDN of choice).
• Confirm monitoring, alerting, and backups are in place on the Quake AI side before decommissioning Linode resources.

See also#

• Coming from Linode: concept translation
• How Quake AI uses OpenStack: project-level mapping
• Migration Explorer: interactive comparison table