Namespace racks MacBooks for iOS builds: what it takes in a data center

Namespace, a provider of build and test environments, has put hundreds of MacBook Pros into data center racks. Kirill Nikolaev explains why in the Namespace blog of 3 November 2026: Mac minis ordered in January arrived in July. The text is a vendor source. It has useful detail, but every number in it is Namespace's own statement, and we have not re-measured any of them.

A Mac rack in a data center is a row of Apple computers operated remotely through IP-KVM and used as build hosts for macOS and iOS. Apple allows only two macOS guests per Mac, so each machine splits into at most two virtual machines. iOS apps can only be built on macOS, the iOS Simulator runs only there, and the App Store requires a recent Xcode version.

Why laptops, and what comes with them

Namespace calls the Mac mini the better data center choice, but it was not deliverable. Each MacBook therefore connects to an IP-KVM, because on laptops some maintenance steps can only be done through the graphical interface. Each also gets an external 10 Gbit Ethernet adapter. According to the post that makes four cables per laptop, 48 cables per shelf and twelve network cables on top. It follows that a shelf holds twelve machines; the text does not say so.

The most frequent cable failure was not MagSafe but HDMI, which falls out when someone touches the shelf. Namespace says it bought the entire available stock of a cable that suits the job.

The FileVault trap

After an unplanned reboot a MacBook with FileVault asks for a password before the disk is accessible. The prompt appears on the screen of a closed laptop. According to Namespace it disappears from an external monitor after five minutes, which includes the KVM picture.

Since macOS 26 Tahoe the drive can be opened over SSH. Apple's man page apple_ssh_and_filevault(7) describes password login while the data volume is locked. On laptops this window also expires after five minutes (Namespace); the man page names no time limit. The way out was to press the power button and enter the password in time.

Anyone who triggers a restart on purpose can use fdesetup authrestart. It reboots and leaves the disk open. It works for planned restarts only, not after a power cut.

Two VMs per Mac

Namespace uses Apple's Virtualization framework. The Hypervisor framework is out because it cannot start macOS. The limit of two macOS VMs per physical Mac comes from the license: section 2B (iii) allows up to two additional instances, among other purposes for software development and testing. The Eclectic Light Company checked this in 2022 for Monterey and measured it: the third VM fails with the error "maximum supported number of active virtual machines has been reached". We have not read the current license text ourselves.

The limit shapes how Namespace sizes instances. A 14-core Mac mini is split into instances of 6 or 12 cores, an 18-core MacBook into instances of 8 or 16 cores, with a few cores kept for management. Most likely this means two halves of 6 and 8 cores; that is a conclusion from the numbers, the text does not spell it out.

Guest networking runs through a userspace TCP/IP stack from Google's gVisor, so Namespace controls every packet path and can enforce egress rules. The price is a detour across process boundaries. Namespace reports that macOS instances reach 4 Gbit/s upstream this way, measured with Fast.com and below line rate.

Distributing 500 GB images

A macOS image, Namespace says, with several Xcode versions and iOS runtimes grows to 500 GB, and several variants to 2 TB. Namespace stores the images as sparse layers in its OCI registry: empty ranges cost a few bytes, and an image with an extra Xcode shares its base layer with the predecessor.

The images reach the nodes by peer-to-peer distribution. Sending 500 GB to hundreds or thousands of nodes comes to about half a petabyte by Namespace's estimate, which would mean terabits per second at the central registry over a few tens of minutes. Each block is therefore fetched from the registry once and then passed between nearby nodes. On disk Namespace uses sparse files and APFS clones (cp -c or the clonefile system call), so holes and shared blocks take no space. The VM boots from the local disk because a network block device would cross the process boundary on every I/O.

We have not re-measured any of these numbers. We found no independent check of the network, distribution or five-minute figures; the discussion on Hacker News brings no measurements on them.

What this means for us

No Mac appears in our host inventory, so this post is market observation and not field experience. Three points carry over to planning iOS builds: at most two macOS guests per Mac, long Mac mini lead times in 2026, and a FileVault machine needs a plan for unplanned reboots. For build and test capacity there is the hub Servers, Proxmox and network. How VMs and containers differ for workloads is covered in Proxmox: GPU VM or LXC. For infrastructure consulting see Services.

The open question for anyone racking Macs: does the reboot plan work without hands on site before the first machine fails?

Further reading

• Namespace, Mac at Any Scale (Kirill Nikolaev): namespace.so
• Apple, SSH and FileVault: apple_ssh_and_filevault(7)
• Eclectic Light Company, how Apple limits VMs: eclecticlight.co
• Apple, macOS license texts (index, not read): apple.com/legal/sla
• Discussion on Hacker News: news.ycombinator.com