Pause and Resume a Sandbox With Its Memory

What happens when you stop a sandbox?

A stop takes a full snapshot of the running machine and then turns it off. Sandboxer's snapshots docs describe three steps:

The filesystem is frozen so the disk image is consistent.
The VM is paused and its memory and device state are written to disk.
The VM shuts down and the billing meter stops.

The sandbox moves from archiving to archived. A stopped sandbox keeps everything and costs nothing, though its disk and memory image count toward your plan's included storage.

sbx stop <sandbox-id>
sbx resume <sandbox-id>

What survives a resume?

Running processes survive, with the same process IDs. That covers shell history, tmux panes, npm run dev, a Postgres server, an SSH tunnel, the desktop session and an agent partway through a turn. The guest clock is corrected and the network is re-attached on resume.

Sandboxer's pause and resume guide shows a test: a counter loop writing to a file every second kept counting from where it was after a stop and resume, instead of starting again from one.

When does a resume boot from disk instead?

A resume falls back to a cold boot from disk in a few cases. Your files are intact, enabled systemd services start, but hand-started processes do not. The sandbox reports this with memoryRestored: false and a resumeReason:

resumeReason	Why it booted from disk
`cpu_mismatch`	No machine with the sandbox's CPU type was free in time
`resized`	You changed the size, which always boots from disk
`no_memory_snapshot`	The stop kept no memory
`restore_failed`	The memory image could not be restored on the host

Memory is restored on a machine with the same CPU type. If one is online but busy, the resume waits up to 2 minutes. Pass --require-memory to wait up to 30 minutes instead, and fail rather than cold-boot.

Does a sandbox pause itself when idle?

Yes. A sandbox pauses itself after a set number of idle minutes, and that pause is the same stop with memory. The next API call or request to one of its hosted URLs wakes it. Defaults depend on the plan, per the long-running tasks docs:

Plan	Default idle pause
$20 / month	30 minutes
$100 and $500 / month	60 minutes
$2,000 / month	120 minutes

sbx new --idle 60          # pause after an hour without activity
sbx idle <sandbox-id> 0    # never pause this one

Commands, SSH sessions, agent turns and open terminals keep a sandbox awake. A sandbox stopped by you, by auto-stop or by billing does not wake by itself.

How is this different from auto-stop?

Auto-stop is a hard deadline, while idle pause reacts to inactivity. Every sandbox has a time-to-live, one hour by default, after which Sandboxer stops it with memory and disk kept. You can extend it up to 30 days at a time or turn it off.

sbx extend <sandbox-id> --hours 12
sbx extend <sandbox-id> --no-auto-stop

When should you pause instead of fork?

Pause when you want the same sandbox back later. Fork when you want copies. A fork copies only the disk into a new sandbox that boots fresh, with a new identity and no running processes. See forking sandboxes.

Pause overnight, between agent turns, or while waiting on review
Fork to try several approaches from one state

Frequently asked questions

Does a stopped sandbox cost anything?

No compute is billed while it is stopped. Its disk and snapshots count toward your plan's included storage, which is not billed.

How long can a sandbox stay stopped?

Until you delete it, unless your account has zero data retention turned on.

Can I change size when I resume?

Yes, you can make it bigger with --type. A resize always cold-boots from disk, so files stay but running processes do not.

Can a sandbox be stopped without saving anything?

A sandbox created with --no-snapshots never snapshots, so stopping it erases it. It cannot be resumed or forked.