Tensorlake Documentation

A sandbox created from a CAS image can change its CPU, memory, and root disk allocation while it runs. Processes keep running, the API reports the confirmed allocation, and the guest sees the new CPUs, memory, and disk capacity. GPU sandboxes can only grow their root disk, and sandboxes created from the default-format tensorlake/* images can’t be resized live; recreate those with the new size instead.

What You Can Change

CPUs: up or down, in whole vCPUs, with a minimum of 1.
Memory: up is always possible. Down goes no lower than the memory the sandbox booted with, and only as far as the guest can free memory at that moment. Memory changes happen in 128 MiB steps.
Disk: up only. The filesystem grows in place.

If the guest can’t release enough memory for a shrink, the resize stops above the target and is reported as failed with the size it reached, and the sandbox keeps that size. For example, a sandbox booted with 1 GiB, grown to 64 GiB, and still using 34 GiB can shrink to about 34 GiB, not back to 1 GiB. Each resize is a numbered generation. The sandbox’s resources always hold the confirmed allocation, and resource_resize describes the latest generation with its status: pending, succeeded, or failed.

Resize a Running Sandbox

Omitted dimensions keep their current allocation. A resize can’t be combined with name, port, or network changes in the same call.

CLI
Python
TypeScript

tl sbx update <sandbox-id> --cpus 4 --memory 8192
tl sbx update <sandbox-id> --disk_mb 51200

The command waits up to 300s for the resize to complete. --wait-timeout changes the limit, and --no-wait returns as soon as the resize is admitted.

info = sandbox.update(cpus=4, memory_mb=8192)
print(info.resources.cpus, info.resources.memory_mb)

info = sandbox.update(disk_mb=51200)
print(info.resources.disk_mb)

update() waits up to timeout seconds (default 300) and raises SandboxResizeError if the resize fails or times out. A timeout doesn’t cancel the resize.

let info = await sandbox.update({ cpus: 4, memoryMb: 8192 });
console.log(info.resources.cpus, info.resources.memoryMb);

info = await sandbox.update({ diskMb: 51200 });
console.log(info.resources.diskMb);

update() waits up to timeout seconds (default 300) and throws SandboxResizeError if the resize fails or times out. A timeout doesn’t cancel the resize.

Wait for a Resize Later

Return as soon as the resize is admitted and wait for its generation when convenient, for example from another process:

CLI
Python
TypeScript

tl sbx update <sandbox-id> --memory 16384 --no-wait
tl sbx wait <sandbox-id> --resize <generation> --timeout 600

With --no-wait, tl sbx update prints the tl sbx wait command to run, including the generation.

info = sandbox.update(memory_mb=16384, wait=False)
generation = info.resource_resize.generation

info = sandbox.wait_for_resource_resize(generation, timeout=600)

const admitted = await sandbox.update({ memoryMb: 16384, wait: false });
const generation = admitted.resourceResize!.generation;

const info = await sandbox.waitForResourceResize(generation, { timeout: 600 });

A wait that times out doesn’t cancel the resize. Wait for the same generation again to keep following it.

Resize and Snapshots

A memory snapshot records the resized allocation, so a sandbox restored from it starts with that size. The restored sandbox can be resized again, including shrinking memory down to the size the original sandbox booted with.

CAS Images

The image format that makes a sandbox resizable.

Lifecycle

Sandbox states, timeouts, and suspend/resume.

Snapshot and Clone

Save and restore a resized sandbox.

Overview

Guides

Use Cases

Live Resize

What You Can Change

Resize a Running Sandbox

Wait for a Resize Later

Resize and Snapshots

See Also

CAS Images

Lifecycle

Snapshot and Clone

​What You Can Change

​Resize a Running Sandbox

​Wait for a Resize Later

​Resize and Snapshots

​See Also

CAS Images

Lifecycle

Snapshot and Clone

What You Can Change

Resize a Running Sandbox

Wait for a Resize Later

Resize and Snapshots

See Also