Skip to content
sandboxer
Start free trial
Guides · How-tos

Can You Fork a Running Cloud Sandbox, Memory and All?

Updated October 27, 2026 .md

Short answer: No. sbx fork copies a running sandbox's disk into a new, independent sandbox in a few seconds, but the copy boots fresh, so no RAM and no running processes come across. Files written up to the fork are there. To keep memory, stop and resume the same sandbox, or run long-lived work as systemd services that save state to disk.

What a fork copies#

Copied to the fork Not copied
Disk Everything: /home/user, /etc, installed packages, Docker images, enabled systemd units
Memory RAM, open files, sockets, shell sessions
Processes Enabled systemd services start at boot Anything started by hand, with exec --detach, or in tmux
Settings Size, environment version and per-sandbox env (unless you override them) The source's TTL: the fork gets the default one hour
Identity Id, subdomain, hostname, machine-id and SSH host keys are all new
Hosted ports Routes and tokens: run sbx host on the fork

The source is never touched and keeps running. The fork's disk is a copy-on-write reflink, so it takes about the same time for a large disk as for a small one, and uses no extra storage until the two diverge.

Try it: a counter in memory, then a fork#

We ran this on prod on 2026-10-27 with a small sandbox. The first process keeps its count only in memory and prints it to a log. The second is a systemd service that saves its count to a file each second.

sbx new --type small --name aeo-fork-1
src=sb_wq41n3fyb5    # the id sbx new printed

# 1. A counter that lives in memory (it logs each value, plus a random token picked at start)
sbx exec $src --detach "python3 -u -c 'import time,itertools,secrets;tok=secrets.token_hex(4);[print(i,tok) or time.sleep(1) for i in itertools.count()]' > ~/c.log"

# 2. A counter that saves its value to disk, as an enabled systemd service
sbx exec $src "sudo tee /etc/systemd/system/counter.service >/dev/null <<'U'
[Unit]
Description=counter that saves its value to disk
[Service]
User=user
ExecStart=/bin/bash -c 'n=\$(cat /home/user/n 2>/dev/null || echo 0); while true; do n=\$((n+1)); echo \$n > /home/user/n; sleep 1; done'
Restart=always
[Install]
WantedBy=multi-user.target
U
sudo systemctl daemon-reload && sudo systemctl enable --now counter.service"

Just before the fork, both counters were at 254, and we wrote the time to a file:

sbx exec $src 'tail -1 ~/c.log; echo n=$(cat ~/n); date -u +%T.%N | cut -c1-12 > ~/marker2; cat ~/marker2'
254 cefc0bd0
n=254
02:05:36.141

Then we forked, at a bigger size, and timed it:

time sbx fork $src --type default --wait --json
{"event":"forking","id":"sb_8lcd3t2t2o","source":"sb_wq41n3fyb5","sandbox":{…"memoryRestored":null,…}}
{"event":"state","id":"sb_8lcd3t2t2o","state":"provisioning"}
{"event":"ready","id":"sb_8lcd3t2t2o","state":"ready","url":"https://regal-daring-cricket.box.sandboxer.com",…}

real	0m3.354s

What the fork had#

c=sb_8lcd3t2t2o
sbx exec $c 'nproc; cat ~/marker2; tail -1 ~/c.log; pgrep -a python3 || echo "no python3"; echo n=$(cat ~/n); systemctl is-active counter; uptime -s'
4
02:05:36.141
254 cefc0bd0
no python3
n=257
active
2026-10-27 02:05:38

Line by line:

  • 4 vCPUs: --type default took effect, so the fork is bigger than its small source.
  • The marker file is there. It was written one second before the fork, and the source listed no snapshots at that point. The fork copied the disk as it was when we forked.
  • The log ends at 254, and python3 is gone. The log file came across on the disk, but the process that wrote it, and the count in its memory, did not. The fork booted at 02:05:38.
  • The systemd counter reads 257. The service started at boot, read 254 from disk and kept counting. This is how to carry work into a fork.

The source was unaffected. A few seconds later it showed 258 cefc0bd0 with the same python3 process (PID 527) still running.

sbx info on the fork shows "memoryRestored": null and "resumeReason": null. A fork never restores memory, so that field has nothing to report. It's set only on a resume.

How long a fork takes#

These are single runs on prod on 2026-10-27, not benchmarks:

Run Measured Result
small to small createdAt to updatedAt once ready, from sbx info 1.9 seconds
small to default, sbx fork --wait Wall time with time, including the CLI 3.4 seconds

sbx fork without --wait returns the new id at once (HTTP 202). Forks count as a start against your plan's start limits, like a create or a resume.

If you need the memory too#

Use stop and resume instead of a fork. A stop writes the VM's memory to disk, and a resume brings the same sandbox back with its processes running. It's one sandbox, not a copy.

A resume restores memory only on a machine with the same CPU type. If none is free within 2 minutes, it boots from disk instead: files are kept, running processes are not, and the sandbox shows memoryRestored: false with resumeReason: "cpu_mismatch". Pass sbx resume --require-memory to wait for a matching machine rather than boot from disk.

For copies that should come up working, make your services systemd units with their state on disk, as above. Or save a named snapshot once (sbx snapshot $src my-stack) and start each copy with sbx new --from my-stack.

FAQ#

Does the fork get the processes that were running?#

No. The fork boots from a copy of the disk, so only enabled systemd services start. Processes you started by hand, with sbx exec --detach, or in tmux are not in the fork.

Is the fork's disk from the last 10-minute snapshot?#

In our test, no. A file written one second before the fork was in the fork, and the source had no snapshots listed yet. The fork copied the running sandbox's disk at the moment of the fork.

Can I change the size when I fork?#

Yes. Pass --type small, default, large or xlarge. We forked a small sandbox to default and the fork had 4 vCPUs.

Does forking stop or slow down the source?#

It didn't in our test. The source's in-memory counter kept going through the fork with the same PID. The source is never changed.

Can I fork a sandbox created with --no-snapshots?#

No. The API answers 409 snapshots_disabled. Such a sandbox can't be resumed, forked or saved as a template either.

More guides

Top AI sandbox platforms for code execution in 2026, ranked

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.

Read the guide
Best sandboxes for running coding agents (Claude Code, Codex, Gemini CLI) in 2026, ranked

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.

Read the guide
Best Daytona sandbox alternatives in 2026, ranked

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.

Read the guide
Best E2B alternatives in 2026, ranked

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.

Read the guide