The two kinds of machine, which way each can be resized, and what it costs in downtime.
A machine can be moved to another type at any time, from Resize on the machines page — to a bigger one always, and to a smaller one on a Cloud Native machine, whose disk is not part of its type.
When you configure a project you choose a machine type beside the datacentre, and it decides how the disk works. Not every datacentre sells both; where only one is offered there is nothing to choose and the question is not asked.
| Regular | Cloud Native | |
|---|---|---|
| The disk | comes with the machine | a volume of its own |
| Where it lives | on the machine, local storage | on the provider's network |
| Choosing the size | whatever the type includes | yours, from 10 GB up |
| Growing it | move to a larger type — see It is downtime below | grow the volume, machine unchanged |
| Best for | most sites | files that grow unpredictably |
Regular is the default and is what most sites want. Cores, memory and disk arrive in one plan at one price, on the fastest disk there is — a device physically in the machine. The catch is that the disk is part of the plan: more room means a bigger machine, and a bigger machine means the stop-change-start below.
Cloud Native separates the two. The machine is cores and memory; the disk is a volume attached to it. That is the one thing a regular plan cannot do, and it changes two things that matter:
Nothing comes with it, and that is the point. You are buying cores and memory; the disk is a purchase of its own, from 10 GB upwards in tens to 100 and then in fifties. It appears as its own line on the bill, and the rate falls as the disk grows — the first ten gigabytes are the dearest, because a machine keeps a fixed amount of any disk whatever its size.
The size you choose is the size your site gets. The volume underneath it is larger — a machine keeps room for the operating system, the container images, the build cache, the journal, the releases kept for rollback and the nightly database dumps held before they go offsite — but that is ours to work out, not yours to subtract. Ten gigabytes bought is ten gigabytes you can fill.
The trade is real and worth knowing before you pick it: the storage is on the provider's network, not in the machine. The included volume is built on the fastest network tier the provider sells rather than the cheapest, which is what keeps that difference off the pages your visitors wait for.
A Cloud Native machine moves both ways. Its disk is a volume of its own, so changing the cores and memory never touches it, and a machine sized for a launch that did not happen can be made smaller again. You are shown every type the provider sells in that region, with its CPU, memory and monthly price.
A regular machine only goes up. Its disk comes with the type and grows with it, and a disk is never made smaller — so once a machine has moved up, the sizes below it are gone for good. Rather than let you take that step without knowing, the list only offers the size it is on and larger, and says why.
That is the trade between the two kinds, and it is most of the reason to pick Cloud Native: not the disk itself, but being able to change your mind.
This is the part worth reading twice, because it is the opposite of growing a disk.
Moving a Regular machine, and shrinking any machine, is done with the machine off. So the sequence is:
Everything on that machine is offline for the few minutes this takes. On a single-machine environment that is the whole site. Plan it like a deploy, not like a settings change.
Growing a Cloud Native machine is the exception, where the provider allows it: the cores and memory are added while it runs, with nothing offline. Not when its disk is being grown in the same step — the filesystem cannot be extended under a running kernel. The resize dialog says which of the two is about to happen before you confirm.
A machine resizes with its role. Every machine doing the same job — the web servers behind a balancer, say — is kept at one size, because traffic is shared between them evenly and the smallest would be the ceiling. Resizing one resizes the others, one at a time, and the dialog says so first.
If the provider refuses the new type, the machine is started again at the size it was — a refused resize is not left as a machine switched off.
This section is about regular machines. On a Cloud Native machine the disk is a volume of its own and is resized separately — see above.
The disk is part of the type here, so it grows when the type does. That is the provider's behaviour and not a choice this platform makes: a larger type comes with a larger disk, and the data already on it is why nothing ever shrinks it back.
Which is why the list stops at the size the machine is on. Once it has grown, the smaller types have less disk than the machine already uses, and the provider would refuse the move after having stopped the machine for it.
If you need more room without changing the machine, buy a volume. It grows without downtime and without taking anything away.
On a dedicated plan, on either shape, you can add a worker: a machine that runs your schedule and any long-running processes instead of the web machine doing it alongside serving requests.
Worth it when background work and visitors are competing for the same CPU. The symptom is a slow site rather than a slow job, which is what makes it easy to miss — see Shapes.
It is a machine like the others: you pick its size, and it is charged like one.
The architecture. An arm machine cannot become an x86 one, because the disk image on it will not boot there — so only types of the same architecture are offered.
Storage covers disks, which is the other half of making a machine bigger, and Upgrades covers giving one service a machine of its own.