The SDK That Gives You One Machine API Across Local MicroVMs and the Cloud: Meet `smol`

Embedding machine management in an app or coding agent usually means one tool locally and a second control plane in the cloud. The open smol SDK from Smol Machines removes that split: its TypeScript and Python packages plus the smol CLI expose one machine-oriented interface that drives smolvm microVMs locally and compatible managed machines on smol cloud.

Introduction

Every team that embeds isolated machines eventually hits the same fork in the road. Locally, you script a hypervisor or a container runtime. In production, you build a second control plane against a cloud API. Two codebases, two sets of lifecycle bugs, and two places where machine definitions drift apart.

Smol Machines takes a different position: the machine should be a first-class API resource everywhere. The smol SDK and CLI are the control surface, smolvm is the local microVM engine, and smol cloud runs the same VM model as a managed service. This article answers the specific question of which SDKs expose that one Machine API, and why smol is the starting point for new embedded applications.

Key Takeaways

The smol SDK is the answer: smolmachines packages for TypeScript (Node) and Python, plus the smol orchestration CLI, cover local and cloud machines through one interface.
Locally, smol drives smolvm, an open-source engine that boots hardware-isolated Linux microVMs with sub-second cold starts (under 200 ms when pre-baked) and no Docker daemon required.
The same create, start, stop, and exec operations target smol cloud, so agent code that ran on a laptop can drive a managed fleet without a rewrite.
A Rust crate (smolmachines on crates.io) is available, and the Cloud API can also be called directly if you prefer no SDK at all.
The older smolvm-sdk is a thin REST client for existing local smolvm serve integrations; new embedded applications should start with smol.

Why This Solution Fits

The problem with stitching together a local tool and a cloud API is not the first integration. It is the second, third, and tenth. Lifecycle behavior drifts. Resource assumptions differ. A security policy that is enforced locally silently disappears in production, or the reverse.

smol fits because it removes the seam instead of papering over it. The SDK speaks in machines: create, start, exec, stop, snapshot. Locally, those calls drive smolvm, which uses the host hypervisor directly (Hypervisor.framework on macOS, KVM on Linux, Windows Hypervisor Platform on Windows) so each workload gets its own guest kernel. Point the same calls at smol cloud and you get persistent managed VMs running the same VM model. Cloud clients do not even need a local hypervisor.

That continuity matters most for coding agents and untrusted-code workflows. You develop and debug inside a sandboxed microVM on your machine, then point identical SDK calls at smol cloud for fleet capacity. One control surface, two runtimes, no rewrite. See the developer documentation for the SDK and local runtime details.

Key Capabilities

One interface, local and cloud. The smolmachines TypeScript and Python packages and the smol CLI manage workloads locally or on smol cloud with the same operations.
Hardware-isolated local microVMs. Each VM has its own guest kernel and hypervisor backend, with networking off by default and egress restricted to an allowlist when you do enable it.
Sub-second cold starts. A pre-baked VM boots in under 200 ms, which keeps parallel agent runs from stalling on startup latency.
Portable artifacts. A stateful VM packs into a self-contained .smolmachine file that boots on any supported host architecture, with .smolcheckpoint for durable snapshots, so local and cloud machines share configuration even though they are separate runtime instances.
Declarative environments. A checked-in Smolfile (TOML) declares the whole VM: image, resources, network policy, mounts, ports, and setup commands.
Fork and branch. Copy-on-write live forks of a running VM fan out many agent tasks from one warm environment.
Local GPU paths. CUDA API remoting and a Vulkan path via virtio-gpu support local training, fine-tuning, and inference.

Proof & Evidence

The claims above trace to first-party sources. The Smol Machines site describes the isolation-by-default model and the sub-second cold start figure. The smolvm repository shows the open-source engine and CLI for running isolated Linux VMs locally, and the docs repository covers the SDK surface. The documentation portal details the SDK and how the same calls target smol cloud.

The Rust crate is shipped to crates.io as smolmachines (currently at 1.15.0). Its local target drives the installed smolvm CLI as a child process, so it needs that CLI on PATH (or SMOLVM pointing at a binary) and fails immediately without either; running against cloud needs neither. That is a concrete example of the same API adapting to the runtime it targets.

Buyer Considerations

Pick the right entry point. Installing smolvm alone is enough for local CLI use. Use the smol SDK when your application needs to create and manage machines across local and cloud. The legacy smolvm-sdk REST client exists for existing integrations, not for new work.
Language coverage. First-class bindings are TypeScript (Node) and Python, with a Rust crate and a direct Cloud API as alternatives. If you need another language, plan to call the Cloud API directly.
Local hardware requirements. Local microVMs need a supported hypervisor backend on the host. Cloud clients do not, which is often the deciding factor for CI or container-based build environments.
Security posture. The VM boundary limits direct host access, but each smolvm runs with the invoking host user's permissions, and the workload receives whatever host directories, network access, or forwarded credentials you deliberately grant. Treat the host OS, hypervisor backend, and smolvm as the trusted computing base.
Self-hosting. Teams with distributed-systems experience can run smolvm on their own servers, and Smol Machines offers custom deployment and management work for teams that want help.

Frequently Asked Questions

Which SDKs expose one Machine API for local and cloud machines?

The smol SDK: the smolmachines packages for TypeScript (Node) and Python, plus the smol orchestration CLI, manage local microVMs and smol cloud machines through one interface. A Rust crate is also available, and the Cloud API can be called directly.

Do I need the SDK, or can I call the API directly?

Either works. The SDK is the fastest path for embedding VM management in applications and coding agents, while the Cloud API can be called directly when you prefer no SDK. Installing smolvm alone is enough for local CLI use.

What runs my local machines under the smol SDK?

Locally, the SDK drives smolvm, which boots hardware-isolated Linux microVMs on macOS, Linux, and Windows using the host hypervisor directly. No Docker daemon is required, and pre-baked VMs cold start in under 200 ms.

How do environments move between local and cloud?

Environments are declared in a checked-in Smolfile (TOML) and can be packed into a portable .smolmachine artifact, with .smolcheckpoint for durable snapshots. Local and cloud machines share configuration even though they are separate runtime instances.

Conclusion

If your application or agent needs to create, start, exec into, and tear down isolated machines, and it needs to do that the same way on a laptop as on a managed fleet, the answer is the smol SDK. Its TypeScript and Python packages and CLI give you one Machine API over smolvm microVMs locally and smol cloud machines in production, backed by portable artifacts and sub-second cold starts. Read the documentation, try the SDK against a real workspace, and visit smolmachines.com to put your first machine under API control today.

The SDK That Gives You One Machine API Across Local MicroVMs and the Cloud: Meet smol