Linode on Akamai Cloud: Compute Instances, Regions and Getting Started

Linode became part of Akamai in 2022, and its developer cloud now runs as Akamai Cloud (often still called Linode on Akamai Cloud). This guide explains how Compute Instances, plan types and regions fit together in Linode Akamai Cloud, and gives a step-by-step path from a new account to a working, locked-down server.

How the platform is organized #

If you used Linode before the acquisition, very little about the day-to-day workflow has changed. You still manage everything from Cloud Manager, the Linode CLI or the Linode API (version 4), and the core building block is still a virtual machine, now officially called a Compute Instance (and still commonly called “a Linode”).

What Akamai added is scale and reach. The compute platform sits alongside Akamai’s content delivery and security network, and the region footprint has expanded. For a summary of the provider as a whole, read our Linode and Akamai Cloud overview.

The main building blocks

• Compute Instances: KVM virtual machines with vCPU, RAM, SSD storage and a transfer allowance.
• Block Storage: network volumes you attach to an instance in the same region.
• Object Storage: S3-compatible buckets for files, backups and static assets.
• NodeBalancers: managed load balancers that distribute traffic across instances.
• Cloud Firewalls: network-level firewall rules applied to instances or NodeBalancers.
• VPC and VLANs: private networking between instances in a region.
• Linode Kubernetes Engine (LKE): managed Kubernetes with Compute Instances as nodes.
• Backups: an optional managed backup service per instance.

Compute Instance plan types #

Plans are grouped by how CPU and memory are allocated. Pick the category first, then the size.

A useful rule of thumb: if your workload is fine being “fast most of the time”, shared CPU is cost-effective. If it must be “equally fast all of the time”, pay for dedicated. You can resize an instance between plans later, although moving to a plan with a smaller disk requires your used disk space to fit.

Regions and where to deploy #

Akamai Cloud offers core compute regions across North America, South America, Europe, Asia-Pacific and other areas, with product availability varying by region. GPU plans, Premium CPU and some newer services are only offered in selected locations, so check the region availability table in the docs before designing around a specific product.

When choosing a region:

• Deploy close to your users, and use the speed test endpoints Akamai publishes to compare latency from your location.
• Keep instances that talk to each other in the same region so they can use VPC or VLAN private networking.
• For disaster recovery, keep a copy of critical data (for example in Object Storage) in a second region.

Understanding billing #

Compute Instances are billed hourly up to a monthly cap, so short experiments cost little. The key thing new users miss is that billing is tied to the instance existing, not to it running.

Each plan includes a network transfer allowance that is pooled across your account. Inbound traffic is free, and outbound usage above the pool is charged per GB. Exact figures change over time, so confirm them on the official pricing page rather than relying on older blog posts.

Getting started, step by step #

Step 1: Create your account the official way

Sign up directly on the official Linode or Akamai Cloud website, complete the email and payment verification, and enable two-factor authentication in your profile. Add a second user with restricted permissions for day-to-day work if more than one person needs access, rather than sharing the owner login.

Step 2: Upload an SSH key

In Cloud Manager, add your public key under your profile’s SSH keys. When you create an instance you can select it, and it will be placed in authorized_keys for the root user.

Step 3: Create the Compute Instance

1. Choose a distribution (Ubuntu LTS and Debian are common defaults) or a Marketplace app.
2. Pick the region closest to your users.
3. Select the plan type and size.
4. Set a strong root password (required even if you use keys) and select your SSH key.
5. Optionally attach the instance to a VPC and enable Backups.
6. Add a user data script (cloud-init) through the Metadata service if you want repeatable configuration on first boot.

Step 4: Apply a Cloud Firewall

Create a firewall with a default inbound policy of “Drop”, then add accept rules for the traffic you need: SSH from your own IP range, HTTP and HTTPS from anywhere, and anything internal from your VPC subnet. Attach it to the instance. Because Cloud Firewalls are applied outside the VM, they keep working even if a misconfiguration inside the OS opens a port.

Step 5: Secure the operating system

• Log in as root once, create a limited sudo user, and copy your key to it.
• Disable root SSH login and password authentication in /etc/ssh/sshd_config.
• Apply updates and enable automatic security patches.
• Set the hostname and timezone, and configure reverse DNS for the instance’s IP in Cloud Manager if you run public services.

Step 6: Know about Lish

Lish (Linode Shell) gives out-of-band console access to your instance even when networking or SSH is broken. It is your recovery path if you lock yourself out with a firewall rule. Keep your Cloud Manager account protected with 2FA, because Lish access is only as secure as that login.

Outbound email and SMTP restrictions #

New Akamai Cloud accounts have outbound SMTP ports restricted by default. This is a standard anti-abuse control: it keeps new accounts from being used to send spam, which protects the reputation of the shared IP ranges that every customer relies on.

For most applications, the best practice is to send through a transactional email service or relay rather than running a mail server on a VM. If you have a legitimate need to send directly, Akamai documents an official process: configure reverse DNS for your sending IP, then open a support ticket describing your use case so the team can review it. Our guide to SPF, DKIM and DMARC covers the DNS records you should have in place either way.

Automation and infrastructure as code #

Once the first server works, avoid building the second one by hand. Options include:

• Linode CLI: scriptable access to every API operation, handy for quick automation.
• Terraform provider: declare instances, firewalls, NodeBalancers and DNS records as code.
• StackScripts: reusable deployment scripts stored in your account.
• cloud-init via Metadata: standard user data that also works on other clouds.

Tag resources consistently (for example by environment and project) so you can filter them in Cloud Manager and attribute costs. Our cloud networking basics guide explains how VPCs, subnets and firewalls work together if you are planning a multi-tier setup.

The authoritative reference for every product is the Akamai Cloud Computing documentation, and plan specifications and rates are listed on the official pricing page.

Linode Akamai Cloud: frequently asked questions #

Is Linode still a separate company?

No. Akamai acquired Linode in 2022, and the compute platform is now offered as Akamai Cloud. Cloud Manager, the Linode API and the Linode CLI remain the main tools for managing resources.

Should I choose Shared CPU or Dedicated CPU?

Shared CPU suits websites, development and bursty workloads at a lower cost. Choose Dedicated CPU when your application needs consistent performance under sustained load, such as CI jobs or busy production services.

Am I billed when my instance is powered off?

Yes. Compute Instances are billed while they exist, regardless of power state. Delete the instance to stop charges, and remove attached volumes, backups and NodeBalancers separately.

How do I get outbound SMTP access?

Outbound SMTP is restricted on new accounts to prevent abuse. Use an email delivery service, or follow Akamai’s documented process of configuring reverse DNS and opening a support ticket that explains your use case.