#Real-host performance report — 2026-07-31

Status: Historical matrix retained; Linux cleanup blockers from that run have been addressed in later Box tips. Numbers below remain the 2026-07-31 capture and are not a fresh all-green requalification.

The matrix ran the real A3S Box 3.2.0 CLI against dedicated-kernel MicroVMs on Linux/KVM and macOS/HVF, plus the shared-kernel Sandbox backend on Linux. It covered lifecycle, exec, idle memory, compute, rootfs/CoW, tmpfs, bind mounts, named volumes, initialization, networking, concurrency, warm pools, snapshot-fork, and TEE simulation.

This was not an all-green qualification at capture time:

#Host conditions

The Linux measurements came from a shared but lightly loaded A3S OS production host. The benchmark was pinned to CPUs 4–7 with reduced CPU and I/O priority. No global AppArmor or user-namespace security setting was changed.

The macOS lane ran on different hardware under materially higher background load. It is not a KVM-versus-HVF hardware ranking.

#Method

Alpine 3.22 was loaded before timed samples. A “cold lifecycle” starts a new execution from the local cached image; it does not include registry pull or image unpack time.

Latency uses nearest-rank p50 and p95. Throughput uses p50. Failed samples are excluded from aggregates but retained in pass/fail counts.

#Lifecycle and execution

Sandbox values describe a detached instance kept alive for exec and storage workloads. They must not be presented as a successful foreground run --rm lifecycle.

#Compute and storage

Compute values include a3s-box exec setup in every timed sample. They are not raw guest CPU or memory-bandwidth measurements.

#Networking, warm pools, and TEE

The homepage's 1.325 VM/s is derived as 4 VMs ÷ 3.020 seconds. It is a pool-fill rate, not request-serving capacity or unbounded concurrent throughput.

Warm-pool steady state did not preserve the low latency of the first three acquisitions, and snapshot-fork leaked resources on both hosts. The 2.26× value is therefore not an unconditional product claim.

TEE rows use --tee-simulate. The Linux host had no qualifying SEV-SNP or TDX device, so this data cannot prove hardware confidentiality, attestation, or real TEE overhead.

#Known blockers

Status as of later Linux tips (post-capture):

1. Fix foreground Sandbox cgroup-mount and log-drain behavior — addressed for hosts with the setuid OCI launcher and a delegated user cgroup; a local run --rm --isolation sandbox smoke now completes cleanly. Re-run the full lifecycle matrix before publishing new Sandbox performance numbers.
2. Reclaim every shim, filesystem mount, socket, and box directory after snapshot-fork / warm-pool shutdown on Linux — pool drain now tears down idle VMs and leases, clears snapshot template dirs, and best-effort reaps orphans when destroy fails (including mid-replenish and lease reclaim). macOS/HVF pool leftover cleanup still needs host re-verification.
3. Fix premature TSI connection closure on macOS/HVF before publishing a network-reliability conclusion.
4. Run attestation, RA-TLS, seal/unseal, and secret injection on qualifying SEV-SNP hardware. Simulation can never replace hardware evidence.

Return to the platform matrix for backend support boundaries.