vmyard places and bin-packs microVM and container sandboxes onto a fleet of hosts, with the dataplane behind pluggable drivers for Firecracker, Cloud Hypervisor, and Docker. The design target is thousands of placements per second from a single scheduler node.
Kubernetes schedules services that start once and run for months. A sandbox is created in a burst next to a thousand siblings, runs for a few seconds, goes to sleep, and is expected back fast when its owner returns. Pushed through pod machinery, every one of those transitions pays for API round-trips, scheduling passes, kubelet reconciliation, and network setup that were priced for a workload changing state a few times a day.
Waiting for Kubernetes to grow into this is a bet against its own architecture: a control plane built on slowly converging desired state cannot become the fast path for millions of short-lived, stateful workloads. That gap is what vmyard is for.
| Phase | What happens |
|---|---|
| create | Boot a fresh sandbox from an image. The cold path. |
| place | Pick a host. Bin-pack for density while leaving headroom for wakes. |
| run | Code executes. The scheduler stays out of the way. |
| sleep | Snapshot and release CPU and memory. Identity and state are kept. |
| wake | Restore from snapshot. The latency this project is judged on. |
| destroy | Reclaim everything. |
Drivers own the dataplane. The scheduling core sees capacity, constraints, and lifecycle verbs; it never talks to a runtime directly. The shape follows the task-driver model proven in HashiCorp Nomad.
| Driver | Isolation | Status |
|---|---|---|
| firecracker | microVM | first target |
| cloud hypervisor | microVM | planned |
| docker | container | planned, for development and CI |
In development.
The scheduling core and driver interface are being built. There is no release, no installer, and nothing to run yet; this page exists so the project has an address. Source opens with the first runnable release.