Skip to main content
On v2 a sandbox’s memory is a property of the image it launches from, not a parameter of the launch. The platform has no memory or vCPU field on the create call at all — the only knob is the memory declared when an image is published. Two consequences follow, and they explain everything else on this page: the set of sizes is a fixed list rather than any number you like, and a size cannot change after launch.

​
Sizes the platform supports

Memory belongs to the image, so a size exists only if we have published an image for it. The sizes mirror the current runtime’s tiers as closely as the platform allows:
These are steps, not a range. 3072 is not a size — a tier is either published or it is not, and nothing in between exists.
The one gap is 16 GB. If you run 16 GB sandboxes today, that work has to fit in 8 GB or be split before you migrate — memory cannot be raised after launch either. See Prepare to migrate.

​
Disk

Disk is fixed at roughly 16 GB and is not configurable. It comes from the image, the same way memory does.
diskMB is accepted by the create API and has no effect — asking for 64 GB returns 201 and gives you the standard ~16 GB. Do not rely on it.
This is smaller than the current runtime’s 20 GB default, and much smaller than the 256 GB ceiling it allows. If any workload needs more disk than 16 GB, it needs somewhere else to put the data — object storage, or a service it streams from — before you migrate. Roughly 14 GB of the 16 GB is free on a fresh sandbox; the rest is the base image.

​
Which sizes are available to you

Every size above is possible; which ones are published in your region is configuration. A region typically publishes the default and a subset of the others. There is no endpoint that lists them. The reliable way to find out is to ask for one — an unavailable size is refused with the list of sizes that region actually offers:
That is a 400, not a 503. The request names something the region cannot serve, so retrying never helps — as opposed to a real capacity shortage, which is reported separately and is worth retrying.
If a size in the supported enum is not published in your region and you need it, ask us — that is a matter of publishing another image, and it is quick. A size outside the enum is not.

​
Choosing one

Omitting memoryMB gives you the default. That is also the fastest option:
Only the default size is kept warm. Every other size cold-launches from its own image, which takes a few seconds rather than the sub-second create you get from the pool.
Warm stock is per-image, so pooling every size would either multiply idle cost by the number of tiers or split one pool between them and lose the latency the pool exists for. Deliberately, one size is fast and the rest are correct.

​
You are never silently given the wrong size

If a size cannot be served, the create fails. It is never quietly served from the default image. This matters more here than on the current runtime: memory is fixed at launch, so there is no later point at which a wrong size could be corrected — you would simply be billed for one size and running on another for the life of the sandbox.

​
Resizing is not possible

scale() and setAutoscale() return 501. Memory belongs to the image, so a running sandbox cannot be resized.
If you size sandboxes dynamically today, that decision has to move to create time. See What’s not supported.