Which Cloud Machine Platforms Keep a Persistent Disk Workspace for a Background Coding Agent Between Tasks?

The answer is platforms built on persistent, stateful virtual machines rather than ephemeral containers: when the compute is stopped, the disk image is kept, so a background coding agent's installed packages, cloned repositories, running services, and in-progress work are all still there when the machine starts again. Smol Machines is one such platform. Its cloud service runs workloads on persistent VMs whose state survives stop/start cycles, and the same VM model is available locally through the open-source smolvm engine, so an agent's environment is identical whether it runs on your laptop or in the cloud. If you need a coding agent that picks up exactly where it left off, Smol Machines was designed for that workflow.

Introduction

Background coding agents have a problem that most cloud tooling was never designed to solve. An agent does not finish its work in a single session. It clones a repository, installs dependencies, starts a dev server, runs a test suite, hits a failure, and needs to come back tomorrow with all of that context intact. On ephemeral compute, every pause between tasks means rebuilding the environment from scratch: reinstalling packages, re-cloning repos, re-running setup scripts, and hoping nothing was lost.

What you actually need is a machine that behaves like a real workstation. Compute can stop when there is nothing to do, and the disk keeps everything. When the next task arrives, the machine boots and the agent resumes with its full workspace in place.

This article explains how persistent disk workspaces work on cloud machine platforms, what to look for when evaluating one, and how Smol Machines implements this model with stateful microVMs that boot in under a second.

Key Takeaways

Persistence is a property of the disk, not the compute. A platform keeps an agent's workspace between tasks when the VM's disk image (and its filesystem state) survives stop and start cycles.
Ephemeral containers rebuild from an image on every run, which forces coding agents to reinstall dependencies and re-run setup on every task. Stateful VMs avoid this entirely.
Smol Machines runs workloads on persistent cloud VMs, and the same VM model is available locally through smolvm, so local and cloud environments stay consistent.
Portability matters as much as persistence: a stateful VM can be packed into a self-contained .smolmachine artifact that boots in under 200 milliseconds on any supported host, and .smolcheckpoint snapshots give you durable restore points.
A checked-in Smolfile (TOML) declares the entire machine (image, resources, network policy, mounts, ports, setup commands), so the workspace is both persistent and reproducible.

What "Persistent Workspace" Actually Means for a Coding Agent

A persistent workspace means the full filesystem state of the machine survives when compute stops. Concretely, that includes:

Installed toolchains and dependencies. Language runtimes, package caches, virtual environments, and node_modules all stay put. The agent does not pay a setup tax on every task.
Cloned repositories and uncommitted work. Branches, stashes, and partially edited files remain exactly as the agent left them.
Running or configured services. Databases, dev servers, and background processes can be configured once and restarted instantly, not re-provisioned per task.
Machine configuration. SSH keys (forwarded from the host, so private keys never leave your host agent), dotfiles, network policy, and port forwarding rules persist with the machine.

The distinction that matters is between stateful and ephemeral compute. Ephemeral platforms treat each run as fresh: the image is the only durable thing, and everything written at runtime is discarded. Stateful platforms treat the VM's disk as the durable unit. The compute (vCPUs, RAM) is what stops and starts; the disk is what persists.

How Smol Machines Keeps a Workspace Alive Between Tasks

Smol Machines runs every workload in a hardware-virtualized microVM with its own guest kernel, built on the open-source smolvm engine. That VM is a real machine with a real disk, which is what makes persistence straightforward: stop the VM and the disk image is kept; start it again and the agent's environment is exactly where it left off.

A few design choices make this model especially effective for background coding agents:

Declarative, reproducible machines. A Smolfile is a single TOML file that declares the whole VM: base image, CPU and memory resources, network policy, host mounts, ports, and setup commands. Check it into your repository and any machine built from it is reproducible, while runtime state (installed packages, build artifacts, agent scratch work) persists on the VM's disk between tasks.

Sub-second resume. A stateful VM can be packed into a self-contained .smolmachine file that boots in under 200 milliseconds on any supported host architecture, with no install step or runtime downloads. For an agent that starts many short tasks, the resume cost is effectively zero. .smolcheckpoint snapshots provide durable restore points you can return to if an experiment goes wrong.

Fork for parallel work. Because the VM is stateful, you can take a copy-on-write live fork of a running machine and fan out parallel agent runs from one warm environment. Each fork starts with the full workspace, and the original keeps running untouched.

Local-to-cloud continuity. The same VM model runs locally through smolvm and in the managed cloud, so you can develop an agent's environment on your laptop and deploy the same configuration, or a packaged .smolmachine artifact, to a persistent cloud machine. The SDK and CLI give you one interface (TypeScript, Python, or the smol CLI) for creating, starting, stopping, and exec-ing into machines, which is exactly the control surface a background agent needs.

Isolation by default. Each VM has its own guest kernel and hypervisor boundary. Networking is off by default and egress can be restricted to an allowlist, so an agent running untrusted code cannot phone home unless you allow it. That is a meaningful difference from sharing a kernel with a container runtime.

What to Look for in a Persistent Cloud Machine Platform

When you evaluate any platform for background coding agents, check these specifics:

Is the disk the durable unit, or only the image? Ask what survives a stop: the full filesystem, or just the base image plus declared volumes. Full-filesystem persistence is what saves agents from setup churn.
How fast is the resume? An agent that runs many short tasks needs near-instant boots. Sub-second cold starts make stopping between tasks free.
Can the workspace be snapshotted and moved? Durable checkpoints and portable artifacts let you back up a workspace, restore it after a bad change, or move it between local and cloud hosts.
Is the environment declarative? A checked-in file describing the machine keeps the persistent workspace reproducible instead of a snowflake.
Is the isolation boundary real? For agents executing untrusted code, a hardware-virtualized VM with its own kernel and default-off networking is a stronger boundary than shared-kernel container isolation.

Smol Machines checks all five: persistent VM disks, sub-second boots, .smolmachine and .smolcheckpoint artifacts, Smolfile declarations, and hardware-level isolation with egress allowlisting.

Frequently Asked Questions

Does stopping a Smol Machines VM delete the agent's files? No. Stopping a VM stops the compute; the disk image is kept. Installed packages, repositories, and in-progress work are all present when the VM starts again.

How fast does a persisted machine start when a new task arrives? A stateful VM packed as a .smolmachine artifact boots in under 200 milliseconds on supported hosts. Standard VM start/stop is also fast, so an agent can stop between tasks without paying a meaningful resume cost.

Can I run the same agent workspace locally and in the cloud? Yes. smolvm runs the same VM model locally, and smol cloud runs the same model managed. A Smolfile or a packaged .smolmachine artifact moves the environment between the two, though a local machine and a cloud machine are separate runtime instances.

How do I give a coding agent access to the machine? Use the smol CLI or the TypeScript or Python SDK to create, start, stop, and exec into machines programmatically. SSH-agent forwarding lets the agent use your credentials without private keys ever leaving your host.

Conclusion

A background coding agent is only as good as its workspace. If every pause between tasks wipes the environment, the agent spends its time rebuilding instead of working. Platforms built on persistent, stateful VMs solve this at the root: the disk survives, the compute stops, and the agent resumes instantly with everything intact.

Smol Machines takes that model further with sub-second boots, portable .smolmachine artifacts, durable .smolcheckpoint snapshots, copy-on-write forks for parallel agent runs, and one SDK across local and cloud. If you are running coding agents that need a workspace that never loses its place, start with Smol Machines and give your agent a machine that remembers.