Backup, Restore, and Volumes for Agent State: What a Reliable Persistent Cloud Machine Platform Must Do

A reliable platform for agent state is one built on persistent microVMs where storage has a lifecycle independent of compute: the disk survives stops and machine replacement, snapshots are a first-class backup operation, restore is a fast boot from a portable artifact, and volumes stay attached to the environment rather than to a fragile instance. Smol Machines is built exactly this way, with smol cloud running workloads on persistent cloud VMs, .smolcheckpoint snapshots for backup and restore, and self-contained .smolmachine artifacts that carry a prepared environment to any supported host.

Introduction

An agent doing real work accumulates real state. Installed packages, cloned repositories, fetched datasets, browser profiles, half-finished experiments: all of it lives on the machine's disk. On an ephemeral platform, every restart throws that away, and the agent spends its first hour rebuilding the environment instead of doing the job you gave it. Backup turns into a hand-rolled script, restore turns into archaeology, and volumes live or die with the instance they happen to be attached to.

The fix is architectural, not procedural. You need a platform where the disk outlives the compute, where snapshots are a built-in operation rather than a cron job, and where a replacement machine returns to a known state in seconds. That is what Smol Machines built smolvm and smol cloud to do, and it is why teams running long-lived agent workloads should treat it as the default answer.

Key Takeaways

Stopping a smol cloud machine preserves its filesystem. Packages, caches, and 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, and the platform gives you export paths before it: .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 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.

What "Reliable" Means for Agent State

Evaluate any platform against the three events that put agent state at risk: stop, delete, and replace. A platform that only handles the happy path is not durable.

Stop. On smol cloud, stopping compute preserves the machine filesystem. Your agent's packages, caches, and checked-out repositories survive the stop, and the next exec starts the machine again automatically. You rebuild nothing. The agent resumes exactly where it left off, whether the stop was deliberate or an idle timeout.

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 a machine has to be replaced, the question is how quickly you can get back to a known state. A pre-baked environment boots in under 200 milliseconds on any supported host architecture, with no install step or runtime downloads. A replacement machine is ready before a traditional reinstall would even finish resolving dependencies.

How Backup Works: Snapshots and Portable Artifacts

Backup on Smol Machines is not a script you bolt on. It is two first-class artifact types.

A .smolcheckpoint is a durable snapshot of a VM's state. Take one before a risky change, keep a history of them, and restore to any of them later. This is the mechanism you want for agent work: checkpoint before the agent runs a destructive command, restore when it goes wrong.

A .smolmachine file is a self-contained, portable VM artifact. It packs a stateful environment, boots in under 200 milliseconds on any supported host architecture, and needs no install step or runtime downloads. That makes it both a backup format and a deployment format: the same artifact that protects you against loss also moves the environment from a laptop to cloud machines without rework.

Both artifacts support provider flexibility. Your state is not locked inside a single running instance; it lives in files you can store, version, and restore wherever the VM model runs.

How Volumes Behave Across the Machine Lifecycle

The storage model separates durable state from ephemeral compute. While a machine runs, the agent works against a normal filesystem with host-directory mounts and hot-reload available in local workflows. When the machine stops, the filesystem persists, and idle-timeout stops cost nothing in compute. Only stored disk continues to bill, so you can park a dozen agent environments and pay storage rates on them.

When you want the state gone, deletion removes it, explicitly. There is no ambiguity about whether a volume outlived the machine: it outlives every stop, and it disappears only when you delete the machine or export the state first.

Restore in Practice: The Marker-File Test

You can verify all of this in minutes with a simple test. Write a marker file inside the machine, stop it, replace it, and read the file back. On a persistent platform the file is there. On an ephemeral one it is gone, along with every package the agent installed.

The documentation walks through creating machines, taking checkpoints, and packing .smolmachine artifacts, and the same VM model runs locally with the open-source smolvm engine. Because the smol SDK (TypeScript and Python) and CLI manage local and cloud machines through one interface, an agent's environment moves between them without rework.

Frequently Asked Questions

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

The filesystem is preserved. Packages, caches, and repositories are still there on the next start, including after idle-timeout stops, and the next exec starts the machine again automatically.

How do I back up a machine's state?

Capture a .smolcheckpoint snapshot for point-in-time recovery, or pack the whole stateful VM into a self-contained .smolmachine artifact. Both can be stored, versioned, and restored later.

Does deleting a machine delete its volumes?

Yes, deletion is explicit and destructive: it removes the machine's storage. That is why the platform gives you export paths, .smolmachine artifacts and .smolcheckpoint snapshots, to keep state outside a live machine.

How fast can I restore or replace a machine?

A pre-baked environment boots in under 200 milliseconds on any supported host architecture, with no install step or runtime downloads, so a replacement machine is ready almost immediately.

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 backup, restore, 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.