When we recently shipped in Vercel Sandbox to let teams capture and restore a sandbox's entire filesystem state, our initial engineering focus was entirely on reliability, making sure the system would never fail to snapshot or lose data.filesystem snapshots Once that foundation was stable, our attention turned to performance. p75 snapshot restores were taking over 40 seconds, and through parallelization and local caching, we brought that under one second. Vercel Sandbox runs on the same infrastructure as our internal builds product, . Each sandbox is an isolated container inside a Firecracker microVM.Hive A snapshot is a compressed copy of the sandbox's disk.

We're working with two different files: When you call , we compress the into a and upload it to S3. When you call with a snapshot, we download the and decompress it back. Without compression, every snapshot operation transfers hundreds of MBs to low GBs over the network, adding seconds to tens of seconds to every restore.sandbox.snapshot().img.vhsSandbox.create().vhs With reliability in place, we turned to the restore path, which was painfully sequential. We'd download the entire file from S3 in a single request, wait for it…