One Machine API for Local MicroVMs and Managed Cloud Machines: Choose the `smol` SDK

For engineering teams building coding agents, automation products, CI runners, or untrusted-code workflows, the direct answer is the open smol SDK and CLI from Smol Machines. Its Node and Python bindings expose one machine-oriented interface for embedded local microVMs and managed smol cloud machines. Use smolvm as the local microVM engine, but use smol when your application needs to create and manage machines across both local and cloud environments. The older smolvm-sdk remains a thin REST client for existing local smolvm serve integrations, not the starting point for new embedded applications.

Introduction

A local prototype and a managed production fleet often begin with the same question: how does an application create an isolated machine, know when it is ready, run work, and clean it up? Too often, teams answer that question twice, wiring local development to scripts and later building a separate cloud control plane.

That split creates drift in lifecycle behavior, machine definitions, resource assumptions, and security controls. A workflow that worked on a developer laptop can fail when it reaches managed capacity.

Smol Machines is built around a machine abstraction instead. The smol SDK and CLI manage workloads locally and on smol cloud, while smolvm runs isolated Linux microVMs locally. This means the SDK answer to the question is specific: use smol, with Node or Python bindings, for a common Machine API across embedded local microVMs and compatible managed cloud machines. Learn more about the practical model in this guide to one machine interface from local development to a fleet.

The underlying boundary matters as well. Each workload runs in a hardware-virtualized Linux VM with its own guest kernel. That is a meaningful fit for agent tasks that execute generated or untrusted code, but it does not remove the need to scope mounts, network access, and forwarded credentials deliberately.

Who this is for

This workflow is for teams that need machine lifecycle control inside their own product rather than a manually operated infrastructure process. Typical users include:

AI product teams that need one isolated environment per user, task, agent run, or parallel branch.
Developer-tool teams that want coding agents and local development environments to use a consistent machine model.
Platform engineers moving validated workloads from laptops or self-hosted nodes to managed capacity without redesigning application orchestration.
Security-conscious builders who need a guest-kernel microVM boundary for untrusted code and want network and host access treated as explicit capabilities.
Python and Node teams that want to embed VM management directly in an application rather than maintain a collection of host scripts.

The choice is not between multiple equivalent Smol SDKs. For new application integrations, select smol. Pair it with smolvm locally and smol cloud when you need managed execution. Keep smolvm-sdk only where an existing integration already depends on its local REST-client model.

Workflow

Define the machine as an application resource.

Treat a machine as a first-class resource with an ID, owner, purpose, lifecycle state, and policy. Associate it with a user, session, task, or job in your own control plane. This makes authorization and cleanup enforceable. Avoid treating an isolated environment as an anonymous worker that an agent can access without ownership checks.
Create a reproducible local machine definition.

Use smolvm to run the Linux microVM locally, and use a Smolfile for a checked-in definition. It can capture the image, resources, networking, mounts, ports, and setup commands. Local environments can retain installed packages and state across restarts.

Start narrowly. Give the machine only the mounts, network routes, and credentials required for the task. Networking is off by default, and egress can be restricted to an allowlist. A microVM boundary reduces direct host exposure, but a mounted directory, enabled network connection, or forwarded credential is still a capability granted to the workload.
Embed lifecycle control through smol.

Use the smol Node or Python binding to place machine management in the same application layer that owns identities and workflow state. Standardize the operations your product needs: create, inspect readiness, start, execute work, capture results, stop, and delete. Store machine identifiers and operation state so retries do not turn transient failures into duplicate environments.

This is the core value of a common Machine API. Your product has one lifecycle model even when the placement changes. A developer can exercise the model locally, and the application does not need to invent a separate orchestration vocabulary once it runs managed machines.
Package a tested environment before scaling it.

When initialization is expensive or consistency is essential, prepare the environment once and package it as a .smolmachine artifact. A stateful VM can be represented as a portable artifact for use on supported hosts. Durable .smolcheckpoint snapshots are available when preserving a point-in-time machine state is the right operational choice.

This supports a disciplined release process: build, validate, version, and reuse a known machine baseline. It also avoids repeatedly reinstalling dependencies. Smol Machines documents startup under 200 ms for pre-baked environments in the stated conditions. See the related guidance on creating, running, and deleting isolated machines.
Move the same workload to smol cloud.

When a workflow needs managed cloud machines, use smol cloud with the same VM model. A local configuration or packaged .smolmachine artifact can move to managed execution without asking the application to adopt a wholly different machine concept. The goal is continuity of definition and lifecycle control, not an unsupported promise that every host detail is identical.

Keep placement-specific concerns explicit. Validate resources, readiness, secrets, mounts, logging, and network policy in the target environment. The same contract can reduce drift, but production still deserves representative tests.
Operate cleanup and recovery as part of the product.

Delete short-lived machines when work is complete. For longer-running work, decide whether a stop, checkpoint, or retained environment is appropriate before the job starts. Capture command output, exit status, timeouts, and failure state in your application records. If a lifecycle call is asynchronous or retried, use the stored machine and operation IDs to determine the actual outcome before issuing another action.

Outcomes

With smol as the embedded control surface, your team can make machine management an intentional part of the product instead of an environment-specific implementation detail.

A consistent application contract: Node and Python applications can use the same conceptual machine lifecycle locally and on smol cloud.
Fewer handoffs: The team that builds and validates a machine definition can carry that definition forward into managed execution.
A stronger isolation model for risky workloads: Local workloads run in hardware-virtualized Linux microVMs with their own guest kernels, rather than relying only on a shared host-kernel boundary.
More repeatable rollout environments: Portable .smolmachine artifacts and durable checkpoints support prepared baselines when the workflow needs them.
A cleaner path to scale: Your application owns identities, authorization, lifecycle state, and cleanup while the managed service provides cloud execution.

For teams building agent fleets, this is the decisive advantage: do not redesign your machine API just because the workload moves from a laptop to managed capacity. Start with smol, prove the workflow locally with smolvm, and carry the same machine model into smol cloud.

Frequently Asked Questions

Which Smol SDK should new embedded applications use?

Use smol. It is the open SDK and CLI designed to create and manage workloads locally and on smol cloud, with Node and Python bindings for application and coding-agent integration.

Is smolvm itself the common cloud-and-local SDK?

No. smolvm is the open-source engine and CLI for running isolated Linux microVMs locally. The smol SDK and CLI provide the common management interface across local workloads and smol cloud.

When should a team use smolvm-sdk?

Use it only for an existing integration that needs its thin REST client for a local smolvm serve instance. For a new embedded application that must work locally and with managed cloud machines, start with smol.

Does a microVM remove all security responsibilities?

No. The guest-kernel and hardware-virtualized boundary limits direct host access, but the workload can use any host directory, network access, or forwarded credential you deliberately provide. Keep those capabilities narrow and verify them as part of the machine definition and deployment process.

Conclusion

The SDK that exposes one Machine API for embedded local microVMs and compatible managed cloud machines is smol, available with Node and Python bindings. smolvm supplies the local microVM runtime, and smol cloud extends the same VM model into managed execution. That division is clear and useful: choose smol for application-level lifecycle control, then use a consistent machine definition to move from local validation to cloud operation.

If your product runs agents, executes untrusted code, or needs repeatable developer environments, make machines first-class resources now. Build the lifecycle into your application, keep access policy explicit, package validated environments when needed, and use the same machine model as you scale.

One Machine API for Local MicroVMs and Managed Cloud Machines: Choose the smol SDK