Memory snapshots vs disk snapshots: what "checkpoint" means for an agent sandbox

01What does a disk snapshot of a sandbox capture?

A disk or filesystem snapshot copies the sandbox's files at a point in time. Restoring it gives you the installed packages, the repository and the build cache, but not anything that was only in memory: running servers, shell variables, an agent's in-process state. The sandbox boots or runs its entrypoint again, and the processes start from scratch.

Several cloud sandboxes document exactly this behaviour. Modal's filesystem snapshots are copies of the sandbox's root filesystem, and mounted volumes are not included. Vercel Sandbox snapshots capture the filesystem and installed packages, and taking one stops the sandbox. Cloudflare's Sandbox SDK says a snapshot saves the writable root filesystem but not memory or processes, so the repository comes back while the development server has to be started again. Daytona keeps the filesystem when a sandbox stops, but not the memory state.

Disk snapshots are the right tool for skipping setup. Install dependencies once, snapshot, and start every later run from there. They are the wrong tool for undoing a mistake in the middle of a long task, because the task itself is gone.

02What does a memory snapshot capture?

A memory snapshot saves the machine's RAM and the CPU and device state alongside it, so restoring it continues execution where it stopped. In Firecracker, a snapshot is a guest memory file plus a microVM state file. The block devices are not part of it: Firecracker's docs say the disk files have to be handled by the user. A whole-machine checkpoint therefore pairs a memory snapshot with a copy of the disk taken at the same moment, or the restored memory will disagree with the files.

Cloud services that expose this describe it in similar terms. E2B's pause saves both the filesystem and memory state, including running processes and loaded variables, at about 4 seconds per GiB of RAM, and resumes in about 1 second. Modal's memory snapshots, documented as alpha, copy the sandbox's entire state, both in memory and on the filesystem, and running processes are still running after restore. Modal lists limits too: the snapshot expires after 7 days, taking it terminates the sandbox, and it can be restored only on the same instance type.

A third approach works below the VM. CRIU, checkpoint and restore in userspace, can freeze a running container or a single application on Linux and write its state to disk. It checkpoints processes rather than a machine, so anything outside those processes, such as the kernel or other containers, is not part of the snapshot.

• Disk snapshot: files only; processes restart; fast to share and keep.
• Memory snapshot: RAM, processes and device state; must be paired with the matching disk.
• Process checkpoint (CRIU): chosen processes only; the host kernel stays outside it.

03Do network connections survive a snapshot restore?

Usually not, at least not connections to the outside world. Firecracker's docs say to expect packet loss after resuming in a new process, that the state of network connections may not survive the restore, and that open vsock connections are closed. E2B says network connections drop on pause and clients must reconnect after resume. Modal says open TCP connections close and must be reopened.

The reason is that the other end did not pause. A remote server sees silence, times the connection out, and forgets it. CRIU can restore established TCP sockets using the kernel's TCP repair mode with --tcp-established, but it has to hold off the peer while the socket is down and needs the same IP address on restore, which is why it fits same-host restores and planned migrations.

Connections that live entirely inside the machine are a different case. A database and the app talking to it in the same VM are both in the snapshot, so they come back together. For agents, the practical rule is: expect calls to model APIs and external services to fail once after a restore, and make the agent retry.

04Is it safe to fork a VM for agents from one memory snapshot?

Forking means restoring one memory snapshot into several machines at once, which is how you run parallel attempts from the same warm state. Firecracker's docs flag the risk directly: they consider resuming execution from the same state more than once insecure, because unique identifiers, cached random numbers and cryptographic tokens are copied into every clone.

Firecracker notes that on Linux 5.18 and later its VMGenID device reseeds the guest kernel's random number generator on resume. Applications that cached their own randomness, session IDs or nonces still need to deal with it themselves. The guest clock also resumes from the moment of the snapshot and should be updated after restore.

For agents this adds one more reason to keep real credentials out of the sandbox. A short-lived token held in memory at snapshot time is held by every fork, and any of them can use it until it expires.

05What do memory snapshots cost in speed and storage?

A memory snapshot is roughly as large as the RAM in use, so it is slower to take and heavier to store than a disk snapshot of a small workspace. Restore can still be fast: Firecracker maps the memory file with MAP_PRIVATE, so pages load on demand as the guest touches them, at the price of keeping the memory file available for the whole life of the resumed VM. Diff snapshots store only memory changed since the last one, and generally have to be merged with a base before they can resume.

Retention differs widely between services. Modal keeps filesystem snapshots for 30 days by default and memory snapshots for 7. Vercel's snapshots expire 30 days after last use by default, adjustable to never. E2B keeps a paused sandbox until you kill it. Check this before you build an undo feature on top of someone's snapshots.

06Which snapshot does an AI agent need?

Match the snapshot to the question you want to answer later. If the question is how to start the next run faster, a disk snapshot after setup is enough. If it is how to undo the last five minutes without losing the running task, you need memory and disk captured together.

Many teams use both: a disk snapshot as the base image that every new sandbox starts from, and memory checkpoints during a task, discarded once the task is done and its results are committed.

• Faster starts: disk snapshot after dependencies are installed.
• Undo mid-task: memory plus disk, taken together, before the risky step.
• Parallel attempts from a warm state: memory snapshot forked into copies, with care for duplicated secrets and randomness.
• Long-term records: neither; keep logs and artifacts, because snapshots expire and are large.