Linode after Akamai: what changed and what did not

Linode spent two decades as an independent Linux VPS provider with a reputation for straightforward pricing and unusually good documentation. Its acquisition by Akamai, and the rebranding of the platform as Akamai Connected Cloud, raised a reasonable question for existing users: is this still the same product?

Mostly yes, at the level that matters day to day. The context around it changed considerably.

What stayed the same

The virtual machine product is recognisably the same. You choose a plan with a fixed amount of vCPU, memory, storage and transfer, you pick a region, you get root access to a Linux machine. Pricing remains plan-based rather than a matrix of separately-metered dimensions, which is the single characteristic that made Linode approachable in the first place.

The transfer allowance model survived too. Each plan includes a monthly outbound transfer quota, pooled across your account. Compared with per-gigabyte egress billing, this is far easier to budget for, and it remains one of the strongest practical reasons to choose the platform.

The API and the CLI kept working. The documentation, long a genuine differentiator, is still good.

What changed

The network underneath. Akamai operates one of the largest edge networks in the world, and Linode compute now sits inside it. In practice this means better connectivity and more points of presence than an independent provider of Linode’s former size could have justified.

The product surface expanded. Managed databases, object storage, managed Kubernetes and a broader set of networking products either arrived or matured. The catalogue is no longer just virtual machines with a few extras.

The enterprise posture. Contracts, support tiers, compliance documentation and account management now look like what a large organisation expects. For a solo developer this is invisible. For a company with a procurement process it is the difference between usable and not.

The naming. Documentation, console and marketing now variously say Linode, Akamai, and Akamai Connected Cloud. This is mostly cosmetic confusion, but it does make searching for help slightly more annoying than it used to be, because results span both eras.

What this means for a decision today

If you are choosing a provider for a straightforward Linux workload, the calculus is largely unchanged and slightly improved. You get predictable plan pricing, a generous pooled transfer allowance, a clean API, and now a substantially better network.

The things that made Linode a poor fit before still apply. The service catalogue, while much larger than it was, remains far narrower than the hyperscalers. If your architecture depends on a deep managed-service ecosystem, on exotic instance types, or on a specific proprietary service, this is not where you will find it.

Sizing a Linode sensibly

The plan families are simple enough that choosing is quick.

Shared CPU plans share physical cores with other tenants. They are the best value for the great majority of workloads: web applications, small databases, development machines, anything that is not CPU-saturated for long periods.

Dedicated CPU plans give you the whole core. Worth it when sustained CPU load is the constraint, when performance consistency matters more than price, or when a benchmark shows the shared plan throttling.

High memory plans shift the ratio for caches and in-memory workloads.

The right procedure is the same as anywhere: start on a shared plan one size below your instinct, run real traffic, and watch CPU steal time alongside utilisation. Steal time is the signal that a shared plan is the constraint rather than your application.

The transfer allowance is worth planning around

Because transfer is pooled across the account, a fleet of small instances shares one large allowance. That has a design consequence: if you are running several services, keeping them on the same account gives you more headroom than splitting them across accounts.

Overage is billed per gigabyte and is easy to avoid if you know your traffic. Media-heavy sites should still put a CDN in front, both to reduce transfer and to improve delivery, but many applications never come close to the included allowance.

Practical first steps

Whether or not the platform is called Linode this week, the setup discipline is the same as any VPS. Add SSH keys at creation and disable password authentication. Configure the cloud firewall before the service listens publicly. Enable backups, which are inexpensive relative to the machine, and then actually restore one to confirm it works. Set up monitoring that runs from outside the machine.

None of that is specific to this provider, and all of it is the difference between a server and a liability.

For the vendor’s own reference on the services involved here, see the Linode documentation on Akamai TechDocs.

Questions people ask