The Race to Replace Docker—With Virtual Machines That Boot Like Lightning
There's a peculiar irony in the latest pitch from a Y Combinator-backed startup called Smol Machines. After years of developers abandoning virtual machines for the lean efficiency of containers, here comes a tool that wants to bring VMs back—by making them faster than containers ever were.
The company, part of YC's Spring 2026 cohort, released a command-line tool that spins up full Linux virtual machines in under 200 milliseconds. Not containers sharing a kernel. Actual VMs, each with its own kernel, its own network stack, its own isolation guarantees. And the entire thing can be packaged into a single executable that runs anywhere, no daemon necessary.
When the project landed on Hacker News around April 17, 2026, it sparked the kind of debate that suggests developers see something here—even if they're not quite sure what. Over 450 upvotes, nearly 140 comments, discussions spilling into subreddits from r/virtualization to the Claude AI forums. The question threading through the chatter: could this actually replace Docker for certain workflows?
What They Built
The core product is smolvm, written in Rust, designed for macOS and Linux. Unlike Docker's shared-kernel architecture, every smolvm instance runs its own Linux kernel—Apple's Hypervisor.framework on Mac, KVM on Linux. Under the hood sits libkrun, an embeddable virtual machine monitor handling the low-level mechanics.
The headline feature is speed. Specifically, sub-200-millisecond boot times for what the company calls "packed executables"—VMs bundled into standalone .smolmachine files. Run smolvm pack create --image python:3.12-alpine -o ./python312 and you get a single binary. Execute it and a Python environment boots faster than most people can perceive the delay.
No daemon consuming background resources. No runtime dependencies to download. Just a self-contained executable that happens to contain an entire virtual machine.
The tool pulls standard OCI images from Docker Hub, GitHub Container Registry, or any compatible source. You can grab Alpine Linux or a specialized machine learning runtime without installing Docker at all. The VMM links directly into the binary, which means when you're not using it, it's not running.
Locked Down by Design
Network access defaults to off. Want internet? Add --net. Need granular control? The system supports allowlisting—--allow-host registry.npmjs.org lets your VM reach npm but blocks everything else. TCP and UDP work. ICMP doesn't, a limitation the documentation acknowledges without apology.
SSH agent forwarding offers a clever security feature: your VM can clone private repositories without ever seeing your actual private keys. The host's SSH_AUTH_SOCK gets forwarded across the boundary, but the keys themselves stay put.
For teams building AI coding agents or running untrusted code, this starts to look less like a curiosity and more like a tool. The architecture differs from AWS Lambda's Firecracker, which also delivers fast microVM boot times—around 125 milliseconds by Amazon's spec. But Firecracker powers production serverless infrastructure. Smol Machines targets developer laptops and portable artifacts. Different problems, different constraints.
Where It Might Fit
The documentation and early community adoption point to a few patterns. Sandboxing untrusted code is obvious—run a command in an ephemeral VM that evaporates afterward. Some developers are using it for persistent development environments: create a VM, install packages, stop it, restart it days later with everything intact.
One thread in the Claude AI subreddit positioned smolvm as "a better default sandbox for coding agents." AI systems that generate and execute code need isolation. Containers offer process-level separation. VMs add kernel-level boundaries. Whether that extra layer matters depends on your threat model and, perhaps, your paranoia.
The portable executable angle offers another use case. Package a VM with dependencies pre-installed, hand someone a .smolmachine file, and they run it without worrying about library versions or missing dependencies. It's heavier than a static binary, lighter than asking users to install Docker.
Technical Realities and Rough Edges
Default allocation is 4 vCPUs and 8 GiB of RAM, but memory usage is elastic via virtio-balloon—the host only commits what the guest actually uses. Idle vCPU threads sleep in the hypervisor rather than spinning.
Platform support covers macOS 11 and later on Apple Silicon (arm64) and Intel x86_64 (the latter untested, according to the docs), plus Linux on x86_64 and aarch64. Cross-architecture isn't supported. Volume mounts work for directories but not individual files. GPU support exists on a development branch but hasn't shipped yet.
The project offers TypeScript and Python SDKs (smolvm-node and smolvm-python), though using them requires running a local server on port 8080. Installation is straightforward: curl -sSL https://smolmachines.com/install.sh | bash. The code lives on GitHub under an Apache 2.0 license.
Releases v0.5.14 through v0.5.18 occurred between April 15 and April 17, 2026, focusing on bugfixes. Path canonicalization, symlink handling, SSH agent forwarding inside nested environments. The velocity suggests active iteration. The specificity of the fixes suggests a product still finding its footing.
Who's Behind It
Y Combinator's directory lists the founder as BinBin He. He, a software engineer based in Seattle, describes his work as serverless compute. The YC listing shows a team size of one—likely a placeholder—with Pete Koomen as the primary partner.
No public funding announcements beyond the YC backing. The GitHub handle @binsquare appears in the repo and site footer as the maintainer. This is early days, a team still figuring out what the market wants.
A Crowded Field
Smol Machines isn't entering empty territory. Firecracker is widely used in production microVM deployments according to various industry sources. Kata Containers wraps containers in VMs for Kubernetes. Projects like ZeroBoot claim sub-millisecond boot times through snapshot-based forking. And libkrun itself—the stack Smol Machines builds on—already powers tools like krunvm.
What distinguishes smolvm is the emphasis on portability and developer ergonomics. Less about building infrastructure, more about giving individual developers a tool that feels simple while delivering strong isolation. Whether that niche is large enough to sustain a business remains an open question.
The Docker comparison matters, perhaps more than the technical specs. Containers won developer mindshare through ease—easier than VMs, easier than configuration management, easier than explaining why something worked yesterday but not today. Smol Machines claims comparable ease with stronger security boundaries. If the boot times hold up in production workloads and the packaging story delivers, some fraction of Docker's user base might pay attention.
What Comes Next
The Hacker News reception suggests curiosity without conviction. Developers asked about benchmarks, questioned networking defaults, debated whether microVMs solve problems they actually face. Some saw value for AI safety use cases. Others dismissed it as overengineering in search of a problem.
Smol Machines faces the challenge every early-stage product faces: proving it's not just technically interesting but practically useful. The technology works—boot times are verifiable, isolation is demonstrable. The question is whether enough developers encounter situations where containers fall short but full VMs feel too heavy.
AI agents executing untrusted code might be that wedge. Or maybe it's something else the founders haven't anticipated yet.
For now, the product ships, iterates rapidly, and anyone can try it. Whether it becomes foundational infrastructure or a footnote in the history of developer tools depends on what happens when people actually use it. And on whether the team can articulate, clearly and convincingly, why this particular approach to isolation matters enough to change workflows.
That part's still being written.
