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": falsewith"resumeReason": "cpu_mismatch". That wait is part of the resume time. Passsbx resume --require-memoryto 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
doneSLOT 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.
Related#
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.