Where this project is right now

This knowledge base covers two operators that share a problem and share no code.

DockerIOS is how I learned the boot chain, and how I keep Intel Macs useful after Apple drops them. It runs macOS on KubeVirt, on x86. It is not a commercial cloud.

MacRack is the product I would sell. It runs macOS virtual machines on Apple silicon Mac minis through Virtualization.framework, and it enforces Apple's SLA by construction: two VMs per host, one tenant per chassis, twenty-four hour minimum lease.

They are two repositories, two API domains, two binaries. Ideas travelled. Types and packages did not.

DockerIOS

Here is the situation that starts this project.

macOS is the only operating system in mainstream software delivery that legally and practically wants to run on hardware you must buy from one vendor. Everything else, you rent by the second. So the moment your pipeline needs to build an iOS app, sign a .pkg, or run an Xcode test suite, you stop being a platform engineer and become a person who owns Mac Minis.

I have lived on the other side of that. I ran Docker-OSX in production work, and it worked. Which is exactly why I stopped and asked the harder question.

The question that made me write this

I could use Docker-OSX. I could not explain it.

I knew which flags to pass. I did not know why the CPU had to be a Penryn, what the OSK string was doing, why a 384 MiB disk had to be attached before the real one, or what exactly Apple was being told about the machine it was booting on.

If I cannot explain it, I cannot rebuild it, and I definitely cannot scale it.

What this is aiming at

The destination is a control plane that treats a macOS machine as a schedulable resource: ask for one, get one, have it register itself as a build runner, throw it away when the job is done.

There are two honest ways to get there, and they are not two versions of the same way.

	DockerIOS	MacRack
Hypervisor	QEMU via KubeVirt, on x86 Linux	Apple's Virtualization.framework, on Apple silicon running macOS
API	`dockerios.io/v1alpha1`	`macrack.io/v1alpha1`
Why it exists	Learning. Guarding Intel Macs through Apple's 2028 security-update window	Selling macOS machines as infrastructure, inside the licence

The timeline that makes DockerIOS a legacy tool rather than a dead one: macOS 26 Tahoe (September 2025) is Apple's last Intel release, macOS 27 (expected autumn 2026) is Apple silicon only, and Tahoe's security updates run until autumn 2028. After that, the last Intel Macs are on their own, and DockerIOS is how I would still run them in a lab.

How the sections are ordered

Why the teardown comes first, on its own

Section 01 contains no operator design at all. Designing on top of a system I only half understand is how you end up rebuilding its accidents. Sections 02 and 03 are allowed to propose DockerIOS because section 01 earned it. Section 04 is allowed to leave that stack behind because 02 and 03 named the seams that do not move.

Section	What it gives you
01 How Docker-OSX actually works	The full teardown: the container image, the boot chain, the QEMU command line flag by flag, the Apple identity subsystem, the bootdisk factory, and the vocabulary you need to read any of it
02 DockerIOS, the next generation	Every constraint the teardown found, answered with an existing supported mechanism on KubeVirt. Also the eight seams that stay open, including the licence and the Intel sunset
03 The DockerIOS operator	The KubeVirt-on-x86 operator. Learning, and legacy Intel Macs. Not a commercial cloud. CRDs under `dockerios.io`, Operator SDK, the domain hook, identity, golden images
04 MacRack	The commercial operator. Mac minis, Virtualization.framework, two VMs per host, dedicated chassis per tenant, twenty-four hour leases. CRDs under `macrack.io`. No shared code with DockerIOS

Credit where it belongs

This project stands on other people's work, and pretending otherwise would be both rude and useless to you as a reader.

Project	What it contributes
Docker-OSX by sickcodes	The containerisation, the runtime configuration model, the image variants, and the identity generation tooling
OSX-KVM by Dhiru Kholia	The underlying QEMU and OVMF recipe, the EFI tree, and the macOS fetch tooling that Docker-OSX clones at build time
OpenCorePkg by Acidanthera	OpenCore itself, plus `macserial`, the tool that generates plausible Apple serial numbers
osx-serial-generator by sickcodes	The bootdisk factory: plist templating plus a libguestfs pipeline that builds a bootable EFI image

On legality, said once and said plainly

Apple's software licence agreement permits macOS virtualisation on Apple-branded hardware you own or control, with a cap of two concurrent virtual copies per machine, and with further constraints if you are hosting for third parties.

DockerIOS, KubeVirt on x86, sits outside that agreement. I built it to learn, and to keep Intel Macs useful in a lab after Apple's support window. I am not selling it as a cloud, and section 03 is explicit about that.

MacRack is the operator that stays inside the agreement: Apple silicon, Virtualization.framework, two VMs, dedicated chassis, twenty-four hour floor. I am not a lawyer. Anyone selling MacRack still needs counsel. The operator's job is to make the numerical and tenancy rules impossible to violate by accident.

Docker-OSX is published as security research tooling and its author is explicit about that framing. Section 01 documents how it works, which is an engineering exercise.