Projects · Dockerios
How Docker-OSX actually works
The technical teardown of Docker-OSX. What the container really contains, how the boot chain reaches a macOS installer, what every QEMU flag is for, and how the project convinces Apple's operating system it is running on a Mac.
How Docker-OSX actually works
This section has one job: explain the engineering inside Docker-OSX well enough that you could rebuild it from memory.
Not how to run it. The README does that better than I would. This is the layer underneath: what the container actually contains, what boots what, in which order, and which specific lies get told to macOS to make it start.
Anybody who has typed the docker run command, watched a macOS desktop appear on a Linux machine, and felt slightly suspicious about how that was allowed to happen.
You do not need prior QEMU knowledge. Every concept gets defined the first time it shows up, and there is a vocabulary section near the top that you can jump back to.
What is in here
| Page | What it covers |
|---|---|
| Inside the Docker-OSX engine | The complete teardown, in one page. Vocabulary, the container image anatomy, the boot chain, the QEMU command line flag by flag, the Apple identity subsystem, the bootdisk factory, how macOS gets downloaded, the image variants, persistence, access paths, and the honest limits of the design |
Because the pieces only make sense together. The reason the CPU model is Penryn lives in the OpenCore config. The reason a 384 MiB disk boots first lives in how UEFI firmware picks a bootloader. The reason your MAC address matters lives in Apple's licence servers.
Split those into separate pages and you get six pages of cross references. Keep them together and it reads once, in order, and lands.