Migrate from Linode compute instances to Quake AI compute

This guide covers migrating compute workloads from Linode (now branded Akamai Cloud Computing) to Quake AI (OpenStack Nova). Linode's image and snapshot tools are designed for intra-Linode portability and do not export to a format Glance can import directly. The reliable path is rebuild and rsync. Linode users typically provision from public images with configuration management (cloud-init, Ansible, shell scripts), which makes rebuild the natural fit.

Service mapping#

Prerequisites#

• A Quake AI account with application credentials
• The OpenStack CLI installed and configured
• SSH access to your Linode instances
• An SSH key pair imported to Quake AI (openstack keypair create --public-key)

Image portability#

Linode supports custom images (private images), generated from a disk on an existing Linode and limited to Linode-region targets. Images do not export to a format that imports cleanly into OpenStack Glance, and Linode's intra-data-center migrate workflow is also a Linode-to-Linode tool.

Recommendation: do not attempt image export. Linode servers are typically provisioned from public Akamai images with config management; rebuild is the right approach.

Plan mapping#

Linode publishes four plan families: Shared CPU (shared vCPU, general purpose), Dedicated CPU (dedicated vCPU, CPU-bound workloads), High Memory (8 GiB RAM per vCPU and up), and Premium (newer-generation hardware, dedicated vCPU). The current sizes per family are documented at How to choose a Compute Instance plan; confirm the exact vCPU and RAM of your Linode in the Cloud Manager before mapping, since plan SKUs are added and renamed over time.

The Quake AI flavor families map onto the Linode families as follows:

Pick the closest Quake AI flavor by vCPU count and RAM-per-vCPU ratio. See Flavors for the full list.

Migration approach#

Option 1: Containerized workloads (recommended)#

If your Linode runs Docker containers, migrate the container images and redeploy.

1. Push images to a portable registry:

docker push registry.example.com/MY_APP:latest

1. Provision a Nova instance on Quake AI:

openstack server create \
  --image "Ubuntu-22.04" \
  --flavor m2a.xlarge \
  --network MY_NETWORK \
  --key-name MY_KEY \
  --security-group MY_SECURITY_GROUP \
  MY_INSTANCE_NAME

1. Install Docker and deploy:

ssh ubuntu@FLOATING_IP
sudo apt update && sudo apt install -y docker.io
sudo docker pull registry.example.com/MY_APP:latest
sudo docker run -d -p 80:8080 registry.example.com/MY_APP:latest

Option 2: Rebuild and rsync (non-containerized)#

1. Provision a Nova instance with the same base OS:

openstack server create \
  --image "Ubuntu-22.04" \
  --flavor m2a.xlarge \
  --network MY_NETWORK \
  --key-name MY_KEY \
  --security-group MY_SECURITY_GROUP \
  MY_INSTANCE_NAME

1. Assign a Floating IP:

openstack floating ip create PublicStatic
openstack server add floating ip MY_INSTANCE_NAME FLOATING_IP

1. Install your application stack. Replay Ansible playbooks, cloud-init configs, or provisioning scripts.

2. Transfer application data:

rsync -avz --progress -e "ssh -i ~/.ssh/MY_KEY" \
  root@LINODE_IP:/path/to/app/data \
  ubuntu@FLOATING_IP:/path/to/app/data

1. Migrate databases:

pg_dump -h LINODE_IP -U MY_USER MY_DATABASE | \
  psql -h FLOATING_IP -U MY_USER MY_DATABASE

Key pair and security setup#

Import your SSH key#

openstack keypair create --public-key ~/.ssh/id_ed25519.pub my-key

Translate Linode Cloud Firewalls to security groups#

Linode Cloud Firewalls attach to a Linode or NodeBalancer and define ingress and egress rules. Neutron security groups apply per instance port and are allow-only (no explicit DROP rules). Translate your inbound rules:

openstack security group create web-tier
openstack security group rule create web-tier \
  --protocol tcp --dst-port 22 --remote-ip 0.0.0.0/0
openstack security group rule create web-tier \
  --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0
openstack security group rule create web-tier \
  --protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0

Linode Cloud Firewall outbound rules: Neutron security groups have egress rules too; by default a fresh security group has an allow-all egress rule. Restrict egress explicitly if your Cloud Firewall did.

Block Storage Volume migration#

If your Linodes have attached Block Storage Volumes, provision an equally sized Cinder volume on Quake AI, attach it to the new instance, format and mount it, then rsync the data:

openstack volume create --size 100 my-data-vol
openstack server add volume MY_INSTANCE_NAME my-data-vol
# on the instance:
sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /mnt/data && sudo mount /dev/vdb /mnt/data
rsync -avz --progress -e ssh root@LINODE_IP:/mnt/data/ /mnt/data/

Validation checklist#

After migrating each workload, verify:

• Application responds correctly on the Quake AI instance
• All expected ports are accessible through the security group
• Data integrity: compare file checksums or row counts between source and destination
• Database connectivity from the application to any migrated databases
• DNS records updated to point to the new Quake AI Floating IP
• Monitoring in place (self-managed Prometheus + Grafana)
• cloud-init or configuration management runs cleanly on the new instance
• SSL/TLS certificates installed and renewed

Provider-specific gotchas#

See also#

• Migrating from Linode to Quake AI: full cross-service migration hub
• Coming from Linode: concept translation reference
• Create an instance: full instance provisioning workflow
• Compute migration guides: all provider guides