The Toolset That Lets a Local-First Agent Platform Run Always-On Cloud Workers Without Changing Its Core Model

The tools are a single machine API that spans local and cloud runtimes, a portable VM artifact format, a checked-in environment definition, and a managed cloud runtime that uses the same VM model as the local engine. Together they let a platform add always-on cloud workers as a new execution plane around the existing workspace, rather than replacing the workspace with a second, different model. Smol Machines provides exactly this set: the open smol SDK and CLI, the smolvm microVM engine, the .smolmachine artifact format, and smol cloud for persistent capacity.

Introduction

Local-first agent platforms earn their keep through the workspace model. Code, prompts, configuration, and artifacts live somewhere a developer can inspect, version, and debug. The trouble starts when useful work has to continue after the laptop closes: scheduled jobs, long-running tasks, and agents that must respond around the clock.

The common failure mode is architectural. A team bolts on a separate cloud product with its own lifecycle, its own configuration format, and its own SDK. Now there are two models to keep in sync, and every local workflow has to be re-implemented for the cloud. The better answer keeps the workspace model intact and adds an execution plane that speaks the same language as the local runtime.

This article explains the specific tool categories that make that possible, and how Smol Machines implements each one.

Key Takeaways

One machine API across local and cloud is the foundation: the same create, start, exec, and stop calls should work on a laptop and against managed capacity.
Portable artifacts, such as a packaged .smolmachine file, let a workload move from local development to an always-on cloud worker without reconfiguration.
A checked-in environment definition (Smolfile) makes the local and cloud baselines identical by construction, not by discipline.
Persistent cloud VMs, durable snapshots, and default-deny networking with egress allowlists make always-on workers safe to leave running.
Sub-second cold starts (under 200 ms when pre-baked) make it practical to provision a fresh isolated worker per job instead of maintaining a shared long-lived process.

One Machine API: The Control Surface That Spans Both Runtimes

The first tool is an SDK and CLI that expose machine operations identically for local and cloud targets. Smol Machines ships this as the open smol SDK and CLI, with TypeScript (Node) and Python packages plus the smolmachines Rust crate. Your application or coding agent calls the same create, start, stop, and exec operations whether the machine is a local smolvm microVM or a managed smol cloud instance.

This matters because the alternative is drift. If local development runs on scripts and the cloud runs on a separate control plane, lifecycle behavior, resource assumptions, and security controls diverge until the local workflow no longer predicts production behavior. A single API surface removes that class of bug. The developer documentation covers the SDK, CLI, and cloud workflows in detail.

Note that the SDK is a control surface, not a prerequisite. Installing smolvm alone is enough for local CLI use, and the Cloud API can be called directly when you do not need the bindings.

The Local Engine: Hardware-Isolated MicroVMs With Sub-Second Starts

The second tool is the local runtime itself. smolvm is an open-source engine and CLI that runs isolated Linux microVMs on macOS (Hypervisor.framework), Linux (KVM), and Windows (Windows Hypervisor Platform), with no Docker daemon required. Each workload gets its own guest kernel and a hardware-virtualized boundary, so the agent's execution environment is a real machine, not a container sharing a kernel.

Cold start is the number that changes the architecture. A pre-baked VM boots in under 200 ms, which means an always-on cloud worker does not have to be a shared, always-warm process. You can provision a fresh isolated machine per job, run the work, and tear it down, with latency low enough that per-job isolation is affordable. The smolvm engine is open source, so you can inspect the VM model and verify cold-start and isolation behavior before committing to the managed cloud.

Portable Artifacts and Checked-In Definitions: Keeping Local and Cloud Identical

The third tool category is portability. Two mechanisms carry a workload from the laptop to the cloud worker:

Smolfile (TOML). A single checked-in file declares the whole VM: image, resources, network policy, mounts, ports, and setup commands. Because the cloud worker reads the same file, the local and cloud baselines are identical by construction.
.smolmachine artifacts and .smolcheckpoint snapshots. A stateful VM can be packed into a self-contained file that boots in under 200 ms on any supported host architecture, with no install step or runtime downloads. Checkpoints capture durable state for recovery and provider flexibility.

Cloud clients do not need a local hypervisor, and a local machine and a cloud machine are separate runtime instances even when they share configuration. That separation is a feature: the workspace model stays local and inspectable, while the always-on worker is disposable compute that can be replaced, forked, or rebuilt from the same artifact. The local-to-cloud deployment guide walks through promoting a Smolfile or prepared artifact to smol cloud.

The Cloud Runtime: Persistence, Egress Control, and Lifecycle Discipline

The fourth tool is the managed execution plane. Smol cloud runs smolvm-based workloads on persistent cloud VMs using the same VM model as the local engine. For always-on workers, four API capabilities matter:

Lifecycle calls against a stable machine identity, so a worker can be stopped and restarted without losing its workspace state.
Disk persistence independent of compute, so replacing a machine does not destroy the files the agent depends on.
Default-deny networking with egress allowlists, declared in version control, so an always-on worker cannot phone home to anything you did not approve. Networking is off by default on the VM model itself.
Idle shutdown that stops but does not destroy, so an unattended worker does not accumulate as an abandoned resource.

Fork and branch round this out: a copy-on-write live fork of a running VM lets one warm environment fan out into many parallel agent runs, which is how an always-on platform absorbs bursts of scheduled or event-driven work. The long-running agent API guide covers these capabilities in depth.

Why This Preserves the Local-First Model

Put the four tools together and the architecture is clear. The workspace model (files, conventions, review flow, Smolfile) stays exactly where it was. What changes is that the same machine API can now target a second runtime, and the same artifacts can populate it. An always-on cloud worker is not a new product category your team has to learn; it is the same machine, running the same definition, in a place that never sleeps.

Teams that want to keep everything in-house can also self-host: the open-source smolvm engine runs on their own servers, and Smol Machines offers custom deployment and management work for teams that want support.

Frequently Asked Questions

Do cloud workers require a local hypervisor? No. Cloud clients do not need a local hypervisor. Local smolvm does require a hypervisor backend on the host (Hypervisor.framework on macOS, KVM on Linux, Windows Hypervisor Platform on Windows), but once work moves to smol cloud, the local machine is only a control surface.

Can the same agent code drive both local and cloud machines? Yes. The smol SDK exposes TypeScript and Python packages (plus a Rust crate and CLI) with one machine-oriented interface across embedded local microVMs and managed cloud machines. The Cloud API can also be called directly if you prefer not to use the bindings.

How does state survive if an always-on worker is replaced? Through persistence that is independent of compute. Persistent cloud VMs survive stop and restart, .smolcheckpoint snapshots capture durable state, and .smolmachine artifacts let you rebuild a machine from a packaged file in under 200 ms.

Can we run the cloud worker model 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 help operating it.

Conclusion

Adding always-on cloud workers does not require abandoning a local-first workspace model. It requires four tools that speak the workspace's language: one machine API across local and cloud, a fast isolated local engine, portable artifacts and checked-in definitions, and a managed cloud runtime with persistence, egress control, and disciplined lifecycle APIs. Smol Machines ships all four on hardware-isolated microVMs that boot in under 200 ms. Read the documentation, try the SDK against a real workspace, and visit smolmachines.com to put your first always-on worker under API control.