SmolVM: Portable VMs Boot in 200ms, Solve “Works on My Machine”

The “works on my machine” problem has plagued developers since software distribution began. Containers promised to fix this by packaging dependencies, but they share the host kernel—which means environment drift still happens, and security isolation is weaker than most developers realize. SmolVM, a new CLI tool from Y Combinator-backed Smol Machines, takes a different approach: ship the entire virtual machine as a portable single-file artifact that boots in under 200 milliseconds. It’s trending on Hacker News today for good reason.

Furthermore, SmolVM provides hardware-level isolation similar to AWS Firecracker, but with zero dependencies and a developer-friendly interface. No Docker daemon, no complex setup, just portable .smolmachine files that run anywhere. For developers dealing with untrusted code—especially AI-generated code in 2026—this combination of speed and security hits a sweet spot that containers can’t match.

Hardware Isolation That Boots in 200 Milliseconds

SmolVM achieves subsecond boot times using libkrun, a library-based virtual machine monitor from Red Hat. Unlike traditional VMs that take 45+ seconds to start, SmolVM’s cold start clocks in at under 200 milliseconds. That’s faster than most container runtimes and 225 times faster than spinning up a QEMU VM.

Moreover, the speed comes from a custom kernel called libkrunfw that’s optimized for rapid boot, plus tight integration with Hypervisor.framework on macOS and KVM on Linux. But here’s what matters more than the milliseconds: each SmolVM gets its own dedicated Linux kernel. That’s true hardware isolation, not the namespace-based sharing that containers rely on.

If you’re running untrusted code in containers, you’re one kernel exploit away from total compromise. Every container on that host shares the same kernel—all 40 million lines of C. A vulnerability in one container’s workload can affect every other container. In contrast, with SmolVM, the security boundary is hardware virtualization enforced by the CPU itself. A kernel exploit in one VM stays trapped in that VM’s hardware boundary.

AI Agent Sandboxing: Why 2026 is the MicroVM Year

The primary use case driving SmolVM adoption is sandboxing AI-generated code. Research shows sandboxed agents reduce security incidents by 90% compared to unrestricted host access, and every major cloud provider reached the same conclusion: VMs, not containers, for untrusted AI workloads.

AWS built Firecracker for Lambda. Google built gVisor for Search and Gmail. Azure uses Hyper-V for ephemeral agent sandboxes. They all chose their strongest isolation primitive and pointed it at AI. The pattern is clear: when code writes itself at runtime, kernel-level isolation becomes non-negotiable.

With 42% of GitHub commits in 2026 coming from AI-assisted code generation, the security risk of executing untrusted code has exploded. SmolVM gives developers the same isolation guarantees that cloud providers use, packaged in a tool simple enough for local development. Network isolation is enabled by default (you must opt in with the –net flag), and you can restrict egress to specific allowed hosts. No firewall rules, no iptables complexity—just a –allow-host flag.

Portable .smolmachine Files Eliminate Dependencies

Docker solved some portability problems but introduced others. You need a daemon running. You need to pull images from a registry. You need to hope the user has Docker installed and configured. SmolVM’s .smolmachine format eliminates all of that.

Package your entire environment—OS, dependencies, configurations, code—into a single file that runs on any matching architecture with zero installation. Download a .smolmachine file and execute it. Boot time: under 200 milliseconds. Dependencies required: none. It’s the “ship the machine” philosophy taken literally.

This solves “works on my machine” definitively. There are no environment differences when you ship the entire machine. Additionally, it addresses Docker Desktop licensing concerns on macOS—SmolVM uses native Hypervisor.framework with an Apache-2.0 license. For CLI tool authors tired of debugging users’ Docker setups, .smolmachine files are a breath of fresh air.

When SmolVM Makes Sense (and When It Doesn’t)

SmolVM sits between containers and infrastructure VMs. Containers are fast but share the kernel. Traditional VMs offer strong isolation but boot slowly and require complex management. SmolVM bridges the gap: hardware isolation with developer-friendly speed.

Choose SmolVM when you need hardware isolation without infrastructure complexity. Running untrusted or AI-generated code? SmolVM or Firecracker (hardware isolation required). Trusted application with existing Docker images? Stick with Docker (ecosystem advantage). Need portable artifacts that run with zero dependencies? SmolVM’s .smolmachine format. Building serverless infrastructure at AWS scale? Firecracker (API-first, infrastructure-focused). Developing on macOS without Docker Desktop licensing headaches? SmolVM (native Hypervisor.framework).

The community is wrong when they treat containers as sandboxes. Containers aren’t sandboxes—they’re process isolation, not security isolation. If your threat model includes untrusted code execution, containers don’t cut it. SmolVM fills the “developer needs strong isolation without becoming a platform engineer” niche.

Getting Started: Installation and Basic Usage

SmolVM installs via a single curl command and provides simple CLI commands for ephemeral runs, persistent machines, and portable artifact creation. The tool uses standard Linux distro images like alpine, ubuntu, and python:3.12.

Installation:

curl -sSL https://smolmachines.com/install.sh | bash

Ephemeral execution with network enabled:

smolvm machine run --net -it --image python:3.12 -- /bin/bash

Sandboxed execution with network allowlist (the security-first approach):

smolvm machine run --net --image alpine \
  --allow-host github.com \
  -- git clone https://github.com/user/repo

For persistent development environments, create a named machine that survives restarts:

smolvm machine create --net --image ubuntu:22.04 mydev
smolvm machine start --name mydev

SmolVM also supports declarative Smolfile configuration similar to Dockerfiles. Define your environment in TOML format for version control and team sharing:

image = "python:3.12-alpine"
net = true

[network]
allow_hosts = ["api.stripe.com"]

[dev]
init = ["pip install -r requirements.txt"]
volumes = ["./src:/app"]

The low friction to experiment is intentional. You can try SmolVM in two minutes without complex setup, making it practical for real workflows rather than just a research project.

Limitations and Trade-offs

SmolVM is v0.5.18—pre-1.0, actively developed, but young. Network supports TCP and UDP only (no ping or ICMP). Volume mounts accept directories but not individual files. On macOS, distributing .smolmachine binaries requires code signing. And .smolmachine files are architecture-locked: arm64 won’t run on x86_64.

Documentation is sparse compared to Docker’s extensive ecosystem. The community is small (825 GitHub stars). Some rough edges remain. However, for AI agent sandboxing and CI/CD isolation—use cases where strong isolation outweighs ecosystem maturity—SmolVM is production-ready.

Set realistic expectations: this isn’t a Docker replacement for all workloads. It’s a specialized tool for scenarios where hardware isolation justifies the trade-offs. The tool is improving rapidly, but if you need a massive image library or extensive tooling support, Docker still wins.

Key Takeaways

SmolVM makes sense when containers aren’t secure enough and traditional VMs are too slow. The subsecond boot times make hardware isolation practical for ephemeral workloads. The .smolmachine portable format solves distribution headaches. And the security model—kernel per VM, network isolation by default—matches what cloud providers use for untrusted code.

The industry trend toward microVMs for isolation is accelerating, driven by AI-generated code security needs. SmolVM positions itself as the developer-friendly option in this space: simpler than Firecracker, stronger than containers, faster than traditional VMs. For developers dealing with untrusted code, portable executables, or isolated development environments, it’s worth evaluating.

Not a revolution, but a solid tool that fills an important niche. Sometimes that’s exactly what you need.