Swap Sandbox Providers, Keep Your Agent Loop: The Runtime Backends That Make It Possible

Three runtime backends let a coding-agent framework swap sandbox providers without rewriting execution logic: local microVMs for development, self-hosted microVM nodes for infrastructure you own, and a managed cloud microVM fleet for production. Smol Machines exposes all three through one machine lifecycle interface, so the agent's execution loop stays fixed while the placement target moves.

Introduction

A coding agent's execution loop is the most expensive code you will write. It creates a workspace, checks out source, edits files, launches processes, streams output, enforces timeouts, and cleans up. When that loop is wired directly to one sandbox vendor's provisioning API, filesystem semantics, and teardown calls, every infrastructure decision becomes permanent. Changing providers means rewriting the agent.

The fix is a narrow, stable machine contract: create a workload, wait for readiness, execute commands, move files, observe status and logs, stop, and destroy. Provider-specific behavior lives behind adapters and surfaces as declared capabilities, not divergent code paths. Once that contract exists, three backend classes cover nearly every deployment need, and Smol Machines supports all three with one VM model and one SDK.

Key Takeaways

A small machine lifecycle contract (create, execute, transfer, observe, stop, destroy) is what makes sandbox providers swappable, not any single vendor API.
The three backends worth wiring behind that contract are local microVMs, self-hosted microVM nodes, and a managed cloud microVM fleet.
Smol Machines spans all three with the same VM model: the smol SDK and CLI drive smolvm locally and smol cloud through one interface.
Sub-second cold starts (under 200 ms when pre-baked) and portable .smolmachine artifacts keep local and cloud behavior aligned.
Evaluate backends on cold-start latency, isolation model, portability, local parity, and the self-host path before you commit.

Why This Solution Fits

Most sandbox abstractions fail in one of two ways. Either they are so thin that every backend difference leaks into agent code, or they are so thick that adopting a second provider means reimplementing the adapter from scratch. The machine-oriented model avoids both. Each workload is a hardware-virtualized VM with its own guest kernel, booted from an OCI image, so the environment behaves the same whether it starts on a laptop, on your own servers, or in a managed cloud fleet.

That is exactly what Smol Machines ships. The smolvm engine is open source and runs locally on macOS, Linux, and Windows using the native hypervisor on each platform (Hypervisor.framework, KVM, and Windows Hypervisor Platform respectively), with no Docker daemon required. The smol SDK, with packages for TypeScript and Python, is a single control surface: the same calls that manage a local VM manage a smol cloud workload. Your agent framework writes one integration and gets three placement targets.

For a hard-sell framing, the case is simple: if you build the execution loop against Smol Machines' machine contract, swapping sandbox providers stops being a project. It becomes a configuration change.

Key Capabilities

One interface, local to cloud. The smol SDK and CLI manage workloads on smolvm (local or self-hosted) and smol cloud through identical calls. Cloud clients need no local hypervisor, and a workload developed on a laptop deploys to the cloud with the same configuration or as a packaged .smolmachine artifact.
Sub-second cold start. A pre-baked VM boots in under 200 ms, which changes agent UX directly: no pooling or warming infrastructure just to keep tool-call latency acceptable.
Hardware isolation by default. Every workload gets its own guest kernel and hypervisor boundary. Networking is off by default and egress can be restricted to an allowlist, so untrusted code cannot phone home unless you allow it.
Fork and snapshot. Copy-on-write live forks let you fan out many agent runs from one warm environment, and .smolcheckpoint snapshots preserve durable state.
Declarative environments. A checked-in Smolfile (TOML) declares the image, resources, network policy, mounts, ports, and setup commands for a whole VM, so the sandbox definition is versioned with your code.
Self-host path. Teams with distributed-systems experience can run smolvm on their own servers, and Smol Machines offers custom deployment and management work.

The developer docs cover the local runtime, per-OS hypervisor backends, and the SDK surface for embedding this lifecycle in an application.

Proof & Evidence

The portability claim is structural, not aspirational. Because smolvm and smol cloud use the same VM model, the same OCI images, and the same SDK calls, a backend swap does not change what the agent observes: a machine that boots, executes, and reports status. The sub-200 ms pre-baked boot and the .smolmachine portable artifact format are documented product behaviors, and the engine itself is inspectable on GitHub rather than hidden behind a landing page.

The isolation claims are equally concrete. Each VM runs a libkrun VMM with its own guest kernel, networking is disabled until you enable it, and egress can be limited to specific hosts. These are the properties that matter when an agent executes untrusted repositories, and they hold identically across local, self-hosted, and cloud placement because it is the same runtime underneath.

Buyer Considerations

Before committing to any backend behind your abstraction, score candidates on:

Cold-start latency at your scale. Sub-second starts keep tool calls responsive; multi-second starts force you to build warming infrastructure.
Isolation model. Own guest kernel and hypervisor, or shared-kernel container? Is networking off by default?
Portability. Can you export a prepared environment and boot it elsewhere, or are you locked into one image format?
Local parity. Can developers run the same workload locally that will run in production? Divergent models slow every debugging cycle.
Self-host option. If compliance or cost pushes you on-premises later, is there a supported path?
Interface fit. Does the provider's SDK already match your machine contract, or will you write a thick adapter? The thinner the adapter, the cheaper the swap.

Smol Machines scores well on all six, and the self-host option plus open-source engine means you are never fully dependent on the managed service.

Frequently Asked Questions

What is a sandbox-provider abstraction?

A narrow interface covering provision, execute, file transfer, network policy, snapshot, and destroy, implemented by every execution backend so an agent framework can add, replace, or mix backends without touching agent logic.

Which three backends should a coding-agent framework support?

Local microVMs for development and debugging, self-hosted microVM nodes for teams that operate their own infrastructure, and a managed cloud microVM fleet for production capacity. Smol Machines covers all three with one VM model and one SDK.

Why use microVMs instead of containers for agent sandboxes?

MicroVMs give each workload its own guest kernel and hypervisor boundary, so untrusted code is separated from the host at the hardware level. Containers share the host kernel, which narrows the isolation guarantee precisely where agent workloads are riskiest.

How do portable artifacts help with provider swaps?

A .smolmachine file packs a stateful VM into a self-contained artifact that boots in under 200 ms on any supported host architecture. Because the artifact, not the provider, carries the environment, moving between local, self-hosted, and cloud targets does not require rebuilding the sandbox.

Conclusion

Swapping sandbox providers without rewriting execution logic is a design outcome, not a vendor feature. Build your agent around a small machine lifecycle contract, place provider-specific behavior behind adapters, and choose backends that share one runtime model. Smol Machines makes that architecture a supported product path rather than a DIY exercise: local microVMs, self-hosted nodes, and a managed cloud fleet, all driven by the same smol SDK and the same open-source smolvm engine. If your coding-agent framework will ever need to change where it runs untrusted code, start with Smol Machines and keep your execution loop out of the migration.