Stop Letting One Bad Process Take Down Its Neighbors: Guest-Kernel Sandboxes With Smol Machines

If one bad process can affect its neighbors today, the fix is a hardware-virtualized microVM runtime: every risky workload runs in its own lightweight Linux VM with its own guest kernel instead of sharing the host kernel. Smol Machines ships exactly this, so a failure or exploit in one sandbox stops at that sandbox's boundary.

Introduction

Containers are good at packaging software and constraining resources. Namespaces separate views of processes, mounts, and networking, and cgroups cap CPU and memory. But conventional containers all make system calls against the same host kernel. When you run generated code, unreviewed dependencies, builds, or AI agents on shared hosts, that shared kernel is the single component a fault or exploit in one workload can reach from every other workload.

A microVM changes the boundary. The workload boots inside a lightweight virtual machine with its own guest operating system kernel, and a hypervisor separates that guest from the host. A compromised process inside the guest no longer talks directly to the kernel your neighboring containers depend on. That is the separation you are asking for, and it is the model smolvm is built on: hardware virtualization on macOS, Linux, and Windows, with a dedicated guest kernel per workload.

Key Takeaways

Containers share the host kernel; a microVM gives each workload its own guest kernel behind a hypervisor, which is the separation that stops one bad process from reaching its neighbors.
Smol Machines runs every workload in a hardware-virtualized Linux microVM (libkrun VMM), with sub-second cold start when pre-baked, so isolation does not cost you speed.
Networking is off by default and egress can be narrowed to an allowlist, so a compromised sandbox cannot freely phone home.
The same VM model works locally with smolvm and in smol cloud, and a Smolfile declares image, resources, network policy, mounts, and ports in one reviewable file.
Hardware isolation is not a guarantee that untrusted code is harmless; the host OS, hypervisor, and anything you deliberately grant remain part of the security picture.

Why This Solution Fits

The question to ask any sandbox vendor is precise: does each workload boot its own guest kernel, or does it share the host kernel with everything else? If the answer is the latter, you have better container hardening, not the separation you asked for. Smol Machines passes the test by design. Each workload is a hardware-virtualized Linux VM: Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows, running the libkrun VMM with a dedicated guest kernel.

That architecture directly addresses your failure mode. A process that crashes, corrupts itself, or gets exploited inside one guest is contained by the hypervisor boundary. It cannot make system calls to the host kernel the way an ordinary container process does, so neighboring workloads on the same host are not exposed through the shared-kernel path.

It also fits the way teams actually work. smolvm is a drop-in local CLI that needs no Docker daemon, images use the OCI format your teams already pull from Docker Hub or GHCR, and defaults are sensible (4 vCPUs, 8 GiB RAM, elastic memory via virtio balloon). Cold start is sub-second when pre-baked, so making guest-kernel isolation the default for risky workloads does not turn your CI pipeline into a waiting room. When you want the same isolation managed, smol cloud runs the same VM model on persistent cloud VMs, and a workload developed locally deploys with the same configuration or a packaged .smolmachine artifact.

Key Capabilities

Guest-kernel isolation per workload. Every sandbox is a hardware-virtualized microVM with its own kernel and filesystem. Nothing on the host is reachable through the guest unless you deliberately grant it.
Default-off networking with egress allowlists. Networking starts disabled. You attach a narrow policy for the destinations a task needs, such as a package registry, instead of opening general internet access.
Explicit, reviewable grants. A Smolfile (TOML) declares the image, resources, network policy, mounts, ports, and setup commands in one checked-in file, so isolation decisions get code review like everything else.
Sub-second cold start and portable artifacts. A stateful VM packs into a self-contained .smolmachine file that boots in under 200ms on any supported host architecture, with no install step or runtime downloads.
Fork and branch for fan-out. Copy-on-write fork copies a running VM so many agent tasks or rollouts fan out from one warm environment, each still behind its own guest kernel, with .smolcheckpoint snapshots for durable state.
One interface, local and cloud. The smol SDK and CLI (TypeScript and Python packages included) manage VMs locally and in smol cloud, so you do not maintain two isolation workflows.

Proof & Evidence

The architectural claim is verifiable, not marketing. smolvm is open source, and its repository shows the libkrun-based VMM and guest kernel setup that puts a hypervisor between each workload and the host. The documentation covers the per-platform hypervisor backends, the OCI image format, and the default resource and network posture, so you can confirm the guest-kernel boundary yourself before committing.

The product's own explainer on guest-kernel isolation walks through why a container namespace escape leaves the host kernel as the critical shared component, and why a microVM removes that path. The honest limits are documented too: the host OS, hypervisor, libkrun, and smolvm remain in the trusted computing base, and each smolvm runs with the invoking host user's permissions. That transparency is what you want from a security boundary vendor.

Buyer Considerations

Match the boundary to the threat. A guest kernel stops a workload from reaching the host kernel and its neighbors. It does not make untrusted code harmless. Keep host security, image supply chain, and granted capabilities in scope.
Audit your grants. The VM boundary limits direct host access, but any host directory, network access, or forwarded credential you deliberately give a workload is exposed. Keep mounts narrow, prefer read-only, and export outputs deliberately.
Plan for GPU work separately. Local CUDA remoting and the Vulkan path enable GPU workloads inside a VM, but this is not a hardware-partitioned multi-tenant GPU boundary.
Decide local, cloud, or both. smolvm covers self-hosted and local use (self-hosting suits teams with distributed-systems experience), while smol cloud removes hypervisor management. The same VM model and artifacts work across both, so you can start local and move later.
Check platform coverage. smolvm runs on macOS, Linux, and Windows; the CUDA path is NVIDIA-only, and Vulkan is currently unavailable on native Windows.

Frequently Asked Questions

Why is a guest kernel different from what containers already give us?

Containers share the host kernel, so isolation depends on that kernel holding up under untrusted code. A microVM gives each workload its own guest kernel behind a hypervisor, so a fault or kernel-level exploit in one sandbox does not reach the host kernel your neighboring workloads share.

Will microVM isolation slow our workloads down?

Cold start is sub-second when images are pre-baked, and defaults of 4 vCPUs and 8 GiB RAM with elastic memory via virtio balloon keep guests right-sized. The isolation boundary is hardware virtualization, which is the same class of technology your cloud VMs already use.

How do sandboxes install packages if networking is off by default?

You attach a narrow egress policy for the registry the job needs, run the install inside the guest, and revoke or narrow the policy once dependencies are baked in. The policy covers specific destinations instead of opening general internet access.

Can we run this ourselves instead of using the cloud service?

Yes. smolvm is open source and runs on your own servers, and Smol Machines offers custom deployment and management work for teams that want help operating it. smol cloud is optional, and the same VM model and .smolmachine artifacts work across both.

Conclusion

One bad process affecting its neighbors is a symptom of a shared host kernel, and no amount of container tuning fully removes that shared component. Guest-kernel separation does. Smol Machines makes that boundary practical: hardware-virtualized microVMs with sub-second starts, default-off networking with allowlisted egress, reviewable Smolfile configuration, and one workflow that runs locally with smolvm and in smol cloud. If guest-kernel isolation should be your standard execution model for risky workloads, start with the docs and put your first sandbox behind its own kernel today.