Hey guys, I m an engineer who s worked at startups, including YC-backed ones that raised solid funding. Giving agents a home where they can execute operations is my favorite niche.Ever wondered how a running sandbox actually gets its disk? It s not just wiring up an EBS or local ephemeral disk, and how do you even know whether a user is using their whole allocated space or barely any of it?The tradeoffs: sandboxes have to be fast to boot, durable, and cheap at scale, all at once. If a sandbox gets paused, you can t just leave its entire disk sitting on EBS; that gets expensive fast.This is where object storage comes in: S3 / Blob storage as the durable backing for caching and mounting. (For a mounted, cached filesystem over a bucket you can use an s3fs upgrade like Archil, though that s a separate volume layer, not the root disk.)But even with object storage, you can t copy the whole image (say 40 GB) every time a sandbox boots. So how do you keep boot fast without loading all that data up front?Solution:Three tiers: object storage (durable, source of truth) + a local SSD cache (hot chunks) + NBD (which presents a normal block device to the guest).A simple read path: guest → NBD → cache hit (fast), or on a miss → pull the chunk from S3/blob → cache it locally so the next read is a hit.The local volume is formatted as XFS so it supports reflink. That s what gives us copy-on-write. This matters for space: if a user only touches a fraction of their disk, we don t duplicate the rest. Sandboxes share the base and only diverge where they write. Write path: writes go to a dirty chunk, and the diff travels back to object storage. The disk is an OverlayFS with two layers: lower and upper. The lower layer is the template: pre-configured globally and handed to every sandbox at boot. Anything the sandbox writes after that (installed packages, new files) becomes dirty data in the upper layer. That upper layer is periodically flushed to object storage, and it s always saved on auto-pause. Now, if the sandbox is paused or crashes, the local disk unmounts. It does one last copy-on-write, carries any remaining dirty chunks up to S3, and then destroys itself. No data loss. Next time it starts from that point, the RAM/snapshot state is already there (the Firecracker/QEMU part), and the disk doesn t reload the whole 10 to 20 GB. When the user reads something, it s fetched from S3 on the first miss and cached, fast from then on. Don t confuse this disk cache with userfaultfd: that s the separate Linux mechanism that lazily restores memory pages via page faults, not disk blocks.Alr, adios