Pause keeps memory

Note: Network connections do not survive; only files and processes do.

docs-confirmed “Memory state is maintained even after scaling down, including the running processes and entire filesystem.” Source↗

Note: A hibernated machine wakes in about 85 ms; standby is faster still.

docs-confirmed “Next to `running`, boxd has two sleep states: `standby` keeps the memory in RAM, and `hibernated` writes it to disk.” Source↗

A filesystem-only pause is opt-in; the default keeps memory.

docs-confirmed “By default a pause saves **both** the filesystem and the memory.” Source↗

Note: A fast pause keeps only the files, so it is the option to avoid if work must survive.

docs-confirmed “`pause()` saves the sandbox’s memory, running processes and every file on its disk.” Source↗

Only storage is billed while paused.

docs-confirmed “Pausing an instance suspends its execution while preserving the memory state.” Source↗

A stop keeps the files and drops memory; only delete removes the disk.

docs-confirmed “A pause keeps its memory and processes.” Source↗

Note: After a longer idle spell it is stopped and memory is dropped, and you are not told which happened.

docs-confirmed “The VM is suspended with everything in memory frozen in place.” Source↗

Note: Only named sandboxes can be suspended; an unnamed one runs until it ends.

docs-confirmed “**Named**: a name given at creation. Supports suspend and resume, so you can pause between tasks and pick up exactly where you left off.” Source↗

The catch: A sleep usually comes back where it left off, but a wake that has to rebuild starts fresh and loses what was running.

Auto-sleep is off by default; a stop never keeps memory.

docs-confirmed “A sleeping instance keeps its memory and wakes on the next request; a stopped one loses its memory and stays down until `start`.” Source↗

The catch: Only the full virtual machine can be paused with memory; a container sandbox loses what was running.

docs-confirmed “Pause is not supported for container sandboxes. The filesystem can be preserved on stop, but memory state is not.” Source↗

The catch: A resume can come back without the running programs, and the machine reports that it did.

A paused machine cannot be stopped; start it first.

docs-confirmed “**Resume** brings back a paused machine's memory and processes. If that is not possible it starts fresh: files are kept, processes are not.” Source↗

The catch: Memory comes back only if a machine of the same processor type is free within two minutes; otherwise it boots fresh with the files.

docs-confirmed “Memory is restored on a machine with the same CPU type as the one the sandbox stopped on.” Source↗

There is no pause; a stop removes the machine and keeps a copy of the disk.

docs-confirmed “There is no pause. A stop removes the virtual machine and keeps a copy of the disk.” Source↗

There is no paused state; when an instance stops, its processes and its disk end with it.

docs-confirmed “An instance runs only until something stops it, and its processes and the files on its disk end with it. The next `start()` creates a new instance.” Source↗

There is no pause; a sandbox is terminated, and only a snapshot can bring its state back.

docs-confirmed “Sandbox memory snapshots are copies of a Sandbox’s entire state, both in memory and on the filesystem.” Source↗

Stopping saves the files but not what was running; the next start is a new session.

docs-confirmed “Persistent sandboxes automatically save their filesystem state when stopped and restore it when resumed.” Source↗