Skip to content
Guides · Sandboxes and isolation

How Fast Does a Cloud Sandbox Start, Resume and Fork? Measured

Updated October 27, 2026 .md

Short answer: Measured from our machine on 2026-10-27 in eu-central, 10 runs per size: a new sandbox reported ready in a median 3.2 seconds, a resume with memory in 1.35 seconds, and a fork in 3.35 seconds. The first command then took about 0.2 seconds. Every figure includes CLI and network time.

Conditions#

Date and time 2026-10-27, 03:00:35 to 03:07:19 UTC
Region eu-central
Sizes small (2 vCPU, 4 GB) and default (4 vCPU, 8 GB), 10 runs each
Client Measured from our machine, with ping sandboxer.com averaging 27.2 ms round trip
What a number means Wall-clock time around one sbx command, so it includes the CLI and every network round trip
Runs One sandbox at a time, each deleted at the end of its run

These are measurements of Sandboxer only. We didn't time any other service.

Results#

All times in milliseconds.

Step Size Min Median p90 Max
sbx new to ready small 3189 3191 3193 3193
sbx new to ready default 3189 3200 3244 7813
First command (sbx exec <id> true) small 205 210 212 218
First command default 205 209 213 217
sbx resume to ready (memory restored) small 1343 1348 1354 1356
sbx resume to ready (memory restored) default 1343 1350 1366 1444
First command after resume small 205 207 214 222
First command after resume default 204 208 210 215
sbx fork --wait to ready small 3352 3354 3360 3361
sbx fork --wait to ready default 3350 3358 3362 3367
First command in the fork small 200 202 207 240
First command in the fork default 198 203 204 211

p90 is the 9th of 10 sorted runs. All 20 resumes reported "memoryRestored": true with resumeReason null, and in all 20 a sleep process started before the stop had the same PID after the resume. Size made no visible difference: the small and default medians are within 10 ms of each other for every step.

One run stands out: default run 10 took 7813 ms to be ready. The other 19 creates took 3.19 to 3.24 seconds.

We also timed a resume that has to boot from disk, by resuming a stopped small sandbox as default (a size change always cold-boots), 5 runs at 03:06 to 03:07 UTC. With 5 runs, p90 here is the slowest run:

Step Min Median p90 Max
sbx resume --type default to ready (cold boot) 3379 3382 3389 3389

Each of those reported "memoryRestored": false and "resumeReason": "resized", and the sleep process was gone, as expected after a boot from disk.

Why the numbers cluster#

sbx new, sbx resume and sbx fork --wait check the sandbox's state at once, after 1 second, then every 2 seconds. sbx resume and sbx fork --wait also run true in the sandbox before they print ready. So the times land in steps: a sandbox seen at the 3-second check shows about 3.2 seconds, whether it came up at 1.5 or 2.9 seconds. The sandbox was up somewhere inside the last step.

Read the table that way:

  • Create: up by the 3-second check in 19 of 20 runs. The 7.8-second run was seen two checks later.
  • Resume with memory: up by the 1-second check in all 20 runs.
  • Fork and cold resume: up by the 3-second check in every run.

What makes a resume fast or slow#

A stop writes the VM's memory and device state to disk. A resume loads that image back, so the VM skips booting and its processes carry on. That is the 1.35-second case.

A resume boots from disk instead, keeping files but not processes, when:

  • you change size (sbx resume <id> --type large). Our cold-boot runs above are this case;
  • the memory image is missing, for example for a sandbox created with --no-snapshots;
  • no machine with the same CPU type as the one it stopped on is free. The resume waits up to 2 minutes for one, then boots from disk and reports "memoryRestored": false with "resumeReason": "cpu_mismatch". That wait is part of the resume time. Pass sbx resume --require-memory to keep waiting (up to 30 minutes) rather than boot from disk.

None of our 20 memory resumes fell back. Check after any resume with:

sbx info $id --json | jq '.sandbox | {memoryRestored, resumeReason}'
{
  "memoryRestored": true,
  "resumeReason": null
}

A fork always boots fresh from a copy of the disk, so it never restores memory and its memoryRestored is null. In our runs the source was stopped when we forked it, so only one sandbox ran at a time.

The script#

This is the script we ran, unchanged. It needs a signed-in sbx and jq, and deletes everything it creates.

#!/usr/bin/env bash
# Sandboxer start / first command / resume / fork timings. Wall-clock from the machine running this script, so every
# number includes the CLI and the network round trips to sandboxer.com. Needs a signed-in sbx (or SANDBOXER_API_KEY)
# and jq. Runs one sandbox at a time and deletes everything it creates.
#   N=10 TYPE=small ./bench.sh > small.tsv
N=${N:-10}; TYPE=${TYPE:-default}; PREFIX=${PREFIX:-aeo-bench}; SBX=${SBX:-sbx}; SLOT=${SLOT:-}
ms_now() { echo $(( $(date +%s%N) / 1000000 )); }
state() { $SBX info "$1" --json 2>/dev/null | jq -r '.sandbox.state // empty'; }
wait_archived() { for _ in $(seq 1 240); do [ "$(state "$1")" = archived ] && return 0; sleep 0.5; done; return 1; }

echo -e "type\trun\tstarted_utc\tcreate_ready_ms\tfirst_exec_ms\tresume_ready_ms\tresume_exec_ms\tmemoryRestored\tresumeReason\tsame_pid\tfork_ready_ms\tfork_exec_ms"
for i in $(seq 1 "$N"); do
  slot=""; [ -n "$SLOT" ] && slot=$($SLOT acquire "$PREFIX-$TYPE-$i")
  started=$(date -u +%H:%M:%S)

  # 1. create to ready
  t0=$(ms_now)
  id=$($SBX new --type "$TYPE" --name "$PREFIX-$TYPE-$i" --no-env --ttl 900 --json | jq -r 'select(.event=="ready") | .id' | tail -1)
  t1=$(ms_now)
  if [ -z "$id" ]; then echo "run $i: create failed, stopping" >&2; [ -n "$slot" ] && $SLOT release "$slot" >&2; exit 1; fi

  # 2. first command
  $SBX exec "$id" true >/dev/null; t2=$(ms_now)

  # 3. stop (memory snapshot), then resume to ready
  $SBX exec "$id" --detach "sleep 100000" >/dev/null
  pid_before=$($SBX exec "$id" "pgrep -f 'sleep 100000'" | head -1)
  $SBX stop "$id" >/dev/null; wait_archived "$id"
  t3=$(ms_now)
  $SBX resume "$id" >/dev/null
  t4=$(ms_now)
  pid_after=$($SBX exec "$id" "pgrep -f 'sleep 100000'" | head -1)
  t5=$(ms_now)
  mr=$($SBX info "$id" --json | jq -r '.sandbox | "\(.memoryRestored)\t\(.resumeReason)"')
  same=$([ -n "$pid_before" ] && [ "$pid_before" = "$pid_after" ] && echo yes || echo no)

  # 4. fork to ready (source stopped again, so only one sandbox runs at a time)
  $SBX stop "$id" >/dev/null; wait_archived "$id"
  t6=$(ms_now)
  fid=$($SBX fork "$id" --wait --no-env --ttl 900 --json | jq -r 'select(.event=="ready") | .id' | tail -1)
  t7=$(ms_now)
  if [ -n "$fid" ]; then $SBX exec "$fid" true >/dev/null; else echo "run $i: fork failed" >&2; fi; t8=$(ms_now)

  echo -e "$TYPE\t$i\t$started\t$((t1-t0))\t$((t2-t1))\t$((t4-t3))\t$((t5-t4))\t$mr\t$same\t$((t7-t6))\t$((t8-t7))"
  echo "run $i: $id fork $fid" >&2
  [ -n "$fid" ] && $SBX delete "$fid" --yes >/dev/null
  $SBX delete "$id" --yes >/dev/null
  [ -n "$slot" ] && $SLOT release "$slot" >&2
done

SLOT is optional. We set it to a small helper that limits how many sandboxes our team runs at once; leave it empty and the script runs one sandbox at a time anyway. The resume time starts after the sandbox reports archived, so it doesn't include writing the stop snapshot.

The first rows of the small output:

type	run	started_utc	create_ready_ms	first_exec_ms	resume_ready_ms	resume_exec_ms	memoryRestored	resumeReason	same_pid	fork_ready_ms	fork_exec_ms
small	1	03:00:35	3189	212	1348	207	true	null	yes	3352	202
small	2	03:00:50	3191	211	1344	207	true	null	yes	3352	201
small	3	03:01:05	3189	207	1356	222	true	null	yes	3353	202
…

Earlier results#

We published an earlier run of the create and resume steps, measured on 2026-10-24 with default, 10 runs: conditions and results and script. It did not time forks or small. This page quotes only tonight's numbers.

FAQ#

Why is a resume quicker than a new sandbox?#

A resume with memory loads the saved VM image back instead of booting. In our runs it was up by the CLI's 1-second check every time, while creates, forks and cold resumes were seen at the 3-second check.

Does a bigger size start more slowly?#

Not between small and default in our runs: their medians were within 10 ms for every step. We didn't time large or xlarge.

What happens to the time if memory can't be restored?#

The sandbox boots from disk. When we forced that with a size change, resume took a median 3.38 seconds and running processes were gone. A CPU mismatch can add up to 2 minutes of waiting for a matching machine before that boot.

Do resumes and forks count against my start limits?#

Yes. Creates, resumes and forks each count as one start (see limits).

What if I need an answer at once when no machine is free?#

Pass --fail-fast to sbx new, sbx resume or sbx fork. Within about a second and a half you get either the usual 202 or 503 no_ready_machine, and a refused request isn't billed or counted as a start.

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