One OCI image. Any execution target. A single 12 MB binary.
Run the same OCI image as a container, Firecracker microVM, Apple Silicon VM, Kubernetes workload, or AI agent task. No daemon required. No overlayfs. No separate VM images.
Modern infrastructure runs on too many engines
Docker for development. containerd for production. Firecracker for isolation. CRI for Kubernetes. Separate tooling for AI agents. Each one has its own image format, storage layer, and operational model — even though they all run the same OCI images.
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.
Pullrun
One binary. One runtime. One image format. Containers, VMs, Kubernetes, and AI agents — all sharing the same OCI image, store, and execution model.
Everything you need, nothing you don't
A platform, not just a runtime. Image management, storage, security policies, secrets, CRI, Compose, and MCP — all in one binary, not a stack of separate daemons.
Content-Addressed DAG Store
Zero-copy reads via rkyv + mmap. Layers stored once by content hash — byte-identical across every node. 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.
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.
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 AI Integration
Native Model Context Protocol server — let AI agents run, stop, exec, and manage workloads through natural language. Agent → MCP → Pullrun → Container/VM.
Encrypted Secrets
AES-256-GCM at rest, decrypted into workload tmpfs at runtime. pullrun secret create/get/ls — data stays encrypted on disk.
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.
One command. Any platform. Zero daemon.
Install in 30 seconds and start running containers or VMs from the same OCI image.
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 |
| 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 AI integration | ✅ | ❌ |
| 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 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?
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 |
|---|---|
| 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 |
Ready to pullrun?
Install in 30 seconds. macOS, Linux, or Windows.