# Optimizing Vercel Sandbox snapshots

DevFeed: [Optimizing Vercel Sandbox snapshots](<https://devfeed.tech/articles/optimizing-vercel-sandbox-snapshots-770.md>)

Original publisher: [Read original article](<https://vercel.com/blog/optimizing-vercel-sandbox-snapshots>)

Author: Guðmundur Bjarni Ólafsson

Published: 2026-04-02T04:00:00Z

Content type: article

Language: en

Sources: [Vercel News](<https://devfeed.tech/sources/vercel-news.md>)

Topics: [Amazon S3](<https://devfeed.tech/topics/amazon-s3.md>), [Go Language](<https://devfeed.tech/topics/go-language.md>)

Tags: [aws](<https://devfeed.tech/tags/aws.md>), [benchmarking](<https://devfeed.tech/tags/benchmarking.md>), [cache](<https://devfeed.tech/tags/cache.md>), [compression](<https://devfeed.tech/tags/compression.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [firecracker](<https://devfeed.tech/tags/firecracker.md>), [go](<https://devfeed.tech/tags/go.md>), [http](<https://devfeed.tech/tags/http.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [performance](<https://devfeed.tech/tags/performance.md>), [s3](<https://devfeed.tech/tags/s3.md>), [sandbox](<https://devfeed.tech/tags/sandbox.md>), [streams](<https://devfeed.tech/tags/streams.md>), [vercel](<https://devfeed.tech/tags/vercel.md>)

## AI overview

Vercel describes optimizing Sandbox filesystem snapshot restores from over 40 seconds at p75 to under one second through parallel S3 range downloads, parallel decompression, streamed decompression, and local caching.

## Source excerpt

When we recently shipped filesystem snapshots 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. 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. What a snapshot looks like on disk Vercel Sandbox runs on the same infrastructure as our internal builds product, Hive. Each sandbox is an isolated container inside a Firecracker microVM. A snapshot is a compressed copy of the sandbox's disk. We're working with two different files: The raw disk image (.img), which can be several GBs A compressed version in our custom VHS format (Vercel Hive Snapshot), which is what gets uploaded to and downloaded from S3 When you call sandbox.snapshot(), we compress the .img into a .vhs and upload it to S3. When you call Sandbox.create() with a snapshot, we download the .vhs 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. Parallelize you shall With reliability in place, we turned to the restore path, which was painfully sequential. We'd download the entire .vhs file from S3 in a single request, wait for it to finish, then decompress it in a single thread. Snapshots range from 200MB to a few GBs, so that single S3 download alone could take several seconds to tens of seconds. We used the Range HTTP header to download chunks in parallel instead, with the AWS Go SDK's transfermanager API handling the orchestration. After benchmarking different concurrency levels and chunk sizes, we ended up with 2-5x faster downloads. We applied the same thinking to decompression. Our .vhs format stores a header and a frame for each allocated region of the disk image, so ins