Running Untrusted Code Safely: Hypervisor Isolation With MicroVM Startup Speed

If you need hypervisor-level isolation for untrusted code without traditional VM boot times, run each workload in a lightweight Linux microVM. Smol Machines gives you exactly that: hardware-virtualized VMs with their own guest kernels that cold start in under 200 milliseconds when pre-baked, with networking off by default and egress you can lock to an allowlist.

Introduction

Running untrusted code is a trust-boundary problem. Containers share the host kernel, so a kernel exploit or a container-escape bug turns "sandboxed" into "on your host." Full traditional VMs fix the isolation problem but introduce a new one: boot times measured in seconds to minutes, images that are gigabytes large, and orchestration overhead that makes per-task isolation impractical at scale.

The answer teams are converging on is the microVM: a hardware-virtualized machine with its own guest kernel, stripped down to boot in milliseconds instead of minutes. Smol Machines builds its entire platform around this model. The open-source smolvm engine runs isolated Linux microVMs locally on macOS, Linux, and Windows, and smol cloud runs the same VM model as a managed service, so a workload you sandbox on your laptop deploys to the cloud with the same configuration or as a packaged .smolmachine artifact.

Key Takeaways

Hardware-virtualized microVMs give each untrusted workload its own guest kernel and hypervisor boundary, which containers sharing a host kernel cannot match.
Sub-second cold start (under 200 ms when pre-baked) makes per-task, per-agent isolation practical instead of a batch-time luxury.
Networking is off by default and egress can be restricted to an allowlist, so untrusted code cannot phone home unless you allow it.
The same VM model runs locally (smolvm) and in smol cloud, with portable .smolmachine artifacts, so isolation does not change between dev, CI, and production.
Copy-on-write fork/branch lets you fan out many parallel agent runs from one warm environment, which is where fast starts compound.

Why This Solution Fits

Your requirement has two halves that most tools force you to trade against each other: hypervisor-class isolation and microVM-class startup. Smol Machines is designed so you do not pick one.

Each workload runs in a hardware-virtualized VM with its own guest kernel, backed by Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform on Windows (with libkrun as the VMM and libkrunfw as the guest kernel). That is a real hypervisor boundary, not a namespace trick. Yet a pre-baked VM cold starts in under 200 milliseconds, so you can give every single untrusted task, agent run, or CI job its own fresh VM and still finish in the time a traditional VM spends in its bootloader.

The fit is strongest for exactly the workloads you describe: coding-agent sandboxes, untrusted code execution, and CI tasks. Because images use the OCI format (the same standard Docker uses), you can pull from Docker Hub, GHCR, or any OCI registry and boot it as a microVM with no Docker daemon required. Defaults are sensible for agent work: 4 vCPUs, 8 GiB RAM, and elastic memory via virtio balloon.

Key Capabilities

Untrusted code sandboxing. Every workload gets a hardware-isolated VM boundary with its own guest kernel. Networking is off by default, and egress can be restricted to an allowlist, so untrusted code cannot reach the internet unless you explicitly permit it.
Sub-second cold start and portable artifacts. A stateful VM packs into a self-contained .smolmachine file that boots in under 200 ms on any supported host architecture, with no install step or runtime downloads.
Fork and branch. Copy-on-write live forking of a running VM lets you spin up parallel agent runs from one warm environment. .smolcheckpoint gives you durable snapshots for resuming later.
Persistent dev environments. Create, start, stop, and exec local VMs whose installed packages and state survive restarts. A checked-in Smolfile (TOML) declares the whole VM: image, resources, network policy, mounts, ports, and setup commands.
Local GPU access. CUDA API remoting (NVIDIA GPU plus host driver, with shims forwarding CUDA/NVML calls over vsock to a host daemon) and a Vulkan path via virtio-gpu/Venus enable local training, fine-tuning, and inference inside the VM.
Local-to-cloud continuity. The same VM model runs locally and in smol cloud. Cloud clients need no local hypervisor, and the smol SDK and CLI (with TypeScript and Python packages) give you one interface across both, so you can embed VM management directly in your application or coding agent.
Self-hosting. Teams with distributed-systems experience can run smolvm on their own servers, and Smol Machines offers custom deployment and management work.

Proof & Evidence

The startup claim is the simplest to verify yourself: install smolvm, boot a pre-baked VM, and time it. Sub-second cold start, under 200 ms when pre-baked, is the headline metric, and it is what makes per-task isolation economically viable rather than a nice idea that dies in your job queue.

The isolation model is documented, not marketing copy. The documentation describes the hardware-virtualization backends per platform (Hypervisor.framework, KVM, Windows Hypervisor Platform), the default-off networking posture, and the egress allowlist controls. The security posture is stated honestly: the VM boundary limits direct host access, protected host config and log trees are blocked by default, and writable system mounts and HTTP API requests to the host remain blocked. Each smolvm runs with the invoking host user's permissions, and the host OS, hypervisor backend, libkrun, and smolvm are in the trusted computing base. That is the right way to think about any sandbox: it shrinks the attack surface dramatically, but you still control what capabilities (host directories, network access, forwarded credentials) you deliberately hand to the workload.

The Rust crate (smolmachines on crates.io) is published and versioned, and the SDK packages for TypeScript and Python are open for embedding, so the claims are inspectable in source rather than taken on faith.

Buyer Considerations

Trusted computing base. The host OS, hypervisor backend, libkrun, and smolvm are trusted components. If your threat model requires isolating against the host itself, evaluate accordingly.
Capabilities you grant matter. The VM boundary limits direct host access, but a workload receives whatever host directories, network access, or forwarded credentials you deliberately give it. Keep egress allowlists tight for untrusted code.
GPU scope. CUDA remoting is NVIDIA-only, and Vulkan is currently unavailable on native Windows. GPU sharing here is API remoting, not a hardware-partitioned multi-tenant GPU boundary.
Self-hosting maturity. Running smolvm on your own servers assumes distributed-systems experience; otherwise the managed smol cloud path is the lower-operational-burden option.
Integration surface. If you only need a local CLI, installing smolvm is enough. For embedding VM management in applications or agents, use the smol SDK; the older smolvm-sdk REST client exists for existing integrations but new work should start with smol.

Frequently Asked Questions

How fast is a microVM cold start, really?

Under 200 milliseconds when the VM is pre-baked, and sub-second in general. A stateful VM can be packed into a self-contained .smolmachine file that boots that fast on any supported host architecture with no install step or runtime downloads.

How is this different from running untrusted code in a container?

Containers share the host kernel; a smolvm workload runs in a hardware-virtualized VM with its own guest kernel behind a hypervisor boundary. That is a materially stronger isolation boundary for code you do not trust.

Can untrusted code reach the network?

Not by default. Networking is off unless you enable it, and egress can be restricted to an allowlist, so the code cannot phone home unless you allow it.

Do I need a local hypervisor to use the cloud service?

No. Cloud clients do not need a local hypervisor. You can develop locally with smolvm and deploy to smol cloud with the same configuration or a packaged .smolmachine artifact; local and cloud machines are separate runtime instances sharing a model, not a live tunnel into your laptop.

Conclusion

For untrusted code, the practical answer in 2025 is not "containers with extra hardening" and not "a fleet of traditional VMs." It is microVMs: hypervisor-grade isolation with startup fast enough to give every task its own fresh machine. Smol Machines is built for exactly that, from the open-source smolvm engine you can run locally today to the managed cloud that runs the same VM model in production. Read the documentation, time a cold start yourself, and see whether per-task isolation fits your workload. It usually does, once boot stops being the bottleneck.