A new open source project called kvz packages a full Kubernetes distribution for Apple Silicon Macs as a single binary that runs the control plane as an ordinary macOS process, with no Linux VM underneath. The code appeared on GitHub under the kvz-platform organization on 2 November 2026, released under the Apache License 2.0, and its own documentation describes it as young software that should not yet carry production workloads.
The key points of kvz, Kubernetes for the Mac, in 30 seconds
- kvz embeds kube-apiserver, the scheduler, the controllers and etcd in one macOS process, in the style of k3s.
- Pods can be Linux microVMs, full macOS virtual machines or native macOS processes.
- It requires an Apple Silicon Mac with macOS 26 or later and installs through Homebrew.
- The project reports 454 of 454 conformance tests passed on Kubernetes 1.37.2 and faster lifecycle numbers than k3s in Lima, measured by its own harness.
The repository is written in Go, and its commit history shows a single human author, Subham K. (GitHub user GrowlyX), alongside automated Dependabot updates. All 122 commits on the main branch carry timestamps from 2 November 2026, and two version tags exist so far, v1.35.10-1 and v1.37.2-2. Releases are named after the Kubernetes version they embed, followed by a kvz release number. The documentation also points to an official site at kvz.systems. Nothing in the repository names a company behind the project.
One macOS process for the whole control plane
Most ways of running Kubernetes on a Mac start a Linux virtual machine and put the cluster inside it. That is how k3s runs under Lima, and it is how Apple’s own container tooling builds a cluster. kvz turns that around. According to its architecture document, it imports k8s.io/kubernetes v1.37.2 as a library, without forking it, and runs the API server, controller manager and scheduler inside one signed darwin/arm64 process. etcd is embedded in the same binary.
The node side is built on a vendored virtual-kubelet that hands each pod to a runtime chosen with the standard runtimeClassName field. Four runtimes are documented:
- linux (the default): every pod boots its own Linux microVM through Apple’s Virtualization.framework, using an 8.5 MB kernel based on Linux 6.18 LTS and a small Go init process. The image is shared read-only over virtiofs with a writable layer in memory.
- macos: a full macOS virtual machine per pod, cloned with APFS
clonefilefrom a bundle in tart’s layout, withkubectl execandkubectl logsgoing over SSH. - darwin: native macOS processes on the host, aimed at Xcode builds, code signing or GPU work.
- apple: the project’s first Linux runtime, which goes through Apple’s container daemon and is kept mainly as a benchmark baseline.
Networking runs in-process as well. Each node hosts an L2 switch and gateway built on the gVisor netstack (via gvisor-tap-vsock), and every pod VM’s network card is one end of a socket pair. The architecture notes say this replaced Virtualization.framework’s NAT mode because hard-stopped VMs leaked kernel interfaces until the host could not create new ones. The feature list includes ClusterIP, NodePort and LoadBalancer Services, a built-in cluster DNS server, NetworkPolicy enforcement in the pod switch and Traefik as the default Ingress controller. Several Macs can be joined into one cluster with k3s-style join tokens.
The design also sets hard limits, and the documentation states them plainly. Virtualization.framework allows roughly 127 VMs per Mac, so kvz runs up to 120 Linux pod VMs per node and queues the rest. macOS itself permits only two macOS guests per host. User namespaces, AppArmor and seccomp profiles are not supported; the project relies on the VM boundary to isolate pods.
Installation, per the README, takes a Homebrew tap and one command to start the server:
brew install kvz-platform/tap/kvz
kvz serverFrom a second terminal, the documented first pod looks like any other cluster:
export KUBECONFIG=~/.kvz/kubeconfig.yaml
kubectl run web --image=nginx:alpine
kubectl get podsCode language: JavaScript (javascript)The getting started guide lists an M1 or later Mac, macOS 26 or newer and kubectl (kvz also bundles one as kvz kubectl). tart is only needed for macOS pods pulled from OCI images. Early releases are ad-hoc signed rather than notarized, according to the same guide.
What the project’s own benchmarks claim
The figures below come from kvz’s BENCHMARKS.md, dated 2 November 2026, and were produced by the author with the project’s own client-go harness (cmd/kvzbench). No independent party has reproduced them. The test machines were three M4 Mac minis (10 cores, 16 GB, macOS 26.6.2) and a Mac Studio listed with an M5 Max, 36 GB and macOS 27.0.1. The document says the Studio had about 26 unrelated OrbStack containers running throughout, and that the minis carried some background jobs from other projects. k3s ran inside a Lima VM with 8 CPUs and 12 GiB on the minis; Apple’s container cluster 1.6.1 used the same sizing. Images were pulled before timed runs, and the author states that no VM pools, snapshots or pre-started pods were used. Values are medians.
| Metric (M4 median) | kvz | k3s in Lima | Apple container cluster |
|---|---|---|---|
| Fresh start to API ready | 3.9 s | 17.8 s | 58.6 s |
| Idle memory | 257 MB | 3,192 MB | 2,453 MB |
| 1 nginx pod to Ready | 99 ms | 421 ms | 859 ms |
| 50 nginx pods to all Ready | 1.51 s | 4.48 s | 4.20 s |
| ConfigMap creates per second (32 clients) | 9,614 | 3,200 | 7,974 |
| Pod-to-pod iperf3, 1 stream (host lexie) | 52.5 Gbps | 83.9 Gbps | 86.4 Gbps |
Two caveats sit in the same document. First, kvz’s low write latency depends partly on a durability trade-off: it runs etcd with F_BARRIERFSYNC by default, a write-ordering barrier that the architecture notes call crash-consistent but which can lose the most recent commits on sudden power loss. With --etcd-sync=full the create-to-watch latency rises from about 0.4 ms to about 4 ms. The author argues that the VM-based platforms’ guest fsync does not reach the drive cache either. Second, networking is slower. “kvz loses here by design: each pod is its own VM,” the benchmark notes say, since frames have to cross Virtualization.framework and a userspace switch while the competitors’ pods share one kernel.
The report also includes a reliability run of 20 rounds of 50 pods on the Studio with zero failures and no leaked VMs, and a four-Mac cluster that brought 200 Linux pods to Ready in 1.68 seconds. Both results come from the same author and setup.
Maturity, gaps and where it fits
The README is direct about status. kvz passes all 454 tests of the Sonobuoy certified-conformance suite on a two-node cluster running Kubernetes v1.37.2, and runs Deployments, StatefulSets, Jobs, Services, Ingress and HA control planes, “but nobody has run it in production yet, so please don’t run production on it yet.” The project is days old, has one main contributor and, at the time of writing, a single-digit star count. The conformance result is self-reported and does not mean the distribution has been certified by the CNCF.
The documentation is not fully consistent either. ARCHITECTURE.md ends with a list of features it marks as not implemented yet, including Services/kube-proxy, cluster DNS and cross-node pod routing, while kubernetes-features.md and the README describe all three as working. The more detailed feature page appears to be the newer of the two, but readers testing kvz should check behaviour rather than rely on either file.
For administrators, the interesting part is the native macOS side. Teams that already keep a shelf of Mac minis for iOS and macOS builds usually manage them with separate CI agents or VM tools such as tart. kvz proposes scheduling those jobs, macOS VMs and Linux containers through one Kubernetes API, using the same YAML and kubectl as elsewhere. The project’s fleet guide covers joining several Macs into one cluster. Whether that holds up beyond a lab will depend on testing that the project itself says has not happened yet.
Frequently asked questions
What is kvz?
kvz is an open source Kubernetes distribution for Apple Silicon Macs. It runs the control plane as one native macOS process and runs pods as Linux microVMs, macOS VMs or native macOS processes.
What do I need to run kvz?
An Apple Silicon Mac (M1 or later) with macOS 26 or newer. It installs with Homebrew from the kvz-platform tap, and tart is only needed for macOS pods pulled from OCI images.
Is kvz ready for production?
No. Its README says nobody has run it in production yet and asks users not to, even though the project reports passing all 454 Kubernetes conformance tests.
Is kvz faster than k3s in Lima?
In the project’s own benchmarks it was faster on startup, idle cost, API throughput and pod lifecycle, but slower on pod-to-pod bandwidth. Those numbers were measured by the author and have not been reproduced independently.
Sources: