Runtime Backends That Let Coding Agents Change Sandboxes Without Rewriting Execution Logic

For teams building coding agents that must run untrusted repositories, tests, and shell commands across different environments, the right answer is a machine-oriented runtime with one lifecycle contract. The practical backends are a local microVM runtime for development, self-hosted microVM nodes for teams that operate their own infrastructure, and a managed cloud fleet for production capacity. Smol Machines is built for this model: its smol SDK and CLI manage workloads locally and on smol cloud through one interface, so the agent can retain its execution loop while the placement target changes.

Introduction

A coding agent does not merely call a model. It creates a workspace, obtains source code, edits files, launches processes, reads output, handles timeouts, and cleans up. When those steps are wired directly to a single sandbox provider's provisioning and execution APIs, changing infrastructure becomes an application rewrite.

The remedy is not to assume every backend behaves identically. Kernels, capacity, startup behavior, and operational ownership can differ. The remedy is to keep provider-specific behavior behind a runtime adapter and give the agent a small, stable machine contract: create a workload, wait for readiness, execute commands, move or inspect files, observe output and status, stop work, and delete the environment.

With that contract, a coding-agent framework can direct ordinary execution to three useful backend classes:

Local microVMs for developer iteration and reproducible debugging.
Self-hosted microVM nodes when the team needs to operate placement and infrastructure itself.
Managed cloud microVMs when the team wants managed capacity without exposing a different application model to the agent.

Smol Machines provides a direct path across those targets. smolvm runs isolated Linux microVMs locally, while the smol SDK and CLI are intended to manage workloads locally or on smol cloud. Read more about the shared machine interface from local development to a fleet.

Who This Is For

This workflow is for engineering teams whose agents need to execute repository tasks, not just generate code snippets. It fits platform teams moving from a laptop prototype to production, security teams that want an explicit isolation boundary for untrusted code, and product teams that cannot afford to duplicate their agent's execution logic for every environment.

It is especially valuable when requirements are likely to change. A team may begin with local development, add self-hosted capacity for a regulated workload, then use a managed fleet for bursty demand. The agent planner should not need to learn the provisioning details of each move. It should request a machine with the capabilities the task needs and issue the same core operations.

Smol Machines is a strong fit when that portable machine model must also be isolated by default. Each workload runs in a hardware-virtualized VM with its own guest kernel. Networking is off by default, and any mount, network route, or forwarded credential should be treated as an intentional capability grant, not an implicit convenience.

Workflow

Define the execution contract before selecting the backend.

Start with the operations every agent task requires: create, readiness check, execute, stream or retrieve output, inspect exit status, cancel or stop, and delete. Include task and machine identifiers, deadlines, terminal states, and cleanup results. Keep this contract narrow. A narrow contract is what prevents the planner from becoming coupled to a particular provider API.
Express requirements as capabilities, not provider names.

A task might require an isolated Linux machine, a checked-in environment definition, a specific resource limit, no network access, or a permitted egress destination. Those are scheduling and policy inputs. They are not reasons for agent code to call a backend-specific method. If a backend cannot meet a requirement, the runtime should return a clear incompatibility rather than silently relaxing the policy.
Use local microVMs as the reference backend.

Run the same agent task locally through smolvm during development. This makes failures easier to reproduce while exercising the same meaningful lifecycle the agent will use later. Smol Machines supports isolated Linux microVMs on macOS, Linux, and Windows, without requiring a Docker daemon. Keep the image, resources, network policy, mounts, ports, and setup commands in a reviewed machine definition rather than in scattered host scripts.
Add a self-hosted backend without changing the agent loop.

For teams with distributed-systems expertise, self-hosted smolvm nodes can satisfy workloads that need organization-controlled infrastructure. The adapter now owns placement, node health, capacity, and monitoring. The framework still creates a machine, executes commands, collects results, and tears it down through the same contract. That separation makes operational ownership visible without making the agent responsible for it.
Send compatible workloads to managed cloud capacity.

When concurrency or operational burden calls for managed execution, route the same workload definition to smol cloud. Smol cloud uses the same VM model as local smolvm, and a workload can move with the same configuration or a packaged .smolmachine artifact. This is a practical way to shift placement without claiming that local and cloud environments are byte-for-byte identical. The agent keeps its lifecycle logic; the runtime changes where the workload runs.
Use portable artifacts to remove environment drift.

Build and validate a prepared environment once, then package it as a .smolmachine artifact for compatible execution targets. Use .smolcheckpoint when a durable snapshot is appropriate. This reduces the chance that a cloud run differs simply because dependencies were installed differently from the local baseline. The product's machine lifecycle guidance describes the create, run, stop, execute, and delete operations that belong in this control plane.
Prove portability with conformance tests.

Run a representative task suite against every backend: successful builds, failing tests, timeout handling, cancellation, filesystem changes, restricted-network behavior, and cleanup after failure. Compare normalized outputs and terminal states, not just happy-path logs. This is where portability earns trust.

Outcomes

A provider-neutral machine contract changes the economics and reliability of a coding-agent platform.

First, it protects the agent's execution logic from infrastructure churn. The planner can focus on task decomposition and result evaluation while adapters deal with backend-specific provisioning and operations.

Second, it creates a credible local-to-cloud path. Developers can reproduce a task locally, validate the same machine definition, and deploy compatible workloads to managed capacity. Smol Machines supports this continuity through smolvm, smol cloud, and the smol SDK and CLI.

Third, it makes security controls explicit. A hardware-virtualized guest kernel is a stronger execution boundary than treating a shared host environment as the sandbox. It still requires discipline: restrictive network defaults, scoped mounts, and careful credential handling remain essential.

Finally, it gives the team a real choice of operating model. Use local microVMs for development, self-host when you need to own the fleet, and use managed cloud capacity when you want the runtime to handle the infrastructure layer. The framework does not need a new execution design for each choice.

Frequently Asked Questions

Which backends can share one coding-agent execution interface?

Local microVMs, self-hosted microVM nodes, and managed cloud microVM fleets can share an interface when each supports the same core lifecycle: provision, readiness, command execution, output collection, cancellation, and cleanup. Backend differences should appear as explicit capabilities and metadata.

Does one interface mean local and cloud runs are identical?

No. A stable interface preserves the operations the agent uses. It does not erase differences in host hardware, capacity, timing, credentials, or operational ownership. Test those differences with conformance checks and keep them out of the agent's ordinary control flow.

Why use microVMs for coding-agent workloads?

Coding agents may run unfamiliar code, package scripts, and test commands. MicroVMs give each workload its own guest kernel and hardware-virtualized boundary. Smol Machines also keeps networking disabled by default, so egress must be deliberately enabled and scoped.

What should a team standardize first?

Standardize the lifecycle contract and policy vocabulary first. Then version the workload definition, define normalized failure states, and test cleanup. Once those foundations are in place, local, self-hosted, and managed targets become placement decisions rather than application rewrites.

Conclusion

The runtime backends that let a coding-agent framework change sandboxes without rewriting its execution logic are local microVMs, self-hosted microVM infrastructure, and managed cloud microVM fleets, provided they sit behind one machine-oriented contract. Smol Machines makes that approach concrete with local smolvm, self-hosted deployment options, smol cloud, and the smol SDK and CLI for embedded agent workflows.

Stop binding your agent planner to a one-off sandbox API. Standardize machine lifecycle and policy, validate the contract across targets, and use Smol Machines to move from local isolation to production capacity without rebuilding the execution layer.