How we measure
The numbers this site gives as measured were measured on bare metal, on the processor our production servers use: sleep, wake and snapshot, and the CPU benchmark. Here is each one, with the machine, the day, how it was taken and where its raw results are.
- Bare metal. A whole physical machine, not a virtual machine on someone else’s, so nothing we cannot see shares it.
- Medians, with their spread. The middle value of many runs, with the 95th percentile and the number of runs beside it.
- A best case is called one. Most of these ran with nothing else busy on the machine; where that is so, the page says it.
- Raw results kept. Each figure names the file it was read from, in the repository with the code that made it.
Sleep, wake and snapshot
- Machine
- Cherry Servers, Singapore: AMD Ryzen 9 9950X (Zen 5, 16 cores), 128 GB, Ubuntu 26.04.1, kernel 7.0.0-34
- Day
- 3 October 2026
- Sandbox
- 4 vCPU / 8 GiB sandbox, node:24-bookworm
- Node
- sandboxd with that day’s defaults: a patched Firecracker, memory in two layers, a process kept ready for each sleeping sandbox, devices on PCI
- Caller
- on the same machine, over one connection kept open, so a figure is the request itself and not a handshake
| What | How it is timed | Median | p95 | Runs | Read from |
|---|---|---|---|---|---|
| Put to sleep | POST …/sleep, as the caller saw it | 2.3 ms | 2.8 ms | 30 | wake.txt cycle sleep |
| Wake, after it fell asleep by itself | the node’s own count of restoring it (its Server-Timing header), for the next call | 3.5 ms | 3.9 ms | 29 | wake.txt auto wake |
| That call, answered | the whole request that woke it, sent to answered | 6.7 ms | 7.1 ms | 29 | wake.txt auto call |
| Wake, straight after a sleep | the process kept ready for the next wake is still starting, so it waits | 5.6 ms | 6.3 ms | 30 | wake.txt cycle wake |
| Snapshot of a running sandbox | through the API: memory, processes and disk, while it runs | 32 ms | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| Made, from the pool | a copy of a template already running | 1.3 ms | — | 100 | tti-sequential.txt create median |
| Made, to its first command’s answer | one after another, a hundred times | 11.0 ms | 12.0 ms | 100 | tti-sequential.txt sequential x100 |
| 30 at once: all asleep | thirty sandboxes put to sleep at the same moment, until the last | 49.0 ms | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 at once: all awake | the same thirty woken at the same moment, until the last | 61.4 ms | — | 1 | wake.txt concurrent 30 wake_all |
The files are in sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/; the write-up is sandboxd/bench/results/README.md, round 2, section 二. The site’s other pages read their sleep and wake figures (3.5 ms to wake, 2.3 ms to sleep) from the same file as this table, so they are this round’s. The snapshot was checked page by page against the whole memory Firecracker wrote out itself: 3 bytes of one page in 2,097,152 differed.
You can read the same figure for your own sandboxes: every API call that had to wake one says how long that took, in milliseconds, in itsServer-Timing: wake;dur=… header.
CPU: StarSling’s open benchmark
StarSling publishes an open benchmark of sandbox providers (github.com/starslingdev/hpc-sandbox-benchmarks). Its CPU score is Node.js web tooling in a sandbox of 4 vCPUs and 8 GiB, in runs a second. We ran its suite in a Glac sandbox and compared the result with the providers in its latest published run that our copy of its data holds.
- Glac, runs a second
- 29.0
- the median of 13 providers
- 17.26
- faster than that median
- 68%
Ours
- Our first production server, in Coventry, UK: an AMD Ryzen 9 9950X with 128 GB, on 10 October 2026, during its acceptance test, with no other sandbox busy on it.
- StarSling’s own suite and image (
sandbox-benchmarks-toolchain:v8), in a sandbox of 4 vCPUs and 8 GiB, run as the product runs it. - Three passes of the suite; each pass is the median of its three trials: 28.97, 29.27, 29.00. The figure is their median, 29.00.
Theirs
- StarSling’s run 36498291449: the run its leaderboard showed on 2 October 2026, when we took our copy of its data, and the latest of the nine runs in that copy (23 to 29 September 2026).
- A provider’s value is the median over its sandboxes of each sandbox’s median trial: the leaderboard’s own rule.
- Our copy keeps each value as a ratio to one provider’s in the same run, to three decimals, so each value below is within about 0.02 of StarSling’s own.
Ours, and the 13 values, runs a second, highest first
29.0 ÷ 17.26 = 1.68, so 68% faster than the median. The providers’ names are in StarSling’s published data; the values here are read at build time from reports/providers/sources/performance-bar/starsling-metrics.tsv, made from that data by analyse.py beside it.
What it does not say
- Ours ran with nothing else busy on the machine; theirs ran on whatever their hosts carried that day. A busy machine lowers the score: on a 9950X with 1.25 other busy vCPUs for each of its cores, the same suite scored 10.4 in our sandbox (8 October 2026). Those neighbours ran the same test in a loop, the most cache-hungry load there is, heavier than a real fleet.
- It is one benchmark of one kind of work, Node.js running JavaScript tools, which follows the speed of the cores. It says nothing of disks or networks.
The files
sandboxd/bench/results/2026-10-10-cvt-01-accept/: the acceptance, its raw output andresults.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md: how the copy was made and readsandboxd/bench/results/README.md: sections 40 and 42
Where the raw results are
Every path on this page is a file in Glac’s own repository, beside the code that took the measurement. The repository is not public; the paths say which run each figure comes from, and each round’s write-up says what was run, on what, and what went wrong.