Running a Mac CI farm on dedicated Mac minis

The only number that matters is how many builds must run at the same time during your busiest hour. Not developers, not repositories: concurrent builds.

A rough shape that holds for most iOS teams:

Queue time is the signal. If builds wait more than a couple of minutes at peak, add a machine. It is cheaper than the hour every developer spends waiting.

Each Mac mini runs the whole machine for you: no hypervisor, no noisy neighbour. That gives you two valid patterns.

Cleanest. A build gets the entire CPU, GPU and memory. Use this for Xcode builds and UI tests, where a build will happily eat every core you give it.

Works when your jobs are small and I/O-bound: unit tests, linting, packaging. On a 32 GB M4 or M6, two parallel light jobs are comfortable.

Mixing both is normal: heavy machines dedicated to release builds, lighter machines packed with fast jobs.

Label your machines and let the pipeline route to them. The useful splits:

ios-app, sdk, internal-tools. Each repository targets its own label, so a broken build on one product never blocks another.

pr machines that are fast and always warm, release machines that get wiped before every signed build.

Agencies give each client their own machines with their own credentials and certificates. Nothing shared, nothing to leak between accounts.

All of it on one MacDuty account, with one invoice at the end of the month.

A Mac that has been building for a year accumulates Xcode versions, simulators and caches. Ask us for a clean reinstall when you rotate a machine to a new project.

Same Xcode version across every machine in a pool, upgraded deliberately. A farm where machines drift produces builds that pass on one runner and fail on another.

CPU graphs on build machines are always alarming and rarely actionable. Queue wait time tells you when to add hardware.

At ten machines, one being down should be an inconvenience, not an incident.

Orchestration platforms layer Kubernetes-style scheduling over virtualized macOS, and you pay for that layer. It is genuinely useful if you need ephemeral VMs spun up per job at large scale.

Most teams under twenty machines do not. They need a handful of fast, dedicated Macs that stay up, keep their caches warm, and cost the same amount every month. That is what a dedicated farm is: whole physical machines at a flat price, with the build cache still there for the next job instead of being thrown away with the VM.

You also get the difference that shows up at 2 a.m. before a release: the people who run the racks answer the email.

Tell us the shape: how many machines, which models, what has to be installed on them. They arrive configured with your Xcode version, runner agent, keys and certificates, and we handle reinstalls and fleet changes as you go.