Projects · Dockerios
MacRack
The commercial product. A Kubernetes operator that runs macOS virtual machines on Apple silicon Mac minis through Virtualization.framework, enforcing Apple's SLA by construction: two VMs per host, dedicated chassis per tenant, and a twenty-four hour minimum lease.
MacRack
DockerIOS was how I learned the problem. MacRack is the product I would actually sell.
They are two operators, in two repositories, with two API groups, two binaries, and no shared schema. That is not organisational tidiness. It is the only way one of them can be a public commercial artifact while the other remains a learning and legacy-preservation tool that nobody should ever deploy as a cloud.
MacRack exists because the DockerIOS substrate, KubeVirt on x86, cannot be made to respect Apple's software licence, no matter how carefully it is engineered. The restriction is on the hardware, not on the hypervisor. Section 02 named that as a strategic seam rather than an engineering one, and this section is the product that sits on the legal side of it.
I am not a lawyer, and nothing here is legal advice. The three SLA rules this operator enforces are my reading of Apple's published licence as of writing, aligned with how AWS EC2 Mac and MacStadium already operate. Anyone selling this needs their own counsel, because a licence is not a Kubernetes feature.
Why two products instead of two versions
I originally thought about v1 and v2 of the same CRDs. Kubernetes will not let me do that cleanly, and even if it would, I would refuse.
An API version of a Kind is not a product line. One CustomResourceDefinition object holds every version of that Kind, they share a storage version, and a conversion webhook has to understand both. Shipping MacRack publicly would have meant shipping the DockerIOS schema with it. That is the opposite of decoupling.
So:
| DockerIOS | MacRack | |
|---|---|---|
| Repository | Its own, published as learning and legacy tooling | Its own, the public commercial operator |
| API domain | dockerios.io | macrack.io |
| API version | v1alpha1 of its types | v1alpha1 of its types. Independent. Not a v2 of anything |
| Hypervisor | QEMU via KubeVirt, on x86 Linux | Apple's Virtualization.framework, on Apple silicon running macOS |
| Hardware | Any KVM-capable x86 node | Apple-branded computers the operator owns or controls. Mac minis, in the design |
| Purpose | Academic. Learning the boot chain. Guarding Intel Macs after Apple drops them | Selling macOS machines as infrastructure, inside the licence |
| Shared code | None. No shared Go module, no shared CRD, no shared container image. Ideas travel. Types and binaries do not | |
I built DockerIOS to understand how macOS actually boots on QEMU, and to have a control plane for Intel Macs after Apple walks away from them.
The timeline is not vague. macOS 26 Tahoe, shipped September 2025, is Apple's last Intel release. macOS 27, expected autumn 2026, is Apple silicon only. Tahoe keeps receiving security updates until autumn 2028, and then the last Intel Macs are outside Apple's support window.
DockerIOS is how I keep those machines useful in a lab, and how I learned enough to design MacRack without guessing. It is not, and will not become, a multi-tenant cloud. Anyone who takes the DockerIOS operator and sells VMs on x86 is on their own, and they are not following this design.
The pages
| Page | What it settles |
|---|---|
| Architecture on Apple silicon | How MacRack actually runs a VM. Mac minis as Kubernetes nodes, 10 GbE and 1 TB SSD, Virtualization.framework, a central store of OS-plus-Xcode goldens, and everything from DockerIOS that simply disappears |
| SLA compliance by construction | The three licence rules, mapped onto native Kubernetes primitives so they cannot be bypassed by a careless reconcile. Two VMs per host, dedicated chassis per tenant, twenty-four hour minimum lease, plus the audit trail |
| The MacRack API | The CRDs. A different group, a different set of kinds, designed around a leased chassis rather than a cloned disk. What a tenant asks for, what an admin owns, and where the workload layer attaches later |
| Building and operating MacRack | Operator SDK scaffolding for the public repo, the host agent, hardware and MDM, the kernel quota bug, packaging, and the order I would build it |
No MacRack package may import a DockerIOS package. No DockerIOS package may import a MacRack package. The two go.mod files share no replace directives pointing at each other.
If an idea is useful in both, it is rewritten. If a type looks similar, it is declared twice. Similarity is allowed. Coupling is not. I would rather maintain two small identity types than one shared module that makes the public binary a derivative of the learning one.