In Part 1 I laid out the Jenkins-as-a-Code setup — JCasC, Job DSL, ephemeral workers, Packer images, all of it. And I said macOS workers were their own special kind of hell that deserved a separate post. This is that post.

If you've never had to run macOS builds in CI, the short version is: everything that's easy on Linux is hard on macOS, and everything that's hard on Linux is also hard on macOS but in a different way. Apple's licensing rules, the fact that you can't just spin up a Mac in AWS the same way you spin up Ubuntu, the keychain weirdness, the signing tooling, the Xcode versions — all of it adds up. And the answer at most companies is "we have a few Mac minis under someone's desk that everybody SSHes into". Which works until it doesn't.

I wanted the same story I had for Linux and Windows — born for one build, destroyed after, byte-identical state every time — but on macOS. Took me a while to get there. Here's what actually worked.

Why macOS is hard in the first place

Before getting into solutions, it helps to name the problems, because they explain why the architecture ends up looking weird.

1. The cloud Mac story is awkward. EC2 Mac instances do exist. They're real Mac hardware living in AWS data centers, and you can absolutely rent one. The catch is the shape: they're dedicated hosts with a 24-hour minimum allocation (Apple's licensing requirement, not AWS being weird), and the per-hour pricing is brutal compared to Linux. For ephemeral workers that live for 30 minutes per build, paying for 24 hours per allocation makes the per-build economics painful. Cloud Mac exists; it's just shaped wrong for high-volume ephemeral CI.

2. Apple's EULA only allows macOS to run on Apple hardware. Which means: no, you cannot legally virtualize macOS on a Linux box. You need real Mac hardware somewhere in the loop. Either you own it, you rent it, or you use a provider that owns it for you.

3. macOS virtualization is its own ecosystem. On Intel Macs the answer used to be VMware (vSphere or Fusion) or VirtualBox. On Apple Silicon, neither of those works the same way — Apple's Virtualization.framework is what everything is built on top of now, and the tooling around it is much younger.

4. Signing and notarization need credentials that don't love being ephemeral. Apple Developer ID certificates, app-specific passwords, the keychain — none of these were designed with "fresh VM every build" in mind. They were designed for "a developer's laptop". Making them work in CI is a whole sub-problem.

5. macOS images are huge. A baked Packer image with Xcode is 60–80 GB. Spinning that up from cold storage is slow. Caching matters way more than it does for Linux.

Once you understand those five things, the architecture choices below stop looking weird.

What I evaluated and didn't pick

The macOS CI space is small enough that I can name everything serious in it. Before settling on the approaches below, I did a real evaluation of the commercial options — they exist for a reason, they're not bad, they just didn't fit our cost shape.

• Veertu Anka — the most mature paid platform specifically for macOS CI virtualization. Does roughly what Tart does, with a polished management UI, enterprise support, and a richer feature set. Licensing is per-host or per-VM, and at fleet sizes that matter for a growing engineering org it adds up quickly. If you have the budget and want vendor support, it's a credible choice.
• MacStadium — a managed-Mac hosting provider. You rent physical Macs in their data center, optionally bundled with their own orchestration layer (Orka). Solves the "I don't want to rack Macs myself" problem cleanly. Pricing is per-host per-month — makes sense for a large, steady-state fleet, less so if your volume is spiky or you already have Macs you want to use.
• AWS EC2 Mac instances — covered above. Useful for very low-volume work where the operational simplicity wins; bad for high-volume ephemeral CI because of the 24-hour minimum.
• GitHub Actions managed macOS runners — fine for OSS projects and small teams. At any real volume the per-minute pricing gets uncomfortable, and you can't customize the image — which matters as soon as your build needs anything beyond stock Xcode.

The thing that pushed me toward Tart is the licensing, more than the technology. Tart's commercial license is structured so that small-scale and personal use is genuinely free, and the paid tier doesn't scale linearly with fleet size the way per-host licensing does on Anka. For our build volume, that math just works — and at smaller scales (one or two Macs) you pay nothing at all. That's hard to beat.

And as of April 2026 — when Cirrus Labs joined OpenAI — that licensing got even better: Tart, Vetu and Orchard have been relicensed under a more permissive license and the commercial fees were dropped entirely. If you were on the fence before, the math is even simpler now.

The other thing the Cirrus Labs team gets right is the coherent toolchain around Tart. Tart for VMs, Orchard for fleet orchestration, and the Cirrus CLI for running CI tasks locally — the same .cirrus.yml configs that would run on the the Cirrus CLI runs the same YAML task definitions locally against a Tart VM. The local-reproduction story alone has saved me hours of "wait, why does this fail only in CI" debugging. It's one of those toolchains where each piece is useful on its own, but the combination is what makes the whole thing pleasant to live with.

Three ways I ended up provisioning macOS workers

There's no single tool that does everything I needed. So the answer ended up being: three different provisioners for three different shapes of Mac fleet. All three follow the same pattern from Part 1 — a Jenkins job invokes the provisioner, the worker comes up from a Packer-baked image, runs the build, gets destroyed — but the layer underneath is different.

Option A — Tart, for Apple Silicon

Tart is a small open-source CLI built by the Cirrus Labs folks that wraps Apple's Virtualization.framework. You give it an OCI-compatible image (basically a tarball with the macOS VM disk), it spins up a VM on Apple Silicon hardware in seconds. The image is reusable, you can layer on top of it, and it's the closest thing to "docker, but for macOS VMs" that exists today.

How it fits:

• The Mac hardware itself is a fleet of Mac minis (or Mac Studios) — physical machines we own or rent, sitting in a rack.
• Each Mac has Tart installed at the host level.
• A dedicated Jenkins job picks an available host, runs tart clone from a known image tag, runs tart run, registers the new VM as a Jenkins agent, and after the build runs tart delete to clean up.
• Packer has a tart-cli source that builds those images. We bake everything — Xcode, Homebrew, signing tools, languages — into the image at build time.

The good: spin-up is genuinely fast. From tart clone to "agent connected to Jenkins" is under a minute. The image is a snapshot, so every build truly starts from byte-identical state — same as the Linux pod story.

The not-so-good: you still need to own or rent the Mac hardware. You're not escaping the "real Apple machines in a rack" problem; you're just orchestrating them better. And the Tart ecosystem is young — expect to write some glue.

Option B — vSphere / VCSA, for the older Intel fleet

Before Apple Silicon, the Mac fleet was a stack of Intel Mac minis hooked into a vSphere cluster. macOS VMs were managed as ESXi guests, exactly like any other VMware VM.

How it fits:

• Each Mac mini runs ESXi (which is the one OS allowed to be installed on a Mac and host macOS guests, per Apple's licensing).
• A "golden" macOS VM template lives in vSphere, baked by Packer's vSphere ISO builder.
• A dedicated Jenkins job runs Terraform with the vSphere provider to clone the template (linked clones are faster), bring up the VM, configure it as an agent, and tear it down after.

This setup predates the Apple Silicon transition and it still works — but it's the heaviest of the three. Linked clones speed up the spawn time, but it's still slower than Tart, and vSphere itself is a chunky thing to operate.

I'd describe this as the "responsible enterprise" path. If you already have VMware in your org, it slots in cleanly. If you don't, you'd never start here in 2026.

Option C — Orchard, for pooled / remote Macs

Orchard is also from Cirrus Labs — same family as Tart. The pitch is: instead of you orchestrating individual Mac hosts, Orchard runs as a controller that manages a pool of Mac workers, and you ask it for a VM via an API. It handles scheduling, queuing, and lifecycle.

How it fits:

• Useful when you have a pool of Macs (could be your own, could be from a managed provider like MacStadium or a similar cloud-Mac vendor), and you don't want each Jenkins job to know which physical machine to pick.
• A dedicated Jenkins job calls Orchard's API to request a VM with a specific image and resource profile, gets a VM back, runs the build, releases it.
• Useful when capacity is the constraint. You can have 20 builds queued and 5 Macs available, and Orchard does the scheduling for you.

The good: clean separation of concerns. The Jenkins job doesn't care where the Mac is physically.

The not-so-good: another piece of infrastructure to run. Worth it only at a certain fleet size — for a tiny pool of 2–3 Macs, raw Tart is simpler.

What gets baked into the Packer image

Same story as Linux and Windows — we bake everything we can into the image, so the build itself doesn't pay setup time. The macOS Packer image is the heaviest one in the fleet by a wide margin.

What goes into a typical macOS worker image:

• OS: a specific macOS version (we pin to specific point releases — Xcode compatibility is brittle, you don't want to be on "whatever's latest").
• Xcode: a specific Xcode version, plus the command line tools. Xcode alone is 30+ GB.
• Homebrew + packages: all the brewed tools the build needs, pre-installed and pre-warmed.
• Language runtimes: Node, Python, Ruby — pinned to specific versions matching what production uses.
• Build tools: CMake, Ninja, Conan, whatever the project uses.
• Signing tools: codesign, notarytool, xcrun — these come with Xcode but worth confirming they're available.
• Pre-warmed caches: Conan cache, npm cache, brew cache — anything that would otherwise need to be downloaded on first build.

The Packer template itself is short — most of the heavy lifting is in a chain of shell scripts that run after the base macOS install:

source "tart-cli" "macos" {
  vm_base_name = "ghcr.io/cirruslabs/macos-monterey-base:latest"
  vm_name      = "macos-ci-${var.image_version}"
  cpu_count    = 4
  memory_gb    = 8
  disk_size_gb = 120
  ssh_username = "admin"
  ssh_password = "admin"
}

build {
  sources = ["source.tart-cli.macos"]

  provisioner "shell" {
    scripts = [
      "scripts/post-install.sh",
      "scripts/brew-setup.sh",
      "scripts/xcode.sh",
      "scripts/nodejs-setup.sh",
      "scripts/deps.sh",
      "scripts/prewarm-caches.sh",
    ]
  }
}

The whole template is maybe 30 lines. The interesting stuff lives in the shell scripts, which are versioned in the same repo and reviewed in the same PRs as everything else.

A baked image is around 60–80 GB. Storage matters. So does the cache locality — if every Mac in the fleet has to pull a fresh 70 GB image from the registry over the network on first use, you've got problems. We pre-cache base images on each host out of band.

The signing-on-ephemeral-VMs problem

This is the one part of the macOS story that genuinely deserves its own section, because it's where most of the time disappears when you first set this up.

Apple's signing pipeline assumes a developer machine with a persistent keychain. You unlock your keychain once, you sign apps for the rest of the day, life is good. In CI with ephemeral VMs, none of that holds. Each VM is brand new. There's no pre-existing keychain. There's no unlocked state. There's no "saved password".

Here's the contract we ended up with — generic enough that it'll work for most teams:

1. Apple Developer ID certificate + private key live in a secrets manager (AWS Secrets Manager, Vault, whatever you use). Never in the image. Never in git.
2. At job start, the Jenkins pipeline pulls the certificate + key from the secrets manager and imports them into a temporary keychain it creates on the VM.
3. The temporary keychain gets a random password generated for that build, used for the duration of the build, and discarded with the VM.
4. Notarization credentials (app-specific password or notarytool API key) come from the same secrets manager and are used directly — they don't need a keychain.
5. When the build finishes and the VM dies, the keychain dies with it. Same lifecycle as the rest of the worker.

A simplified version of the keychain-bootstrap script looks like this:

#!/usr/bin/env bash
set -euo pipefail

KEYCHAIN="ci-build.keychain"
KEYCHAIN_PASSWORD="$(openssl rand -base64 24)"

# Create a brand-new keychain just for this build.
security create-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
security set-keychain-settings -lut 21600 "$KEYCHAIN"
security unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"

# Add it to the search list so codesign can find it.
security list-keychains -d user -s "$KEYCHAIN" $(security list-keychains -d user | tr -d '"')

# Import the cert + key from the secrets-manager-provided files.
security import "$DEVELOPER_ID_CERT" -k "$KEYCHAIN" -P "$CERT_PASSWORD" -T /usr/bin/codesign

# Grant codesign permission to use the key without prompting.
security set-key-partition-list -S apple-tool:,apple: -s -k "$KEYCHAIN_PASSWORD" "$KEYCHAIN" >/dev/null

Things that will bite you if you don't know them:

• set-key-partition-list is mandatory on modern macOS. Without it, codesign prompts for a password from the UI and the build hangs forever.
• The keychain must be in the search list. A keychain that exists but isn't searched is invisible to codesign.
• Notarization is async. notarytool submit --wait does block until done, but be ready for it to take several minutes. Plan for it in build timeouts.
• Stapling fails silently if you forget it. Notarization succeeds, the artifact ships, end users get a Gatekeeper warning anyway because the ticket isn't stapled. xcrun stapler staple <artifact> after notarization succeeds.

It's not deep magic, but every team I've seen do macOS CI for the first time burns a week on this. So: budget for that week, and write the keychain bootstrap script before you write the rest of the pipeline.

Trade-offs — which one should you pick?

Honest answer: probably more than one, depending on what fleet you've inherited. But if I were starting from a blank slate today, in 2026:

The thing I'd push back on is "let's just use Mac minis under someone's desk". That's fine for one team. It's not fine when it's the bottleneck for every iOS release.

What I'm still figuring out

A few open problems I haven't fully solved:

• Image freshness. Xcode updates land every few weeks. Keeping the Packer image current without breaking everyone's builds is a constant low-grade tax. We rebuild images on a schedule and pin every job to a specific image version, but the rebuild itself is a 90-minute job and it's not free.
• Cost. Mac hardware is expensive whether you own it or rent it. The economics only work above a certain build volume; below that, the per-build cost is uncomfortable.
• Apple Silicon transition for older code. Some of our older C++ code still has Intel-only dependencies that haven't been ported. We run those builds on the vSphere/Intel fleet, but that fleet is shrinking, and "rewrite all the legacy build deps for arm64" is its own project.
• Notarization queue times. Apple's notarization service has occasional bad days where submissions take 20+ minutes. There's nothing we can do about it on our side, but it does mean macOS builds have a longer tail than the others.

Closing thought

The macOS CI story doesn't have a single right answer. There's no equivalent of "just run a pod in EKS". You're going to end up with physical hardware in the loop, a hypervisor (probably more than one), and a signing problem that doesn't exist on any other platform. The trick is to treat it the same way as everything else: ephemeral, image-baked, orchestrated by a job in git, secrets from a vault. Once the contract is the same as Linux and Windows, the macOS hell becomes a tractable hell.

Next up — Part 3, where I'll talk about running spot instances as GitHub Actions runners and the cost story behind moving some of this work off Jenkins entirely. Different model, different trade-offs, similar headaches.

Appendix — tools mentioned in this post

Cirrus Labs toolchain (the one I ended up on)

• Tart — macOS VMs on Apple Silicon via Virtualization.framework. Free for small-scale; licensing.
• Orchard — controller for pooled Tart hosts.
• Cirrus CLI — run CI tasks locally against a Tart VM; same .cirrus.yml as Cirrus CI's SaaS.
• Packer Tart plugin — Packer builder for Tart images.

Commercial alternatives I evaluated

• Veertu Anka — paid platform for macOS CI virtualization, polished, enterprise support.
• MacStadium — managed Mac hosting + optional Orka orchestration.
• AWS EC2 Mac instances — real Apple hardware in AWS, 24-hour minimum allocation.
• GitHub-hosted macOS runners — fine for OSS / small scale.

Other

• vSphere and the Terraform vSphere provider — for the older Intel fleet.
• HashiCorp Packer — bakes all the worker images.
• Apple's notarytool — the modern notarization CLI.

This is Part 2 of My CI/CD Odyssey. If you want to be pinged when Part 3 drops, follow me here on dev.to. And if you're doing macOS CI differently — I'd love to hear about it in the comments.