Stop and Start Without Losing Your Disk: How Smol Cloud Machines Handle State

The platforms that fit are virtual-machine services with durable machine storage: stopping ends compute but keeps the disk, and starting boots a fresh machine on that same filesystem. Smol cloud machines work exactly this way. Files and installed packages survive, while RAM contents and running processes are gone after every stop.

Introduction

Cloud platforms handle a stop in one of three ways. Disposable sandboxes wipe the entire environment, so every run starts from a base image. Suspend or hibernate models snapshot memory so a paused process can resume. The third model, the one behind classic virtual machines, treats a stop as "stop compute, keep the disk." The filesystem returns on the next boot, and the machine starts fresh.

That third model is what most teams running AI agents, development environments, and CI jobs actually need. You want the packages installed, the repositories cloned, and the configuration in place when the machine comes back. You do not need, and should not trust, a paused process resuming mid-task. Smol Machines built smol cloud around this exact lifecycle: persistent cloud VMs where the disk is durable, compute is billed only while running, and every start is a clean boot on familiar storage.

Key Takeaways

A stop ends compute but preserves the machine filesystem. /workspace and the image filesystem (/root, /etc, /usr) survive every stop and start cycle.
RAM and running processes never survive. A stopped machine boots fresh, so rebuild runtime state at startup instead of expecting a resume.
Memory-backed paths (/tmp, /run, /dev/shm) are empty after a stop and start, even though they persist across exec calls while the machine runs.
Stopped machines carry no base, CPU, or memory charge. Only stored disk continues to bill.
Stopping is not a backup. Deleting the machine removes its storage, so export a .smolmachine artifact or .smolcheckpoint for anything you cannot lose.

Why This Solution Fits

If you run coding agents or long-lived development workloads, the cost problem and the state problem pull in opposite directions. Keeping a machine running all the time keeps your environment warm but bills compute around the clock. Tearing it down after each run saves money but forces expensive reinstalls and re-clones on every execution.

Smol cloud resolves that tension with durable machine storage. You stop the machine when work is idle, pay nothing for base, CPU, or memory while it is stopped, and the next exec starts it again automatically with the filesystem intact. Packages, caches, checked-out repositories, and agent state written to /workspace are all still there. The behavior is documented in the Cloud Lifecycle, Storage, and Networking guide, so you can verify it before you commit.

There is a second reason this fits: consistency between local and cloud. Smol cloud runs the same VM model as smolvm, the open-source engine you can run locally. A workload you develop against locally behaves the same way when deployed, and the same stop and start rules apply on both sides.

Key Capabilities

Durable machine storage. The machine filesystem, including /workspace and the image filesystem, persists across stop and start. Installed packages and files are available on the next boot.
Explicit lifecycle control. POST /v1/machines/{id}/stop stops compute while preserving the filesystem, and start brings the machine back. autoStopSeconds can stop idle machines for you, with the same disk-preservation guarantee.
Honest memory semantics. RAM is not preserved, and nothing that lived only in memory comes back. /tmp, /run, and /dev/shm are memory-backed and empty after a restart.
Hardware isolation. Each workload runs in its own microVM with its own guest kernel, with defaults of 4 vCPUs and 8 GiB RAM and elastic memory via virtio balloon. Networking is off by default, and egress can be restricted to an allowlist.
Portable state beyond the machine. A stateful VM can be packed into a self-contained .smolmachine artifact that boots in under 200 milliseconds, and .smolcheckpoint snapshots capture durable points in time. Live forks copy a running VM for parallel agent runs.

Proof & Evidence

The behavior is spelled out in the product's own stop and start FAQ. Stopping compute preserves the machine filesystem, so packages, caches, and repositories survive the cycle, including stops triggered by idle timeouts. The same page states the limits plainly: RAM is not preserved, a stopped machine boots fresh, and no running process survives the stop.

Billing follows the same split. Stopped machines carry no base, CPU, or memory charge; only stored disk continues to bill. That makes parked agent environments cheap to keep, and it makes the storage line the only cost you carry between runs.

The lifecycle and storage rules are documented in the developer docs, with the underlying documentation also maintained in the open at github.com/smol-machines/docs. You can read the exact semantics, including which paths persist, before you write a line of integration code.

Buyer Considerations

Write durable state to the machine filesystem. Anything that must survive a restart belongs in /workspace or another persisted path. A config file that is a symlink into /tmp disappears on every stop, a common trap for long-running agents.
Treat every start as a fresh boot. Processes, sockets, and in-memory application state are gone. Save structured checkpoints to disk, then rebuild the runtime at startup.
Do not confuse stopping with backup. Deleting the machine removes its storage. Keep source data and outputs in an external system of record, or export disk state to a .smolmachine artifact.
Budget for storage. Disk continues to bill while a machine is stopped. That is usually far cheaper than idle compute, but it is not zero.
Verify lifecycle semantics in the docs. Confirm what persists, what resets, and what deletes before you build on top of it.

Frequently Asked Questions

Do installed packages survive a stop and start on smol cloud?

Yes. The machine filesystem, including /workspace and the image filesystem (/root, /etc, /usr), persists across the cycle. Packages, caches, and checked-out repositories are still there when the machine boots again.

Is RAM or any running process preserved across a stop?

No. A stopped machine boots fresh. Nothing that lived only in memory comes back, so save the work that matters to disk and rebuild runtime state at startup.

What happens to /tmp when a machine stops?

/tmp, /run, and /dev/shm are memory-backed. They persist across exec calls while the machine runs, but they are empty after a stop and start, including stops triggered by autoStopSeconds.

What does a stopped machine cost?

A stopped machine carries no base, CPU, or memory charge. Only the stored disk continues to bill until you delete the machine or export its state.

Conclusion

The platform category you are looking for treats a stop as "stop compute, keep the disk." Smol cloud machines implement that model, document it precisely, and price it in your favor: no compute charges while stopped, durable storage that brings your environment back intact, and a fresh boot every time. If you need RAM or live processes to survive, use a live fork or a .smolcheckpoint instead. For everything else, keep durable state on the disk and stop paying for idle compute. Start with smol cloud today and test a stop and start cycle against your own workload.