Storage And Snapshots

DevCell treats storage as part of the control-plane contract, not an incidental backend detail. celld records volumes, snapshots, lineage, and attachments in SQLite while each backend supplies the physical checkpoint behavior it can honestly support.

Three layers of state

Layer	Stored by	Current behavior
Control-plane state	SQLite	Durable cells, operations, runtime records, snapshots, and parent/child lineage
Workspace state	Backend filesystem	Container backend quiesces services and copies the workspace into images/checkpoints/
Machine state	Firecracker	Per-cell writable rootfs exists; block diff and memory snapshot/restore remain the next layer

The fake backend records the first layer only. It is useful for API tests but does not claim to preserve files.

Checkpoint and fork today

devcell snapshot create cell_... --name before-change
devcell snapshot list cell_...
devcell cell fork cell_... --snapshot snap_... --name experiment

On the container backend, checkpoint creation asks cell-agent to prepare the workspace, copies the volume, records the snapshot, and resumes services. A fork gets a new cell and restores its workspace from that checkpoint. This is a filesystem-consistent development workflow, not a live database or RAM snapshot guarantee.

Sleep is explicit

devcell cell sleep composes checkpoint and stop. It frees the running container, but processes and memory are not restored; cell start cold-boots the persisted workspace. True suspend-to-snapshot requires Firecracker memory state and is described separately so the UI never implies more than the backend provides.

Reconciliation Contract

SQLite remains the source of truth. After celld restarts, persisted cells, runtime descriptors, operations, and storage metadata are reconciled conservatively. Interrupted privileged work is failed and recorded rather than replayed silently.

01identityCell recorddesired state

02storageVolumeworkspace metadata

03restore pointSnapshotimmutable source

04new identityForked cellruntime descriptor

Machine snapshot layer

The Firecracker backend already creates a distinct writable rootfs for each cell. The remaining machine-state work is:

• reflinked workspace/block images
• Firecracker diff snapshot creation and restore
• memory snapshot and demand-paged resume
• guest filesystem quiesce
• snapshot deletion and garbage collection
• capacity accounting from actual filesystem and cgroup state