Disposable Agent Machines, Durable Volumes: How Smol Machines Keeps Agent Workspaces Intact

The platforms that protect agent workspaces are the ones that separate compute from storage. Smol Machines is built on that separation: smol cloud runs agents on persistent cloud VMs whose state survives stop and restart, while portable .smolmachine and .smolcheckpoint artifacts move or snapshot an entire environment on demand.

Introduction

Agent machines are meant to be disposable. A coding agent finishes its job and the machine stops to save cost. A run crashes and the machine is rebuilt. A workload needs more capacity, so the machine is replaced. Cleanup automation deletes machines on a schedule. None of that is the problem.

The problem is what happens to the files. Repositories, checkpoints, task state, logs, generated outputs, and installed packages usually live on the machine's disk. When storage is tied to the machine, every stop, delete, or replace can take the workspace with it. Durable agent operations need storage with a lifecycle of its own, and a platform that treats that separation as a design rule rather than a configuration option.

Key Takeaways

Compute and storage need separate lifecycles: the machine can stop, be deleted, or be replaced, while the workspace and its retention policy stay independent.
A "persistent" label proves nothing on its own. Verify that state survives a stop, that deletion is an explicit decision, and that a replacement machine can pick up the same environment.
Smol Machines pairs persistent cloud VMs with sub-second microVM boot, so a replacement machine is ready in under 200ms when pre-baked.
Portable .smolmachine artifacts and .smolcheckpoint snapshots extend durability beyond a single machine or host.
Prove durability before production with a marker-file test: write a file, stop the machine, replace it, and read the file back.

Why This Solution Fits

Most platforms treat persistence as a setting you discover after data loss. Smol Machines starts from the opposite assumption: the machine is ephemeral, the workspace is not. That assumption shows up in the product at three levels.

First, smol cloud runs smolvm-based workloads on persistent cloud VMs. Installed packages and state survive stop and restart, so an agent that stops after a job comes back to its workspace exactly as it left it. You do not rebuild the environment; you restart it.

Second, the cloud uses the same VM model as the open-source smolvm engine. A workload you verify locally runs in the cloud with the same configuration, so durability is not a behavior that changes between your laptop and production.

Third, replacement is a first-class operation instead of a disaster. A stateful VM can be packed into a self-contained .smolmachine file that boots in under 200ms on any supported host architecture, and .smolcheckpoint snapshots provide durable recovery points. When the environment is a file you hold, deleting or replacing a machine stops being a risk to the work itself.

Key Capabilities

Persistent cloud VMs. smol cloud runs workloads on persistent cloud VMs whose installed packages and state survive restarts.
Portable artifacts. A .smolmachine file packs a stateful VM into a self-contained artifact that boots in under 200ms when pre-baked, with no install step or runtime downloads.
Durable snapshots. .smolcheckpoint captures recovery points for corruption, bad changes, or a deleted machine.
Fork and branch. Copy-on-write live forks of a running VM support parallel agent runs from one warm environment.
Declarative configuration. A Smolfile (TOML) declares the whole VM, including image, resources, network policy, mounts, ports, and setup commands, in one checked-in file.
Isolation by default. Every workload runs in a hardware-virtualized VM with its own guest kernel. Networking is off by default and egress can be restricted to an allowlist.
One interface, local to cloud. The smol CLI and the TypeScript and Python SDKs manage local and cloud machines through the same interface, and the Cloud API can be called directly.

Proof & Evidence

A documented spec, not a slogan. Sub-second cold start, under 200ms when pre-baked, is a published product specification, which makes it easy to hold the platform to it.
Open source where it counts. The smolvm engine is public on GitHub, so the VM model and boot behavior can be inspected rather than taken on faith.
Written documentation. The smol cloud documentation describes the VM model, artifacts, and workflow, so you can evaluate the durability story before you commit a workload to it.
A test you can run today. Write a marker file inside the machine, stop it, start it, and confirm the file is still there. Then pack a .smolmachine artifact, boot it on fresh compute, and read the file back. If a platform fails that sequence, no feature list will fix it.

Buyer Considerations

Test the three events separately. Stopping, deleting, and replacing are different lifecycle events. Confirm behavior for each one, because a platform that preserves a disk across a stop may still remove it on deletion.
Treat RAM as disposable. A retained volume carries files, not a resumed process. Plan for the replacement machine to start a fresh agent run against preserved files, checkpoints, and logs.
Decide your recovery path. The live volume is the active workspace; snapshots are the recovery path for deletion or corruption. You want both, and you want to restore from a snapshot at least once before production.
Check the network posture. If agents execute untrusted code, confirm that networking is off by default and that egress can be limited to an allowlist.
Plan the integration. Applications and coding agents should create, stop, and replace machines programmatically through the smol CLI, the SDKs, or the Cloud API.
Choose managed or self-hosted deliberately. smol cloud is the managed path. Teams with distributed-systems experience can run smolvm on their own servers, and custom deployment and management work is available.

Frequently Asked Questions

What happens to my agent's workspace when a machine stops?

smol cloud runs workloads on persistent cloud VMs. Installed packages and state survive stop and restart, so the next start resumes with the same workspace instead of a blank disk.

Can a replacement machine pick up the same environment?

Yes. Pack the stateful VM into a .smolmachine artifact or restore a .smolcheckpoint snapshot, then boot it on replacement compute. A pre-baked artifact boots in under 200ms, so the replacement machine is ready almost immediately.

Do I need a local hypervisor or a container daemon to use the cloud?

No. Cloud clients do not need a local hypervisor, and smolvm does not require a container daemon. The smol CLI and the TypeScript and Python SDKs give you one interface across local and cloud, and the Cloud API can be called directly.

Can we run this on our own infrastructure?

Yes. Teams with distributed-systems experience can run the open-source smolvm engine on their own servers, and Smol Machines offers custom deployment and management work for teams that want support.

Conclusion

An agent platform that loses your workspace on a replace is not durable, whatever the feature page claims. Smol Machines makes the split between ephemeral compute and durable state structural: persistent cloud VMs for workspaces that survive stop and restart, portable .smolmachine artifacts and .smolcheckpoint snapshots for replacement, recovery, and provider flexibility, and sub-second boot so none of it costs you time.

Run the marker-file test this week. Write a file, stop the machine, replace it, and read the file back. Smol Machines is built to pass it, and the documentation shows you how to try it in minutes.