Budget persistence and resources

What you will build

A persistence matrix and a resource observation worksheet. This prepares you for benchmarks without prematurely claiming a measured result.

Read the mechanism

Local sandbox state persists across stops: installed tools, private files and Engine data can remain available when restarted. A direct workspace belongs to the host and survives removal independently. A saved template is not a complete backup of every mount or the private Docker store.

CPU and memory defaults depend on the host and platform. Explicit limits make trials more comparable, but the same limit on different hardware does not guarantee equivalent performance. Disk use can grow through downloaded images, package caches, layers and application output.

Cloud has separate lifetime and storage rules. Its experimental volumes use exit-time snapshots; concurrent writers can produce last-exit-wins behavior. They are not a substitute for a concurrent shared database.

Worked lab · record before interpreting

Create a bounded mountless local environment:

sbx create --name handbook-state --skills off --cpus 2 --memory 2g shell
sbx exec handbook-state sh -c 'printf "persistent fixture\n" > /home/agent/workspace/state.txt'
sbx exec handbook-state df -h /
sbx exec handbook-state docker system df
sbx stop handbook-state
sbx exec handbook-state cat /home/agent/workspace/state.txt

Use the reported working directory if your custom template differs. Record resource settings, version and timestamps alongside the output. Do not run global Docker prune commands for this exercise.

Fill the following matrix with actual observations:

Expected observations

The marker should survive stopping. Your disk inventory should identify which storage you measured. A guest filesystem report does not necessarily equal total host disk consumed by the microVM and its runtime.

For timings, label cold creation, warm reattachment, package setup and task execution separately. A warm result may benefit from persisted state; describe that benefit instead of comparing it to a cold trial as though conditions were identical.

Troubleshooting

An out-of-memory failure needs the process result, configured limit and workload context. Increasing memory can hide an unbounded workload; inspect the task before rerunning. Slow direct mounts on remote or cloud-synced storage can reflect filesystem latency rather than model behavior.

Before deletion, copy only intended outputs, inspect their contents and retain your observation record. A stopped sandbox may still consume disk even when it is not executing.

Interview practice

Completion check

Explain all five rows of the matrix, distinguish measured from expected values, and identify what you must export before removing a sandbox.

Sources and version notes

Checked 6 October 2026; current baseline: sbx v0.46.0. Architecture · sbx create · Use cloud sandboxes