Cloud & InfraArticle Pullrun revives an old promise just as AI agent sandboxing finally makes it urgent.
Ji-ho Choi
A project called pullrun hit the Hacker News front page this week with a seductive pitch: pullrun run alpine:3.18
starts a container, add --backend vm
and the exact same OCI image boots as a Firecracker microVM. No second image format, no VM build pipeline, no daemon running as root. One image, and isolation becomes a flag.
It's a genuinely good idea. It's also not a new one — and the interesting question isn't whether pullrun works, but why this idea keeps getting rebuilt, and why 2026 might finally be the year it sticks.
You could already do this. Nobody enjoyed it. #
Running unmodified OCI images inside microVMs has been possible for years. AWS shipped firecracker-containerd back in 2019 precisely so containerd could schedule ordinary container images into Firecracker VMs. Kata Containers does the same trick at the Kubernetes layer: set a RuntimeClass
on a pod and it runs in a lightweight VM instead of a shared-kernel namespace, Firecracker optionally underneath. Weave Ignite gave Firecracker a docker run
-style UX in 2019 and is now archived. And Fly.io has been transmogrifying Docker images into Firecracker root filesystems in production since roughly 2020.
So the "you can now" framing undersells how old this capability is. What's actually true is that every existing path drags in a stack most developers won't set up voluntarily: containerd plus a shim plus a guest kernel you source yourself, or a full Kata install, or a Kubernetes cluster, or someone else's cloud. The capability existed; the ergonomics never did. That gap — not the VM boot itself — is the thing pullrun is attacking.
What pullrun actually changes #
The project's bet is that the whole container/VM split is an artifact of accumulated tooling, not a real technical boundary. It ships as a ~14 MB Go CLI talking gRPC to a ~6 MB Rust daemon, runs rootless by default, and swaps overlayfs for a content-addressed DAG store — layers deduplicated by hash, memory-mapped rather than extracted, synced peer-to-peer between nodes. On top of that sit runc containers on Linux, Firecracker on Linux and WSL2, and Apple's Virtualization framework on M-series Macs, all fed from the same image store. There's a Docker Compose-compatible frontend where --backend vm
boots an entire compose file as microVMs, plus a CRI shim (beta) and an MCP server so AI agents can drive it directly.
The kernel-sourcing problem — historically the worst part of DIY Firecracker — gets a reasonable answer: pullrun kernel install
fetches a Kata guest kernel automatically. One HN commenter correctly noted the residual sharp edge: your workload now runs on a kernel your distro's package manager has never heard of, so anything expecting matching linux-headers
will break. That's inherent to the approach, not a pullrun bug, but it's the kind of thing that bites you in CI at 2 a.m.
The self-reported numbers are plausible for the architecture — ~400 ms container starts, ~500 ms cold Firecracker boots, ~160 ms Apple VM boots, a 24 MiB idle daemon — and the benchmark script ships in the repo. Treat them as vendor numbers until you've run hack/bench.sh
yourself; nobody independent has published a reproduction yet.
Why this idea is back now #
The honest answer is AI agents. Firecracker was built for Lambda's multi-tenancy, but the current wave of interest comes from sandboxing LLM-generated code — E2B, Fly Machines, CodeSandbox, and half the agent-infrastructure startups of the last two years are Firecracker or microVM shops, because handing an agent a shared-kernel container is a bad time. Even Apple's own container project, announced at WWDC 2025, runs every container in its own lightweight VM.
That demand changes the shape of the problem. When isolation was a per-cluster decision, Kata-on-Kubernetes was an acceptable cost. When it's a per-task decision — this agent workload is untrusted, boot it in a VM; this build step is fine, run it as a container — you want exactly what pullrun's compose flag implies: isolation chosen at schedule time from one artifact. The MCP server makes the target audience explicit. This is a runtime designed to be operated by agents as much as by humans.
Should you touch it? #
Not in production, and the project's own signals say so as clearly as mine do. It's at v0.6.7 with 56 GitHub stars and 189 commits; multi-node orchestration is labeled work-in-progress. The HN thread also raised a softer flag worth weighing: commenters called out the maintainer's replies as obviously unedited LLM output, and for a security-boundary component — the one piece of your stack whose entire job is containing hostile code — provenance and review culture matter as much as design. A Rust codebase this ambitious, this young, with this little independent scrutiny is a research artifact, not a foundation.
If you need VM-grade isolation for container images today, the boring answers still win: Kata via `RuntimeClass`
if you're on Kubernetes, firecracker-containerd if you're building a platform, a managed sandbox provider if you're shipping an agent product this quarter.
But as a signal, pullrun is worth more than its star count. Ignite died with Weaveworks, yet the itch it scratched keeps regenerating — and this time there's a paying use case attached. The likely endgame isn't that a 56-star repo dethrones containerd; it's that containerd, Podman, and the managed platforms absorb the UX pullrun is demonstrating, and "container or microVM" quietly becomes a scheduling flag everywhere. The image format already won that war. The runtimes are just catching up.
Sources & further reading #
Ji-ho Choi· Security & Cloud Editor Ji-ho covers the increasingly tangled overlap between cloud architecture and security, drawing on a background as a penetration tester to keep his reporting grounded in real-world attack paths. He never lets a vendor claim go unquestioned and insists that every buzzword come with a proof of concept.
Discussion 0 #
No comments yet
Be the first to weigh in.