Skip to main content
A checkpoint captures the sandbox’s filesystem. Restoring puts those files back.
Checkpoints on v2 do not capture live memory. Restoring gives you your files back on a freshly booted sandbox — not a process tree resumed mid-execution.

​
Why

The current runtime can snapshot a running VM’s memory because we operate the hypervisor. The v2 platform exposes no snapshot or memory-export operation at all, so a filesystem archive is the only checkpoint that can exist here. This is an API ceiling, not a missing feature.

​
What this changes for you

If you checkpoint an installed environment — dependencies, a built toolchain, a seeded database directory — nothing changes. That is a filesystem, and it restores exactly. If you checkpoint a warmed process — a loaded model, an open connection pool, a debugger paused at a breakpoint — that state is gone on restore. Your process starts again from scratch, with its files in place. The practical test: if you would be happy with the result of reboot plus your files, a checkpoint gives you that.

​
The kind argument

The current runtime accepts kind: "full" for a memory-inclusive checkpoint. Here:
  • omitting kind, or asking for disk_only, works and produces a filesystem checkpoint
  • explicitly asking for full is refused, rather than quietly giving you a disk-only checkpoint under a name that promises more

​
Restore is in-place

restoreCheckpoint rolls the current sandbox’s filesystem back to the checkpoint. It does not create a new sandbox.
Forking a new sandbox from a checkpoint is not available yet. createFromCheckpoint fails on v2. It is being worked on. Until then, restore into an existing sandbox.

​
Checkpoints outlive their sandbox

A checkpoint is stored durably and is not bound to the sandbox that produced it. That makes it the tool for surviving the 8-hour ceiling: checkpoint before the deadline, then restore onto a sandbox you create later.