Namespace explains how it runs macOS CI on racks of MacBook Pros

Namespace, a provider of CI and cloud instances, has published a long engineering post on why and how it runs macOS workloads on racks of MacBook Pros in a datacenter. The author opens by pointing to a video of hundreds of MacBook Pros being unpacked for the racks, which went viral on X.

The reasoning is practical. Many customers build and test iOS apps, and that requires a Mac: the iOS Simulator only runs on one, and the App Store requires a recent Xcode version. The author says the open-source xtool is cool but not yet a serious replacement. The author concedes that Mac Mini would be a better datacenter choice than a laptop, despite rudimentary remote management, no redundant power and a case that makes cooling hard. But Namespace ordered a couple hundred Minis in January and they arrived in July, in what the author calls the disarray of the 2026 supply chain. Apple also does not update CPU models across all devices at once: Mac Mini went 10 months without M5 cores, then got M6 before any other model. Since Namespace promises customers the newest hardware, it built the MacBook-in-Datacenter project.

Each MacBook is connected to an IP KVM, which the author calls indispensable because laptop firmware is designed with a screen in mind and some maintenance can only be done by clicking in the GUI. Each also gets an external 10G Ethernet NIC. Counting power, the cabling comes to four cables per laptop and forty-eight per shelf, plus twelve for Ethernet and the KVM wiring. For heat, Namespace is deploying custom-made holders that wick heat from hotspots and steer hot air away from neighbouring machines.

The problems were not the expected ones. MagSafe disconnections were very rare. HDMI was the least reliable cable: thick, inflexible and prone to falling out when the shelf is touched. Namespace found cables that bend the right way and bought the entire supply on Amazon. FileVault was a bigger pain. After an unplanned reboot a MacBook asks for a password to unlock its disk, on the screen of a closed laptop. The KVM prompt disappears after 5 minutes of inactivity, and the SSH-based remote FileVault unlock added in macOS Tahoe also expires after 5 minutes on laptops. The only way out can be to press the power button and race to unlock in time. The author's tip: fdesetup authrestart reboots a Mac while keeping the disk unlocked. There is also a bug where an external USB NIC shows no link until the network service is deleted and recreated in macOS settings.

M5 and M6 Mac Minis and Studios are due to join the fleet soon, with no timescale beyond that. They are simpler: built-in 10 Gb networking, automatic boot after a power cycle, and full configuration through MDM. Namespace designs custom shelves for them, tested with airflow simulation. Installation means unpacking, putting 10 machines in a holder, connecting power and network, and pressing the power button once.

On the software side, every Namespace instance is a virtual machine, and several VM engines sit under one platform for Linux, Windows and Mac. The Mac engine uses Apple's Virtualization framework, which the author compares to Firecracker. Apple's lower-level Hypervisor framework, comparable to Linux KVM, cannot run macOS. Apple allows only two macOS VMs per physical Mac, even on a Mac Pro with 24 cores and 192 GB of memory, so Namespace can only split a machine in halves: instances of 6 or 12 cores on 14-core Mac Minis and 8 or 16 cores on 18-core MacBooks, with a couple of cores reserved for management. Because the virtual CPU runs in a separate VMM process, every hook into VM behaviour costs an IPC roundtrip.

For networking, the built-in bridged and NAT modes suit trusted local workloads, but Namespace instances run untrusted code and need customer-definable access policies. So Namespace processes every packet in software, using a userspace TCP/IP stack from Google's gVisor project as an IP gateway and firewall, which limits host exposure to guest-controlled packets. Batching reduces IPC roundtrips. The result is 4 Gbps upstream bandwidth per Fast.com, below line rate. Approaches that avoid IPC entirely are being explored but not yet productionized.

The last section covers VM images. A first macOS VM is easy to make, but adding several iOS runtimes and an Xcode beta can push an image to 500 GB. Keeping the previous macOS adds another 500 GB, and a developer-preview image adds one more. A beta Xcode can subtly break stable Xcodes on the same system, because installing it bumps the global CoreDevice and CoreSimulator versions, so images with and without pre-release Xcodes must be kept. In the author's example that reaches 2 TB, which does not fit on a 2 TB MacBook drive. Namespace therefore has to build, distribute and store huge images across a fleet of hundreds of machines. Builds are scripted to mimic a human user (shell commands, UI clicks over VNC, reboots), defined as a YAML workflow, and the resulting images go to Namespace's internal Image Registry, the same one used for Linux and Windows images. The post's visible text ends partway through that section.

Key facts

Namespace runs macOS instances as VMs on racks of MacBook Pros because a couple hundred Mac Minis ordered in January arrived in July, and Mac Mini went 10 months without M5 cores.
Each MacBook has an IP KVM and an external 10G Ethernet NIC; cabling is four cables per laptop and forty-eight per shelf, plus twelve for Ethernet.
FileVault was the unexpected pain: both the KVM password prompt and the remote SSH unlock expire after 5 minutes; fdesetup authrestart keeps the disk unlocked across a reboot.
Apple allows only two macOS VMs per physical Mac, so Namespace offers 6 or 12 core instances on 14-core Minis and 8 or 16 core instances on 18-core MacBooks.
Guest networking runs through a gVisor-based userspace stack that processes every packet, reaching 4 Gbps upstream per Fast.com, below line rate.

Why it matters

Anything that builds or tests an iOS app needs a Mac, so Apple's hardware cadence and supply become a constraint for CI providers. The post shows what that costs in practice: a six-month wait for Minis, uneven CPU refreshes, and a workaround of laptops in datacenter racks. It is also a rare detailed look at how a provider runs macOS VMs at scale on Apple's Virtualization framework, including the two-VM-per-Mac cap and the networking trade-offs that follow.

Who it affects

Teams that build and test iOS apps in CI, and anyone running coding agents that need Xcode and the iOS Simulator. It also concerns operators of Mac fleets, who face the same limits on remote management, FileVault unlocking, VM counts and image sizes.

How to use it

Practical tips from the post: reboot a Mac with fdesetup authrestart to keep its disk unlocked; if an external USB NIC shows no link, delete and recreate the network service in macOS settings; expect to size VMs in halves because of the two-VM limit. The post describes Namespace's own platform and gives no pricing or customer details.

How solid is it

This is a first-party engineering account by Namespace, and the author is not named in the text. The specifics (cable counts, 5 minute timeouts, instance sizes, the Apple VM limit) are stated plainly. The 4 Gbps figure is measured with Fast.com. The 500 GB and 2 TB image sizes are an illustrative scenario, not fleet measurements. The text available ends partway through the VM-image section, so image build and distribution details are not covered here.

Risks and caveats

The author admits Mac Mini would be the better datacenter machine and that laptops bring their own problems: GUI-only maintenance, FileVault races, a USB NIC bug and fragile HDMI cables. Networking is still below line rate, and the IPC-free alternative is not productionized. The arrival of M5 and M6 Minis and Studios is described only as coming soon. The number of machines is given only as hundreds.

“Because our customers need Macs. And because Apple didn’t give us another option.”

— Namespace blog post, Mac at any scale