Guide

Migrating from Cirrus Runners to a dedicated Mac mini

Cirrus Runners takes no new customers and existing contracts are running out. Move your macOS GitHub Actions jobs to a dedicated Mac mini, natively or with the same Tart images.

60 minutes, updated 2026-09-15

In April 2026 Cirrus Labs announced it was joining OpenAI. Cirrus CI stopped running jobs on 1 June 2026. Cirrus Runners takes no new customers, and existing customers are supported only until their current contract ends.

If your macOS GitHub Actions jobs run on Cirrus Runners, they need a new home before that date. This guide shows two ways to move them to a dedicated Mac mini, and how to pick between them.

Two ways to move

Path A, a native runner. The GitHub Actions runner runs directly on macOS. It is the simplest setup, with the fastest builds and caches that stay warm between jobs.

Path B, Tart virtual machines. You run the same Cirrus macOS images you use today, inside Tart, on your own Mac. Every job starts from a clean machine, exactly as on Cirrus.

Path A, native runner

Fastest, and you install Xcode yourself.

Path B, Tart virtual machines

Nothing changes in the workflow except the label.

One Mac, two arrangements. The choice is the whole guide.

	Native runner	Tart VMs
Setup time	About 30 minutes	About an hour
Same environment as Cirrus	No, you install Xcode yourself	Yes, same images
Clean machine per job	No	Yes
Warm caches between jobs	Yes	No, unless you build them into the image
Jobs at once per Mac	One per runner	Up to two (Apple's licence limit)

Choose A if your team owns the repository and wants speed. Choose B if you need every build to start from a known, clean state, or you want to change nothing in your workflows except the label.

Before you start

List what your workflows use today. Look for the runs-on lines that point at Cirrus images, for example:

.github/workflows

runs-on: ghcr.io/cirruslabs/macos-runner:sonoma

Note the macOS version, the Xcode versions and anything your jobs install at the start. You will need that list for either path.

Path A: native runner

Follow our guide, Self-hosted GitHub Actions runner on a Mac mini, linked at the foot of this page. It covers Xcode, registering the runner and running it as a service.

Give the runner a label that describes it, such as macduty-m4. Then change one line in each workflow:

.github/workflows

# before
runs-on: ghcr.io/cirruslabs/macos-runner:sonoma

# after
runs-on: [self-hosted, macOS, ARM64, macduty-m4]

Run one workflow on the new runner while Cirrus still works. When it passes, move the rest.

Path B: the same images, in Tart

1. Install Tart on the Mac

ssh

brew install cirruslabs/cli/tart

2. Pull a Cirrus image

Pick the image closest to what you run today. Cirrus publishes images with and without Xcode:

ssh

tart clone ghcr.io/cirruslabs/macos-sequoia-xcode:latest ci-base

The first pull is large, often over 50 GB, so allow some time.

3. Start the VM and log in

ssh

tart run --no-graphics ci-base &
ssh admin@$(tart ip ci-base)

The Cirrus images come with a default admin account. Change its password before you do anything else.

4. Register the runner inside the VM

Inside the VM, register a GitHub Actions runner the same way as in Path A, with one difference: add --ephemeral, so the runner takes a single job and then stops.

inside the VM

./config.sh --url https://github.com/<owner>/<repo> --token <token> --ephemeral --labels tart-sequoia
./run.sh

5. A fresh VM for every job

On the Mac itself, a small loop clones a clean copy of the image, runs one job in it and deletes it:

ssh

while true; do
  tart clone ci-base job
  tart run --no-graphics job &
  # wait for the job to finish, then:
  tart stop job
  tart delete job
done

In practice you will want a script that also fetches a fresh registration token for each VM. Tools such as Orchard, from the same team, handle this for larger setups.

Apple's licence allows at most two macOS virtual machines running at the same time on one Mac. For more jobs in parallel, add another Mac.

After the move

Check build times. On a dedicated M4 or newer, most teams see builds as fast as on Cirrus, and faster with warm caches.
Keep the old workflows for a week. Leave a copy of the Cirrus runs-on lines in a branch until the new runners have been through a full release.
Private repositories only. Self-hosted runners should not take jobs from public forks.

Why a dedicated Mac mini

One flat month. No per-minute billing and nothing to renegotiate when a contract ends.
Every generation. M1 to M6 side by side, so you can test on the chips your users have.
Yours alone. No queue, no neighbours, nobody else's jobs on your hardware.
Hosted in the EU, under the GDPR.

MacDuty racks Mac minis from M1 to M6, with macOS installed and your SSH key in place, ready within minutes.