# Pause and resume a cloud sandbox with its memory

> 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.

Source: https://sandboxer.com/guides/pause-and-resume-a-sandbox-with-memory. Updated 2026-10-27.

**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.

```bash
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 counting
```

After 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

1. The filesystem is frozen so the disk is consistent.
2. The VM's memory and device state are written to disk next to its disk snapshot.
3. 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:

```bash
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 start
```

## Fork 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:

```bash
sbx snapshot $id web-stack
sbx new --from web-stack
```

## FAQ

### 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](/docs/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.