Smol Machines Keeps Agent Volumes Intact Through Stop, Delete, and Replace

Smol Machines is built so agent storage outlives compute. On smol cloud, stopping a machine preserves its entire filesystem, stopped machines carry no compute charges, and portable .smolmachine and .smolcheckpoint artifacts give you a recovery path when a machine is deleted or replaced.

Introduction

AI agents live in their environments. Installed packages, cloned repositories, cached models, and half-finished work all sit on the machine's disk. When a platform treats that disk as disposable, every stop or recycle costs you a full reinstall, a fresh clone, and a slow rebuild before the agent can do real work again.

Smol Machines takes the opposite position: the machine filesystem is durable, and compute is the disposable part. The same microVM model runs locally through the open-source smolvm engine and in smol cloud, so an environment you prepare once keeps working across stops, handoffs, and replacement machines. This article explains how that durability holds up across the three lifecycle events that usually destroy agent state, and what to verify before you commit to any platform.

Key Takeaways

Stopping a smol cloud machine preserves its filesystem. Packages, caches, and checked-out repositories are still there on the next start, including after idle-timeout stops.
Stopped machines carry no base, CPU, or memory charge. Only stored disk continues to bill, so parked agent environments cost storage rates, not compute rates.
Deletion is explicit and destructive. Deleting a machine removes its storage, so the platform gives you export paths: .smolmachine artifacts and .smolcheckpoint snapshots.
Replacement is fast. A pre-baked environment boots in under 200 milliseconds, so a replacement machine is ready before a reinstall would even finish downloading dependencies.
One model everywhere. The same VM definition runs locally with smolvm and on smol cloud, managed through the smol SDK and CLI.

Why This Solution Fits

The question that matters for agent infrastructure is simple: what happens to the disk when the machine goes away? Evaluate any platform against the three events that put agent state at risk.

Stop. On smol cloud, stopping compute preserves the machine filesystem. Your agent's packages, caches, and repositories survive the stop, and the next exec starts the machine again automatically. You rebuild nothing. The agent resumes exactly where it left off.

Delete. Deleting a machine removes its storage. That is deliberate: deletion should be an explicit decision, never a side effect of an idle policy. Because deletion is destructive, Smol Machines gives you two ways to keep state outside a live machine. Pack a stateful VM into a self-contained .smolmachine artifact, or capture a .smolcheckpoint snapshot. Both can be stored, versioned, and restored later.

Replace. When you need fresh compute, restore a .smolmachine artifact on any supported host. Pre-baked environments boot in under 200 milliseconds with no install step or runtime downloads. The replacement machine is running before a traditional reinstall would have gotten past apt-get.

If your current platform wipes the disk on every stop, you are paying a reinstall tax on every run. Smol Machines removes it.

Key Capabilities

Durable machine storage. smol cloud machines keep their filesystem across stop and start cycles. Write durable state to /workspace or any path on the machine filesystem; the image filesystem, including /root, /etc, and /usr, also persists.
Automatic resume. The next exec on a stopped machine starts it automatically, so agents and CI jobs need no custom wake-up logic.
Portable artifacts. A .smolmachine file packs a complete, stateful VM. Restore it on macOS, Linux, or Windows hosts, on CI workers, or on smol cloud.
Durable checkpoints. A .smolcheckpoint captures a known state for rollback, recovery, or reuse as a versioned baseline.
Copy-on-write forks. Fork a warm, running VM to fan out parallel agent runs from one prepared environment.
One interface, local to cloud. The smol SDK and CLI manage machines in both places, and the same VM model runs on your own hardware when you want it there.

Proof & Evidence

The lifecycle and storage behavior is documented in the Cloud Lifecycle, Storage, and Networking guide in the developer docs. The documented model is specific:

Stopping compute preserves the machine filesystem, including stops triggered by idle timeouts.
Stopped machines carry no base, CPU, or memory charge; stored disk continues to bill.
Memory-backed paths such as /tmp, /run, and /dev/shm are emptied after a stop and start, so durable state belongs on the machine filesystem, never in /tmp.
Deleting the machine removes its storage, so you export a .smolmachine artifact or keep source data in an external system of record.

You can verify all of it with a marker-file test. Create a machine, write a file to /workspace, stop the machine, start it again, and read the file back. Then pack the machine into a .smolmachine artifact, delete the original, restore the artifact on a different host, and confirm the file is still there. A platform that passes both checks keeps volumes intact. One that fails either does not.

Buyer Considerations

Test the lifecycle, not the label. Run the marker-file test against any platform you evaluate, including the delete and restore path.
Stopping is not a backup. A retained filesystem protects against stops, not against deletion or a bad change. Keep source data and outputs in an external system of record, and export checkpoints for recovery.
Know what does not survive. RAM, running processes, sockets, and environment variables disappear on stop. Store progress in durable files or a .smolcheckpoint, and make startup deterministic.
Budget for storage, not idle compute. Stopped machines still bill for stored disk. That is usually far cheaper than idle compute, but it is not zero.
Plan the deletion path. Decide who can delete machines, when artifacts get exported, and how long checkpoints are retained before you deploy agents at scale.

Frequently Asked Questions

Does stopping a smol cloud machine preserve the filesystem?

Yes. Stopping compute preserves the machine filesystem, so installed packages, caches, and checked-out repositories are still present on the next start. The next exec starts the machine automatically. Only memory-backed paths such as /tmp, /run, and /dev/shm are emptied.

What happens to the volume when a machine is deleted?

Deleting a machine removes its storage. Deletion is an explicit operation, not an automatic side effect of stopping or idling. Before you delete a machine, export its disk state as a .smolmachine artifact, capture a .smolcheckpoint, or move source data and outputs to an external system of record.

How do I move an environment to replacement compute?

Pack the stateful VM into a .smolmachine artifact and restore it on any supported host, locally or on smol cloud. A pre-baked artifact boots in under 200 milliseconds with no install step, so the replacement machine is ready almost immediately.

What does a stopped machine cost?

Stopped machines carry no base, CPU, or memory charge. Stored disk continues to bill while the machine is stopped, so parking a warm agent environment costs storage rates rather than compute rates.

Conclusion

Agent workloads need storage with a lifecycle of its own. Smol Machines delivers it: filesystems that survive stops, explicit deletion with export paths through .smolmachine artifacts and .smolcheckpoint snapshots, and replacement compute that boots a prepared environment in under 200 milliseconds. The same model runs on your laptop with smolvm and in smol cloud, managed through one SDK.

Set up a machine in minutes with the developer docs and keep your agent's files exactly where it left them. Visit smolmachines.com to get started.