# Migrating from Linode (Akamai Cloud Computing) to Quake AI Source: https://docs.quake.ai/docs/platform/migration/from-linode Markdown: https://docs.quake.ai/docs/platform/migration/from-linode.md --- # 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](/docs/platform/migration/coming-from-linode) for the full mapping table. ## Before you migrate - Read the [concept-translation guide](/docs/platform/migration/coming-from-linode) 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](https://techdocs.akamai.com/cloud-computing/changelog) 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](/docs/network/migration/migrate-from-linode-vpc). - **LKE strategy.** Quake AI provisions Kubernetes through [Magnum](/docs/kubernetes) 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](/docs/kubernetes/migration/migrate-from-lke) for both paths. ### 2. Account setup Create your Quake AI project, generate application credentials, and install the OpenStack CLI. - [Quickstart](/docs/quickstart) - [Generate application credentials](/docs/platform/access/generate-app-credentials) - [Access & Credentials](/docs/platform/access/) for the OpenStack CLI Keep the [Linode API reference](https://techdocs.akamai.com/linode-api/reference/api) and the [Linode CLI](https://github.com/linode/linode-cli) handy on the source side; you will use them to enumerate the resources you migrate. ### 3. Object storage [Linode Object Storage](https://techdocs.akamai.com/cloud-computing/docs/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 `.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](/docs/object/migration/plan-your-migration#s3-feature-compatibility) 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](/docs/object/migration/migrate-from-linode). ### 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](/docs/network/migration/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](/docs/compute/migration/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](/build/iac-templates/edge-reverse-proxy), [edge WAF](/build/iac-templates/edge-waf), or [API gateway](/build/iac-templates/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](/docs/kubernetes): `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](https://github.com/kubernetes/cloud-provider-openstack) 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](/docs/kubernetes/migration/migrate-from-lke). ### 9. Infrastructure as code (Linode provider → openstack provider) If you use OpenTofu or Terraform with the [linode provider](https://registry.terraform.io/providers/linode/linode/latest), the migration is a provider swap (`linode/linode` -> `terraform-provider-openstack/openstack`) and a resource rename. Full procedure: [Migrate from Linode automation](/docs/automation/migration/from-linode). ### 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](/docs/platform/migration/coming-from-linode): concept translation - [How Quake AI uses OpenStack](/docs/platform/migration/openstack): project-level mapping - [Migration Explorer](/docs/platform/migration): interactive comparison table