Every agent task. Its own sandbox. 400 ms.
Pullrun is the AI agent sandbox runtime. The same OCI image boots as a microVM, container, or Apple Silicon VM — with native MCP for opencode, Claude Code, and Cursor. No daemon. No overlayfs.
Agents need to run code — nothing runs it safely, fast, and cheap
AI agents churn through executions by the thousands. Host exec is unisolated. Docker gives you slow ~800 ms starts and a full image copy per task. VMs give isolation but heavyweight tooling built for servers, not tasks. And none of it hands your agent a control plane it understands.
Agent sandboxes today
Unisolated host exec (dangerous), slow per-task containers that duplicate the image every time, or heavy VM tooling with its own image format. No cross-turn state, no fleet-wide storage sharing.
Docker
Great developer UX, but requires a daemon, doesn't support VMs natively, and doesn't integrate with Kubernetes CRI without containerd.
Kubernetes (CRI-O / containerd)
Production-grade, but no local dev workflow, no VM execution, no AI agent interface — you need 4 different tools to cover dev + prod + VMs + agents.
Firecracker / Kata
Strong VM isolation, but require separate VM image tooling and don't speak OCI natively without containerd shims.
Built for agent workloads, sized for fleets
Fast, isolated, cheap sandboxes — with storage that makes the N-th sandbox essentially free. Image management, security policies, secrets, CRI, Compose, and MCP — all in one binary, not a stack of separate daemons.
AI Agent Sandboxes
MicroVM per task — booted from any OCI image in ~400 ms, kernel-level isolation for untrusted agent code, cross-turn state via commit/snapshot, and a native MCP server agents drive directly.
Content-Addressed DAG Store
Zero-copy reads via rkyv + mmap. Layers stored once by content hash — 1,000 sandboxes share one copy of the image. Mark-and-sweep GC reclaims unreachable blobs. No overlayfs, no layer duplication, no escape CVEs.
Universal OCI Execution
Same image → runc container, Firecracker microVM, or Apple Silicon VM. No separate VM image build step. The OCI manifest is the rootfs.
Kubernetes CRI
Drop-in CRI shim with RuntimeClass support (pullrun-container / pullrun-vm). Full exec, attach, port-forward, and events.
Docker Compose
Full Compose-compatible workflow: up, down, logs, ps, build — parse standard docker-compose.yml, zero changes.
Policy Engine
Cosign signature verification, SBOM evaluation, seccomp profiles, read-only rootfs — gate workloads before they run. Defense-in-depth as code.
MCP Server
Native Model Context Protocol — 15 tools (run, exec, logs, build, push…) over stdio or SSE. opencode, Claude Code, and Cursor pull images, boot sandboxes, and inspect state through natural language.
Encrypted Secrets
AES-256-GCM at rest, decrypted into workload tmpfs at runtime. pullrun secret create/get/ls — data stays encrypted on disk.
P2P Image Distribution
Nodes share image blocks peer-to-peer via gRPC and Bloom filters. One pull from registry; the rest delta-sync from each other at LAN speed.
Apple Silicon Native
Native macOS VM backend via Virtualization.framework — boots Linux VMs on Apple Silicon with full isolation. No Docker Desktop, no Linux VM needed.
How it all fits together
Not a collection of tools — a single runtime platform where OCI is the universal abstraction for every execution model.
Every target uses the same OCI image. Pullrun handles storage, security, distribution, and orchestration — so you don't need a different runtime for each workload type.
Performance that speaks for itself
Every millisecond matters. Pullrun is architected for speed from the ground up.
Give it a spin in the terminal
Boot a sandbox in 30 seconds — the same image runs as a container, VM, or agent task.
Type help for available commands in the terminal.
Built different from the ground up
No overlayfs. No daemon tax. No separate VM images. A platform, not just a runtime.
Pullrun vs Docker
Same OCI images. Radically different architecture. See also: ecosystem positioning →
| Metric | Pullrun | Docker |
|---|---|---|
| First alpine:3.18 pull | 968 ms | ~2 s |
| Container run latency | ~400 ms | ~800 ms |
| Apple Silicon VM boot | ~160 ms | N/A |
| Agent sandbox (Firecracker VM) | ~500 ms | N/A |
| Idle daemon RSS | 24.6 MiB | ~90 MiB |
| Binary size | 12 MB | ~75 MB |
| Rootless by default | ✅ | ❌ |
| Containers + VMs from same image | ✅ | ❌ |
| P2P image sync | ✅ | ❌ |
| MCP for AI agents | ✅ | ❌ |
| MicroVM per agent task | ✅ | ❌ |
| Content-addressed store | ✅ | ❌ |
| Optional daemon | ✅ | ❌ |
Apple M3 (macOS 14), cold cache, alpine:3.18. Pullrun vs Docker Desktop 4.27. Your results may vary. Full methodology →
Common questions
Everything you need to know before getting started.
How does Pullrun work with AI agents?
pullrun mcp). Flow: Agent → MCP → Pullrun → Container/VM. Agents pull images, boot per-task microVM sandboxes in ~400 ms, exec, snapshot state with commit, and push builds — through 15 tools (run, exec, logs, statatch, build, push…) in stdio or SSE mode. Because sandboxes share one content-addressed image copy, a fleet of agents costs about the same storage as one.How is this different from Podman?
Can I use my existing Docker Compose files?
pullrun compose up -f docker-compose.yml and it works — dependency ordering, port mapping, environment variables, volumes, resource limits, and per-project bridge networks are all supported.Is this production-ready?
Does it require root or a daemon?
sudo needed, no central daemon. The optional runtime daemon (pullrun-runtime) is only required for background sync, policy enforcement, and Prometheus metrics. For basic use, the CLI runs standalone.What platforms are supported?
Is Pullrun open source? How do you make money?
Where Pullrun fits in your stack
Not a replacement for everything — a unification layer where OCI images become the universal primitive.
| If you use | Pullrun gives you |
|---|---|
| AI agents (opencode, Claude Code, Cursor) | Native MCP server + per-task microVM sandboxes + DAG dedup for fleets + cross-turn state via commit/snapshot |
| Docker | Daemonless runtime + native VM execution from the same image + P2P distribution + CRI shim |
| Podman | Kubernetes CRI support + Firecracker/Apple VM backends + MCP AI agent protocol + P2P block sync |
| containerd | Integrated content-addressed DAG store + P2P distribution + Compose + secrets in a single binary |
| CRI-O | Local development workflow + VM execution via RuntimeClass + AI agent integration via MCP |
| Firecracker / Kata | OCI-native VM workflows — no separate VM image builds, no containerd shim needed |
Open source. And ready to be a business.
Pullrun ships as Apache-2.0 open source — and as a commercial offering for teams that run it in production. Same runtime, same images: from free OSS to a supported, licensed deployment.
Shipped and available today
Security Policy Engine
Deny-by-default image gate: cosign signature verification, CycloneDX SBOM checks (CVSS cap, license deny-list), evaluated at pull and run. Per-workload hardening: seccomp allowlists, read-only rootfs, no-new-privileges.
Observability
Prometheus /metrics endpoint on the runtime daemon — pull & start latencies, running workloads, store size, sync peers. Live pullrun stats and an event stream (pullrun events) covering pulls, runs, exits, and every policy decision.
Secrets & Config
Docker-style secret and config management — create, list, inspect, remove — mounted under /run/secrets, never stored in plaintext in workload images.
Air-Gapped Fleet Sync
P2P image distribution between nodes — one pull seeds the fleet. Kernel-as-image updates, offline registries, and DAG garbage collection keep air-gapped clusters self-sufficient.
Kubernetes CRI
CRI shim (beta) with v4 streaming exec/attach — run Pods against Firecracker VM backends via RuntimeClass, with per-pod bridge subnets and NAT.
Enterprise License
Per-cluster licensing for production fleets — Kubernetes CRI runtime, agent sandbox farms at scale, air-gapped registries, kernel-as-image updates. Predictable per-node pricing.
For AI agent platforms
Embedded Agent Sandboxes
License Pullrun inside your agent product — Claude Code, opencode, Cursor-style products included. Per-task microVM sandbox in ~500 ms cold / ~200 ms warm, driven over a native MCP server (15 tools: run, exec, logs, build, push, commit…).
Fleet Economics
Content-addressed DAG storage: 1,000 concurrent sandboxes share one copy of each image, mmap'd from the same host pages (idle daemon RSS 24.6 MiB). Sandbox cost stays flat as the fleet grows — the N-th sandbox is essentially free.
Isolation & Guardrails
Kernel-per-task microVMs for untrusted agent code — no shared-kernel escapes. Deny-by-default image policy, seccomp profiles, read-only rootfs, no-new-privileges; every policy decision emitted as an audit event.
Hosted Sandbox API
Planned: managed sandbox endpoints — boot, run agent, snapshot state, resume — billed per active sandbox-second. Your agents get enterprise isolation without you running a single VM.
How we sell it
Professional Services
We deploy and tune Pullrun on your infrastructure: custom executors and backends, P2P fleet network design, policy & seccomp hardening, migration from Docker/containerd, team training.
Managed Control Plane
Planned: a hosted SaaS control plane — fleet-wide image sync, policy center, secrets, and observability across hundreds of nodes, billed per active sandbox. Built and run by the team that writes the runtime.
Support & SLAs
Priority engineering support with response SLAs for enterprise deployments — security fixes, backports, and a roadmap that follows paying customers.
OEM & Embed
Build Pullrun into your product: per-seat OEM licensing, custom MCP tool surfaces, co-branded runtime, and white-glove onboarding for agent platform vendors.
Enterprise conversations start here — open an issue on GitHub.
Ready to pullrun?
Give your agents a sandbox that boots in 400 ms. macOS, Linux, or Windows.