Linode (Akamai Cloud) Explained: Compute, Storage, and Regions
Linode (Akamai Cloud) explained: account users and permissions, compute plan families, block and object storage, backups, regions, VPC and NodeBalancers, hourly billing, account limits, and SMTP restrictions.
Linode has been selling Linux virtual machines since 2003 and became part of Akamai in 2022, which is why the platform now appears as Akamai Cloud Computing while the product names, the Cloud Manager, and the API keep the Linode identity. This guide explains how a Linode account and its users are organised, what the compute plan families are, how storage, networking, and regions work, and what to know about billing, limits, and email before you build.
Accounts, users, and access
A Linode account is the billing entity. It holds the payment method, receives the monthly invoice, and owns every resource. Inside the account you create users, each with their own login, and each user is either unrestricted or restricted. An unrestricted user has full control, including billing. A restricted user is assigned global permissions (for example, can add Linodes, can add Volumes) and per-resource grants (read only, read and write, or none) on individual instances, volumes, and other objects. This makes it practical to give a contractor access to one server without exposing the rest.
Everything in the Cloud Manager is also available through the Linode API, the Linode CLI, and a Terraform provider. Personal access tokens are created per user with a chosen expiry and a scope per API area, so a deployment pipeline gets a token that can manage Linodes but not touch billing. Two-factor authentication is available per user and should be enabled on every login. Security questions and a phone number are also used for account recovery and verification.
- Account
- Billing entity that owns all resources and receives invoices
- User
- Individual login with unrestricted or restricted permissions
- Personal access token
- Scoped API credential with an expiry, created per user
- Cloud Manager
- Web console; the same actions are available in the API and CLI
Compute plans
A Linode is a virtual machine. Plans are grouped into families by CPU allocation and memory ratio:
| Family | Characteristics | Typical use |
|---|---|---|
| Shared CPU (including the 1 GB Nanode) | vCPUs shared with other tenants | Websites, small apps, staging, development, personal projects |
| Dedicated CPU | Reserved cores, no CPU contention | Production applications, CI runners, databases, game servers |
| Premium | Dedicated cores on newer CPU generations, available in select regions | Latency-sensitive production services |
| High Memory | Large memory relative to CPU | In-memory caches, analytics, memory-heavy databases |
| GPU | NVIDIA GPUs attached to the instance | Model training, inference, rendering, scientific computing |
Every plan includes local SSD storage and a monthly network transfer allowance that is pooled across all Linodes on the account. Plans can be resized up or down, though a downsize requires the disk to fit inside the smaller plan. Instances boot from distribution images (Ubuntu, Debian, AlmaLinux, Rocky Linux, Fedora, Arch, and others), from your own custom images, or from Marketplace apps that preinstall common software. StackScripts are Linode’s mechanism for running a setup script at first boot, alongside standard cloud-init user data.
Storage, images, and backups
Three storage products sit alongside the local disk on each Linode. Block Storage Volumes attach to an instance in the same region, can be resized upward, and persist after the instance is deleted. Object Storage is S3-compatible, organised into buckets in specific regions, and works with standard S3 tooling; it is the natural home for uploads, static sites, and backup archives. Images are captured disks that you can deploy as new Linodes.
The Backup Service is an optional add-on billed per Linode that takes automatic daily, weekly, and biweekly snapshots plus one manual snapshot slot. It restores whole disks rather than individual files, so treat it as a disaster recovery layer and keep application-level backups in Object Storage or off-platform as well.
Regions and networking
Linode regions span North America, Europe, Asia Pacific, and South America. Since the Akamai acquisition, the region list has expanded and newer locations are described as core compute regions, with some products, notably Premium plans and VPC, launching in newer regions first. Every resource is regional; moving a Linode between regions is done through the migration feature, which involves downtime and a new IP address.
Networking starts with a public IPv4 address and an IPv6 range on each instance. Private connectivity has several layers: VPC gives an isolated network with subnets and private addresses that do not consume transfer, VLANs provide a layer 2 private network in supported regions, and the older private IP option gives a data-center-wide private address. Cloud Firewalls apply inbound and outbound rules to instances and NodeBalancers from outside the operating system. NodeBalancers are managed load balancers for TCP, HTTP, and HTTPS with health checks and TLS termination. The DNS Manager hosts zones for your domains at no charge while you have an active Linode. Linode Kubernetes Engine (LKE) provides a managed control plane with worker nodes billed as regular Linodes.
Billing, limits, and email sending
Billing is hourly with a monthly cap per resource, invoiced at the start of each month for the previous month’s usage. New accounts are typically asked for a valid payment method at sign-up, and promotional credits, when offered, are applied against usage before the card is charged. The terms of any promotional credit are set by Akamai and change over time, so confirm them on the current page before relying on them. Transfer overage beyond the pooled allowance is billed per gigabyte.
Accounts carry limits on the number of Linodes and other resources that can be created, and new accounts start conservatively. Limit increases and access to certain plan families are requested through a support ticket, where the provider reviews the request. Some newly created accounts are also reviewed before their first resources are provisioned; this is a normal fraud-prevention step and is resolved by supplying what the provider asks for.
Outbound SMTP is restricted by default on newly created accounts: ports 25, 465, and 587 are blocked until you ask support to open them and explain your use case, and the provider decides. The Linode email sending guide describes the process and the expectations around valid reverse DNS, SPF, and DKIM. Any sending you do must comply with the acceptable use policy and anti-spam law; for most applications a dedicated email service is the safer path.
- Enable two-factor authentication for every user and give contractors restricted users rather than sharing credentials.
- Add SSH keys during creation and turn off password authentication on the server.
- Attach a Cloud Firewall before exposing any service, and open only the ports you serve.
- Watch the transfer pool in the Cloud Manager if you serve large downloads or media.
- Keep every workload within the Linode acceptable use policy; abuse complaints lead to suspension regardless of who created the account.
The full product reference is in the Linode documentation.
Where to go next
Account listings labelled with a promotional credit or with outbound port 25 already open are on the Buy Linode Accounts product page.
Related reading in the Cloud Library:
- SSH keys for cloud servers: generate, add, and rotate
- Object storage vs block storage: which one does your app need?
- Building staging and test environments in the cloud
- Port 25 and cloud email sending: why providers restrict it
Browse the full Cloud Library, or read the DigitalOcean vs Linode comparison.