Pause and resume a cloud sandbox with its memory
Updated October 27, 2026 .md
Short answer: Stop the sandbox with sbx stop. Sandboxer writes the VM's memory and device state to disk along with its files, then shuts it down, so nothing is billed. sbx resume restores that memory, and your dev server, tmux session and agent continue from the instruction where they stopped, with the same process IDs.
At a glance#
| Stop and resume | Fork | |
|---|---|---|
| What's saved | Memory, device state and disk | Disk only (a running sandbox's disk as it is at that moment; a stopped one's latest snapshot) |
| Running processes after | Still running, same PIDs | None: the copy boots fresh |
| Identity | Same sandbox, id and URL | New id, subdomain, machine-id and SSH host keys |
| Cost while waiting | Nothing | The copy is billed while it runs |
| Use it for | Pausing work overnight or between agent turns | Trying several approaches from one state |
Try it: a process that survives a stop#
This is what we ran on a real default sandbox to check the behaviour.
id=sb_k3v9x2mq # your sandbox id from `sbx new`
# A counter that ticks every second, and a web server on port 3000
sbx exec $id --detach "bash -c 'i=0; while true; do i=\$((i+1)); echo \$i > ~/counter; sleep 1; done'"
sbx exec $id --detach "mkdir -p site && cd site && echo hello > index.html && python3 -m http.server 3000"
sbx host $id 3000 --public
sbx exec $id "cat ~/counter" # 11
sbx stop $id
# ...wait as long as you like; nothing is billed...
sbx resume $id
sbx exec $id "cat ~/counter" # 13, not 1: the same loop kept countingAfter resume, ps showed both processes with their original PIDs, and the public URL answered again without restarting anything. The counter moved from 11 to 13 even though the sandbox was stopped for about 20 seconds: the loop was frozen while stopped and continued when resumed.
What happens on stop#
- The filesystem is frozen so the disk is consistent.
- The VM's memory and device state are written to disk next to its disk snapshot.
- The VM shuts down and billing stops.
The stop call returns at once, and the sandbox shows archiving while the snapshot is written. Resume waits until a test command succeeds before it reports ready.
When resume boots from disk instead#
Resume restores memory in the normal case. It boots from the disk instead, keeping your files but not your processes, when:
- you change size on resume (
sbx resume <id> --type large); - the memory image is missing or the host can't restore it. The resume still succeeds.
A sandbox created with --no-snapshots is different: it never snapshots, so stopping it erases it.
Auto-stop does the same#
A new sandbox stops itself after one hour by default, as a safety net, and an auto-stop is the same memory-preserving stop. Change it per sandbox:
sbx extend $id --hours 12 # push the deadline out
sbx extend $id --no-auto-stop # never stop on its own
sbx new --ttl 28800 # 8 hours from the startFork when you want copies, not a pause#
sbx fork <id> makes a new, independent sandbox from the source's latest disk snapshot. The disk is a copy-on-write reflink, so forking a large sandbox is as quick as forking a small one. The fork boots fresh, so start your services again in it. To start many sandboxes from a prepared state, save a named snapshot once and create from it:
sbx snapshot $id web-stack
sbx new --from web-stackFAQ#
Does a stopped sandbox cost anything?#
No. Billing is per second while a sandbox runs. A stopped sandbox, its disk and its automatic snapshots are free. Storage isn't billed: each plan includes an amount for stopped sandboxes and named snapshots, and at the limit new sandboxes wait until you delete some (see billing).
Do running processes survive a stop?#
Yes. Resume restores the VM's memory, so processes continue with the same PIDs. A shell, a tmux session, npm run dev, a Postgres server or an agent halfway through a turn all keep running.
Is the clock wrong after a resume?#
No. The guest clock is corrected when the sandbox resumes, and the network is re-attached.
How is this different from a fork?#
A fork copies the disk into a new sandbox that boots fresh, with no running processes. Stop and resume keeps the same sandbox, including its memory.
How long can a sandbox stay stopped?#
Until you delete it, unless your account has zero data retention turned on.
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.