Guide
Migrer de Cirrus Runners vers un Mac mini dédié
Cirrus Runners ne prend plus de nouveaux clients et les contrats existants arrivent à échéance. Migrez vos jobs GitHub Actions macOS vers un Mac mini dédié, en natif ou avec les mêmes images Tart.
60 minutes, mis à jour le 2026-09-15
En avril 2026, Cirrus Labs a annoncé rejoindre OpenAI. Cirrus CI a cessé d'exécuter des jobs le 1er juin 2026. Cirrus Runners ne prend plus de nouveaux clients, et les clients existants ne sont pris en charge que jusqu'à la fin de leur contrat en cours.
Si vos jobs GitHub Actions macOS tournent sur Cirrus Runners, il leur faut un nouvel hébergement avant cette date. Ce guide présente deux façons de les migrer vers un Mac mini dédié, et comment choisir entre les deux.
Deux façons de migrer
Option A, un runner natif. Le runner GitHub Actions tourne directement sur macOS. C'est la configuration la plus simple, avec les builds les plus rapides et des caches qui restent chauds entre les jobs.
Option B, des machines virtuelles Tart. Vous faites tourner les mêmes images macOS Cirrus qu'aujourd'hui, dans Tart, sur votre propre Mac. Chaque job démarre sur une machine propre, exactement comme sur Cirrus.
Path A, native runner
Fastest, and you install Xcode yourself.
Path B, Tart virtual machines
Nothing changes in the workflow except the label.
| Runner natif | VM Tart | |
|---|---|---|
| Temps de mise en place | Environ 30 minutes | Environ une heure |
| Même environnement que Cirrus | Non, vous installez Xcode vous-même | Oui, mêmes images |
| Machine propre pour chaque job | No | Oui |
| Caches chauds entre les jobs | Oui | Non, sauf si vous les intégrez à l'image |
| Jobs simultanés par Mac | Un par runner | Jusqu'à deux (limite de la licence Apple) |
Choisissez A si votre équipe possède le dépôt et veut de la vitesse. Choisissez B s'il faut que chaque build parte d'un état propre et connu, ou si vous ne voulez rien changer à vos workflows à part le label.
Avant de commencer
Listez ce qu'utilisent vos workflows aujourd'hui. Cherchez les lignes runs-on qui pointent vers des images Cirrus, par exemple :
runs-on: ghcr.io/cirruslabs/macos-runner:sonomaNotez la version de macOS, les versions d'Xcode et tout ce que vos jobs installent au démarrage. Vous aurez besoin de cette liste quelle que soit l'option.
Option A : runner natif
Suivez notre guide, Runner GitHub Actions auto-hébergé sur un Mac mini, en lien au bas de cette page. Il couvre Xcode, l'enregistrement du runner et son exécution en tant que service.
Donnez au runner un label qui le décrit, par exemple macduty-m4. Puis changez une ligne dans chaque workflow :
# before
runs-on: ghcr.io/cirruslabs/macos-runner:sonoma
# after
runs-on: [self-hosted, macOS, ARM64, macduty-m4]Lancez un workflow sur le nouveau runner tant que Cirrus fonctionne encore. Quand il passe, migrez le reste.
Option B : les mêmes images, dans Tart
1. Installez Tart sur le Mac
brew install cirruslabs/cli/tart2. Récupérez une image Cirrus
Choisissez l'image la plus proche de ce que vous utilisez aujourd'hui. Cirrus publie des images avec et sans Xcode :
tart clone ghcr.io/cirruslabs/macos-sequoia-xcode:latest ci-baseLe premier pull est volumineux, souvent plus de 50 GB, prévoyez donc un peu de temps.
3. Démarrez la VM et connectez-vous
tart run --no-graphics ci-base &
ssh admin@$(tart ip ci-base)Les images Cirrus sont fournies avec un compte administrateur par défaut. Changez son mot de passe avant toute autre chose.
4. Enregistrez le runner dans la VM
Dans la VM, enregistrez un runner GitHub Actions comme dans l'option A, à une différence près : ajoutez --ephemeral, pour que le runner prenne un seul job puis s'arrête.
./config.sh --url https://github.com/<owner>/<repo> --token <token> --ephemeral --labels tart-sequoia
./run.sh5. Une VM neuve pour chaque job
Sur le Mac lui-même, une petite boucle clone une copie propre de l'image, y exécute un job puis la supprime :
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
doneEn pratique, vous voudrez un script qui récupère aussi un nouveau jeton d'enregistrement pour chaque VM. Des outils comme Orchard, de la même équipe, s'en chargent pour les installations plus grandes.
La licence Apple autorise au plus deux machines virtuelles macOS en même temps sur un Mac. Pour plus de jobs en parallèle, ajoutez un autre Mac.
Après la migration
- Vérifiez les temps de build. Sur un M4 dédié ou plus récent, la plupart des équipes ont des builds aussi rapides que sur Cirrus, et plus rapides avec des caches chauds.
- Gardez les anciens workflows une semaine. Conservez une copie des lignes runs-on Cirrus dans une branche jusqu'à ce que les nouveaux runners aient passé une release complète.
- Dépôts privés uniquement. Les runners auto-hébergés ne doivent pas prendre de jobs venant de forks publics.
Pourquoi un Mac mini dédié
- Un forfait mensuel fixe. Pas de facturation à la minute, rien à renégocier quand un contrat arrive à échéance.
- Toutes les générations. Du M1 au M6 côte à côte, pour tester sur les puces qu'ont vos utilisateurs.
- Rien qu'à vous. Pas de file d'attente, pas de voisins, aucune tâche d'un autre sur votre matériel.
- Hébergé dans l'UE, soumis au RGPD.
MacDuty héberge en baie des Mac mini du M1 au M6, macOS installé, prêts en quelques minutes. Ajoutez votre clé SSH depuis l'espace client.
En stock aujourd'hui
Ceux-ci sont en baie maintenant. Choisissez-en un, voyez ce qu'il comprend, et créez votre compte seulement au moment de commander.
Vérification des baies
Un Mac mini à vous
Choisissez une configuration. Si elle n'est pas disponible, laissez votre e-mail et nous vous écrivons le jour où elle est en baie.
À l'année : au moins 19 % de moins qu'au mois
À suivre