Coming from Linode (Akamai Cloud Computing)
Coming from another cloud?
▸Linode·s (Compute Instances), Block Storage Volumes, Object Storage (S3 API), VPC, Cloud Firewalls, NodeBalancers, Kubernetes Engine (LKE) Cluster
Linodes (Compute Instances)
- Provisioned via the Linode API v4 (/v4/linode/instances) instead of OpenStack Nova /v2.1/servers; auth is a Personal Access Token rather than a Keystone token.
- Plan selection is fixed (Shared, Dedicated, High Memory, Premium, GPU, Accelerated) with predefined vCPU/RAM/storage; OpenStack flavors can be cloud-defined.
- Billing is hourly with a monthly cap per plan; powered-off Linodes continue to bill until deleted, unlike pause/suspend semantics common in OpenStack stop-billing setups.
- Distribution images and StackScripts are first-class; OpenStack uses Glance images and arbitrary userdata.
Block Storage Volumes
- Managed via /v4/volumes on the Linode API; OpenStack uses Cinder /v3/{project_id}/volumes.
- Volumes are region-scoped and cannot move between data centers without detach + recreate; OpenStack Cinder volumes are likewise AZ-scoped but the explicit no-cross-region migration is documented at Akamai.
- Size increases only (no shrink); same restriction exists on OpenStack but Linode enforces it as a hard API rule.
- Throughput and IOPS limits are plan-implicit and not separately tunable per volume.
VPC
- VPCs are region-scoped and isolate Linodes from the public internet and from other customers; OpenStack networks are project-scoped Neutron networks.
- A VPC contains one or more subnets, each with a CIDR block defined at create time; routing between subnets is implicit within the VPC.
- Linodes attach to a VPC by configuration interface rather than via Neutron ports; trunking is not the same model.
- VLANs and VPCs are distinct products; OpenStack collapses these into Neutron network types (vlan, vxlan, geneve).
Cloud Firewalls
- Cloud Firewalls are a managed stateful firewall service attached to Linodes and NodeBalancers; OpenStack uses Neutron security groups per port.
- Rules are evaluated as inbound and outbound policy sets per firewall, not as additive security group memberships.
- Default policy can be set to ACCEPT or DROP per direction at the firewall level; OpenStack security groups default-deny inbound.
- Cloud Firewalls are free; OpenStack security groups are also free but have different rule semantics (port + protocol + remote group).
NodeBalancers
- NodeBalancers are a managed L4/L7 load balancer product. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
- A NodeBalancer contains one or more port and protocol configurations plus backend nodes. Self-managed Quake AI edges define listeners and upstreams in proxy or ingress configuration.
- NodeBalancers configure TLS termination with an inline certificate and key. Quake AI users manage TLS on the self-managed edge.
- Linode prices NodeBalancers separately. Size the compute used by a self-managed Quake AI edge instead.
Object Storage (S3 API)
- Linode Object Storage is S3-compatible by design; the S3 API is the primary programmatic surface, not Swift.
- Access keys are managed in Cloud Manager and scoped per-bucket; OpenStack Swift uses tempauth or Keystone tokens.
- Bucket regions are explicit and presented as endpoint hostnames per cluster.
Linode Kubernetes Engine (LKE) Cluster
- LKE provides a fully managed control plane (free Standard tier or paid Enterprise tier with HA and SLA); on Quake AI you provision the cluster through Magnum or self-managed Kubernetes on Nova instances (OpenTofu plus kubeadm, k3s, or RKE2) and operate it yourself.
- LKE clusters are created and managed through the Linode API or Cloud Manager with a single cluster object. Quake AI offers Magnum as a managed-cluster API, or you can compose a cluster from compute instances, a private network, a CNI, and a self-managed control-plane endpoint.
- LKE ships an integrated linode-cloud-controller-manager and linode-blockstorage CSI driver out of the box; on Quake AI you install openstack-cloud-controller-manager and the Cinder CSI driver yourself.
- LKE node pools auto-recycle when you upgrade the Kubernetes version; Quake AI node lifecycle is managed by you (OpenTofu replace, manual drain, or cluster API operator).
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 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). |
| 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. |
| 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. |
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 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. Quake AI exposes four flavor families:
m2a: general purpose, 4 GiB RAM per vCPUc2a: compute-optimized, 2 GiB RAM per vCPUr2a: memory-optimized, 8 GiB RAM per vCPUs1a: 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); 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. 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.
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.
- 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 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
PublicStaticand 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.
Load balancing: NodeBalancers to a self-managed edge#
Linode NodeBalancers cover TCP, limited UDP, and HTTP/HTTPS. On Quake AI, run an edge reverse proxy, edge WAF, or 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, 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. For cluster migration steps, see 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 and
openstack server image createfor 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 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 to translate any Linode API calls in your tooling to the equivalent OpenStack project.
Usage Guidelines
The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.
Comparisons to third-party providers in this material reflect publicly documented behavior as of the validation date below. Pricing, quotas, service limits, and feature availability change frequently on every cloud. Verify provider-specific claims against the provider's own current documentation before relying on them for a procurement, architecture, or migration decision.
For the full policy, see Usage Guidelines.