# Migrate from Linode compute instances to Quake AI compute

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

---

# 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

<MigrationTable provider="linode" service="compute" />

## Prerequisites

- A Quake AI account with [application credentials](/docs/tools/generate-app-credentials)
- The [OpenStack CLI](/docs/tools/install-openstack-client) 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](https://techdocs.akamai.com/cloud-computing/docs/migrate-to-a-new-data-center) 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](https://techdocs.akamai.com/cloud-computing/docs/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:

| Linode plan family | Quake AI flavor family | RAM-per-vCPU ratio | Notes |
|---|---|---|---|
| Shared CPU (Nanode, Linode 2 GB, etc.) | `s1a` | 1-2 GiB | Smallest shared sizes; cheapest entry point on both. |
| Shared CPU (larger general-purpose) | `m2a` | 4 GiB | General-purpose web/app workloads. |
| Dedicated CPU | `m2a` or `c2a` | 4 GiB or 2 GiB | `c2a` is the compute-optimized choice (2 GiB RAM per vCPU); use `m2a` when you also need more RAM. |
| High Memory | `r2a` | 8 GiB | Direct fit. Cinder volumes provide additional disk for in-memory workload spillover. |
| Premium | `m2a` (or `c2a` for CPU-bound) | 4 GiB or 2 GiB | Pick the closest ratio match for your workload. |
| GPU (RTX/A100) | No equivalent today | n/a | Quake AI does not currently expose GPU flavors. Plan a rebuild on non-GPU hardware or use an external GPU provider. |

Pick the closest Quake AI flavor by vCPU count and RAM-per-vCPU ratio. See [Flavors](/docs/compute/concepts/flavors) for the full list.



Linode bills hourly with a monthly cap; Quake AI uses fixed monthly plans tied to a resource tier, plus a small list of per-resource add-ons (see the [pricing model](/docs/platform#pricing)). Linode's transfer pool varies by plan; Quake AI has no separate egress charge.



## 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:

```bash
docker push registry.example.com/MY_APP:latest
```

2. Provision a Nova instance on Quake AI:

```bash
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
```

3. Install Docker and deploy:

```bash
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:

```bash
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
```

2. Assign a Floating IP:

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

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

4. Transfer application data:

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

5. Migrate databases:

```bash
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

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

### Translate Linode Cloud Firewalls to security groups

[Linode Cloud Firewalls](https://techdocs.akamai.com/cloud-computing/docs/cloud-firewall) 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:

```bash
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:

```bash
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

| Topic | Detail |
|---|---|
| Billing for powered-off Linodes | Linode bills hourly while a Linode exists, regardless of power state; only deletion stops billing. Plan the cutover window so you delete the source Linode promptly after validating the Quake AI instance. |
| Linode-only image migrate | Linode's [data-center migrate](https://techdocs.akamai.com/cloud-computing/docs/migrate-to-a-new-data-center) tool is Linode-to-Linode and cannot target OpenStack. |
| Managed services | **Linode Managed Databases** (PostgreSQL, MySQL) and **Linode Backups** have no managed equivalent on Quake AI. Run Postgres/MySQL on a Nova instance with a Cinder data volume; replace Backups with `openstack server image create` and Cinder volume snapshots. |
| GPU plans | Linode GPU plans (RTX 4000 Ada, A100) have no Quake AI equivalent. |
| Linode CLI | Keep the [Linode CLI](https://github.com/linode/linode-cli) installed during the cutover to enumerate source resources; see also [linode-cli getting started](https://techdocs.akamai.com/cloud-computing/docs/getting-started-with-the-linode-cli). |

## See also

- [Migrating from Linode to Quake AI](/resources/migration/from-linode): full cross-service migration hub
- [Coming from Linode](/resources/migration/coming-from-linode): concept translation reference
- [Create an instance](/docs/compute/how-to/create-instance): full instance provisioning workflow
- [Compute migration guides](/docs/compute/migration): all provider guides