What it adds
Twenty regions, and the ones that matter most are the ones we were thin on:
| **Asia · Pacific** | Tokyo, Singapore, Mumbai, Sydney |
| **North America** | New York, Chicago, Dallas, Atlanta, Miami, Seattle, Los Angeles, Fremont, Toronto |
| **Europe** | Amsterdam, Frankfurt, London, Stockholm |
| **South America** | São Paulo |
If you have been waiting for Tokyo, that wait is over. Akamai's network is the reason to care about the Asian locations specifically — latency into the region is genuinely good, not "technically present".
Two corrections to what this post said when it was published. Osaka is not a Linode region for us — it is available, but on Vultr; we listed it here by mistake. And Paris and Madrid were on this list until Linode paused new servers in both without telling us — we found out when a customer's deploy failed. Their side, not yours, and both are available on Vultr. The region picker in the dashboard is generated from what can actually be deployed, so it has always been right even while this page was not.
Pricing is not identical across providers
Two plans cost more on Linode than elsewhere:
| Plan | Most providers | On Linode |
|---|---|---|
| Starter (1 vCPU / 2 GB) | $18/mo | **$22/mo** |
| Standard (2 vCPU / 4 GB) | $34/mo | **$41/mo** |
Micro, Pro and Beast are the same price everywhere.
The honest reason: Linode charges us more for those two sizes than Vultr does, and we would rather show a different number than quietly earn less on one provider and make it up somewhere else. The price you see in the picker is the price you pay, and it is locked in when you deploy — a server you own never changes price, whatever we do to the list later.
If price is what matters and the region works for you, Hetzner and Vultr stay cheaper on those two plans. If you need Tokyo, Linode is the one that has it.
Nothing changes about how you use it
Same prepaid balance in the same account. No second signup, no separate payment method, no per-provider wallet. Top up once, deploy anywhere, destroy anything — billing stops the hour a server does.
The API treats it as one more value in the provider field. Scripts that deploy today keep working; you get a new option, not a migration.
Why we keep adding clouds
Capacity, mostly. Every provider caps how many instances an account may run, and those caps move slower than demand does. When one of ours fills up, the honest options are to stop selling or to have somewhere else to put the next server. We prefer the second one.
There is a reliability argument too. Providers have outages, regional maintenance and occasional bad days — one of ours had an API outage this month that stopped deployments cold for twenty minutes. Four independent networks means a bad day at one of them is an inconvenience rather than an outage for you.
One caveat worth knowing
Reverse DNS on Linode is stricter than on our other providers. Before Linode will accept a PTR record for your server, the hostname has to already resolve to that server's IP — create the A record first, wait for it to propagate, then set the rDNS from the server page. On Vultr and Hetzner you can do it in either order.
Everything else — power controls, renaming, IP rotation, backups and one-click restore — works exactly as it does elsewhere. We ran the full lifecycle against a live Linode account before opening it up, including rotating a server's IP and confirming the disk and the root password survived the move.