# Coming from Linode (Akamai Cloud Computing)

Source: https://docs.quake.ai/docs/platform/migration/coming-from-linode
Markdown: https://docs.quake.ai/docs/platform/migration/coming-from-linode.md

---

# Coming from Linode (Akamai Cloud Computing)

If you have been running on Linode (now branded **Akamai Cloud Computing**), you already know the primitives: **Linodes** (VMs), **NodeBalancers** (load balancers), **Block Storage Volumes**, **Object Storage** (S3-compatible), **VPC** and **VLAN**, **Cloud Firewalls**, and **Linode Kubernetes Engine (LKE)**. Quake AI exposes compute, storage, networking, and Kubernetes through standard OpenStack services. See [How Quake AI uses OpenStack](/docs/platform/migration/openstack) for the full project map. The biggest conceptual shift is from Linode's single-resource API surface to OpenStack's explicit projects: networks, subnets, and routers are independent objects you wire together, not abstractions hidden behind a Linode object.

## Quick reference

| Linode (Akamai) | Quake AI | OpenStack project | Key difference |
|---|---|---|---|
| Linode (Compute Instance) | Instance | Nova | Linode publishes fixed plans (Shared CPU, Dedicated CPU, High Memory, Premium); Quake AI uses the `m2a`/`c2a`/`r2a`/`s1a` flavor families ([Flavors](/docs/compute/concepts/flavors)). |
| Block Storage Volume | Volume | Cinder | Both NVMe-backed; same attach model. Linode caps volume size at 16 TiB; Quake AI Cinder limits are documented in [Block Storage limits](/docs/block). |
| Object Storage Bucket | Container | Swift | Both expose an S3-compatible API. Endpoint and credentials change; SDK code does not. |
| VPC | Network | Neutron | Linode VPC abstracts subnets and routing into a single API object; Neutron exposes **networks**, **subnets**, and **routers** explicitly. |
| VLAN | Network (provider VLAN segment) | Neutron | Linode VLAN is a free private L2 inside a region; on Quake AI use a Neutron tenant network for the same role. |
| Cloud Firewall | Security Group | Neutron | Linode Cloud Firewall is attached to a Linode or NodeBalancer; Neutron security groups attach to instance ports. |
| NodeBalancer | Self-managed edge proxy or API gateway | Nova + Neutron | Translate routes, backends, and health checks into Caddy, SafeLine, or APISIX. |
| Floating reserved IP | Floating IP | Neutron | Same concept; Quake AI Floating IPs are allocated from `PublicStatic` and attached to a port via DNAT on a router. |
| SSH Key | Key Pair | Nova | Direct equivalent. |
| LKE Cluster | Kubernetes Cluster | Magnum | LKE auto-scales nodes and manages upgrades; Magnum workers are self-managed Nova instances. Self-managed RKE2 or k3s on Nova is also documented as an alternative. See [migrate from LKE](/docs/kubernetes/migration/migrate-from-lke). |

## Compute: Linodes → instances

**What maps directly.** You still pick an image, a region, a plan, and SSH keys. Quake AI instances are backed by [OpenStack Nova](https://docs.openstack.org/nova/latest/) and are provisioned through the Cloud Console, the OpenStack CLI, or the Nova API.

**What is different.** Linode's plan families (Shared CPU, Dedicated CPU, High Memory, Premium, GPU) are documented at [How to choose a Compute Instance plan](https://techdocs.akamai.com/cloud-computing/docs/how-to-choose-a-compute-instance-plan). Quake AI exposes four flavor families:

- `m2a`: general purpose, 4 GiB RAM per vCPU
- `c2a`: compute-optimized, 2 GiB RAM per vCPU
- `r2a`: memory-optimized, 8 GiB RAM per vCPU
- `s1a`: shared, 1-2 GiB RAM per vCPU

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 bills hourly with a monthly cap. Quake AI has no separate egress charge.

## Block storage: Linode Block Storage → Cinder volumes

Both products are NVMe-backed network block devices that attach to a single instance at a time. The data path is the same: you create the volume, attach it to an instance, partition and mount the device. Linode exposes Block Storage through the `/v4/volumes` API and the Cloud Manager; on Quake AI you use `openstack volume create` and `openstack server add volume`. See [Block Storage](/docs/block). The migration path is rebuild-and-rsync: provision a Cinder volume on the target, attach to the new instance, and copy with `rsync` over SSH.

## Object storage: Linode Object Storage → Swift

Linode Object Storage and Quake AI Object Storage are both S3-compatible. Standard tooling (`rclone`, `aws-cli`, `s3cmd`, `mc`, `boto3`) works against both endpoints with no code change. The data migration is an endpoint swap and an `rclone sync` from the Linode bucket to the Quake AI container. See [migrate from Linode Object Storage](/docs/object/migration/migrate-from-linode).

Differences to plan for:

- **Endpoint format.** Linode endpoints follow `<region>.linodeobjects.com`; Quake AI uses the Object Storage endpoint documented in your project credentials.
- **Lifecycle and policy features.** S3 lifecycle rules, bucket policies, and event notifications are not part of the Swift backend. If you depend on these, see the [S3 feature compatibility matrix](/docs/object/migration/plan-your-migration#s3-feature-compatibility).
- **No egress charges** on Quake AI; Linode includes a monthly transfer pool that varies by plan.

## Networking: Linode VPC + VLAN + Cloud Firewall → Neutron

This is the largest conceptual shift. Linode's [VPC](https://techdocs.akamai.com/cloud-computing/docs/vpc) is a single API object that hides subnet allocation and routing; subnets are an attribute of the VPC. On Quake AI you build the topology from independent Neutron objects:

- **Network.** L2 broadcast domain (OVN-backed VXLAN).
- **Subnet.** IP range with DHCP and gateway, attached to a network.
- **Router.** L3 gateway. SNAT outbound; DNAT inbound via floating IPs.
- **Floating IP.** Static public IPv4 allocated from `PublicStatic` and bound to a port.
- **Security Group.** Stateful, allow-only, per-port. The equivalent of a Linode Cloud Firewall.

The Linode VLAN (a free intra-region private L2) has no special equivalent; you use a normal Neutron tenant network. See [migrate from Linode VPC](/docs/network/migration/migrate-from-linode-vpc).

## Load balancing: NodeBalancers to a self-managed edge

Linode [NodeBalancers](https://techdocs.akamai.com/cloud-computing/docs/create-a-nodebalancer) cover TCP, limited UDP, and HTTP/HTTPS. On Quake AI, run 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) on a VM with a floating IP. Translate NodeBalancer configs into proxy routes, backend lists, and application health checks. Choose an external service or software appliance for UDP and other protocol-specific requirements.

## Kubernetes: LKE to Magnum

**What maps directly:** You still get a Kubernetes API, worker nodes, and cluster-scoped resources. Clusters are provisioned through [OpenStack Magnum](https://docs.openstack.org/magnum/latest/), which selects a **cluster template** the way LKE selects a Kubernetes version and node pool profile.

Kubernetes Services with `type: LoadBalancer` keep the same workload-facing contract after migration. The cluster provisions the public endpoint without exposing a tenant-managed load balancer service.

**What is different:** LKE manages node pools, offers auto-scaling, and keeps the control plane fully hands-off. Magnum gives you a **managed control plane** from the template, but **worker nodes are Nova instances** you size, patch, and scale: there is **no built-in node auto-scaling** in the same shape as LKE. The platform also documents **self-managed RKE2 or k3s on Nova instances** as an alternative for teams that need a custom CNI, custom kubelet flags, custom CRI, or a Kubernetes version outside the template catalog.

**Operations:** You plan capacity, upgrades, and add-ons with OpenStack and Kubernetes APIs both in play. Cluster operations and templates are covered in [Kubernetes](/docs/kubernetes). For cluster migration steps, see [migrate from LKE](/docs/kubernetes/migration/migrate-from-lke).

## Self-managed services and deployment patterns

Be honest about the gaps before you plan a migration:

- **Linode Managed Databases** (PostgreSQL, MySQL). Quake AI has no managed database. Run Postgres or MySQL on a Nova instance with Cinder-backed data volumes, or use an external managed DB provider over the public internet.
- **Linode Backups** (per-Linode managed snapshots). Use [Cinder volume snapshots](/docs/block) and `openstack server image create` for instance images.
- **DDoS protection / Cloud Firewall at the edge.** Quake AI offers per-instance Neutron security groups; there is no equivalent of Akamai's edge DDoS mitigation in the Quake AI product surface.

## Next steps

- Read [migrate from Linode](/docs/platform/migration/from-linode) for the overall migration workflow.
- Inventory your Linodes, Volumes, Object Storage buckets, NodeBalancers, VPCs, Cloud Firewalls, and LKE clusters before you start.
- Use the [OpenStack mapping page](/docs/platform/migration/openstack) to translate any Linode API calls in your tooling to the equivalent OpenStack project.