Les équipes qui développent sur Windows ou Linux mais livrent des pipelines iOS / macOS connaissent ce choix en 2026 : continuer à payer les runners macOS hébergés par GitHub (facturation à la minute, environnements éphémères), ou enregistrer un runner auto-hébergé sur un Mac mini M4 dédié à distance (disque persistant, loyer mensuel stable). Cet article traite la seconde voie — les runners macOS GitHub Actions auto-hébergés — et non OpenClaw ni l’exploitation d’agents longue durée. Nous passons en revue l’économie hébergé vs auto-hébergé, six choix de région, la mémoire M4 et les sièges parallèles, DerivedData et le disque, le découpage par labels, un HowTo d’enregistrement, le TCO journalier–mensuel et une FAQ. Comparez les offres sur la page Tarifs Mac mini et les notes Runner / SSH dans le centre d’aide. Pour l’automatisation par agents (hors CI), voir notre guide OpenClaw sur Mac distant — ici, le fil conducteur reste CI/CD.
1) Runners macOS hébergés vs Mac distant auto-hébergé : minutes, files d’attente et quand le bare metal gagne
GitHub facture les runners macOS hébergés à la minute Actions ; tarifs et quotas gratuits sont définis dans la documentation de facturation GitHub (les prix des runners hébergés ont évolué en 2026 — vérifiez les tarifs actuels avant tout budget). Les runners hébergés excellent en zéro exploitation : chaque job repart d’une image propre, ce qui convient aux builds PR occasionnels. En contrepartie, le DerivedData et les caches SwiftPM survivent rarement d’un job à l’autre, les files peuvent gonfler aux heures de pointe, et la facture suit le rythme des releases.
Sur un Mac mini M4 bare metal chez Nuvcloud (ou équivalent), un runner auto-hébergé achète un siège fixe et un SSD persistant : un processus actions-runner supervisé par launchd, avec ~/Library/Developer/Xcode/DerivedData réutilisé entre les PR. Les builds incrémentaux sont souvent plus rapides qu’un job hébergé à froid (l’écart dépend de la taille du dépôt — traitez les chiffres ci-dessous comme des modèles, pas des SLA).
| Voie | Préférable quand | Coût principal |
|---|---|---|
| macOS hébergé GitHub | < quelques centaines de minutes macOS/mois, pas besoin de cache, pas d’envie de gérer une machine. | Minutes + temps de file ; DerivedData ne persiste pas. |
| Mac distant auto-hébergé | Builds quotidiens sur main, plusieurs schémas, chemins Archive / TestFlight rapides. | Mises à jour runner, hygiène disque, mutex de signature ; loyer prévisible. |
| Mac mini au bureau | Site unique, pas de multi-région, vous acceptez alimentation et exposition réseau. | CapEx + énergie + temps admin ; scaler = acheter des boîtes. |
Modèle TCO sur 12 mois (hypothèses d’exemple — substituez vos chiffres) : soit P le prix minute macOS hébergé et M les minutes mensuelles ; coût annuel hébergé ≈ 12 × M × P. Soit R le loyer mensuel (machine + bande passante) ; coût annuel cloud ≈ 12 × R. Quand M × P dépasse R et que vous avez besoin de DerivedData chaud, l’auto-hébergement gagne souvent ; quand M est faible et irrégulier, restez hébergé ou louez à la journée pour valider les workflows avant un engagement mensuel.
Chemin intermédiaire fréquent en 2026 : garder lint et tests unitaires sur des runners Linux hébergés (minutes bon marché) et n’envoyer que xcodebuild, Archive et notarisation vers un seul Mac auto-hébergé. Documentez ce découpage dans le README du workflow pour éviter qu’un refactor ne remette les grosses compilations sur macOS hébergé.
2) Singapour, Japon, Corée, Hong Kong, US Est, US Ouest : placer le runner près de Git, du registry et des artefacts
Nuvcloud propose Singapour, Japon, Corée, Hong Kong en Asie-Pacifique et US Est / US Ouest en Amérique du Nord (confirmez les SKU dans l’assistant Commande). Ne demandez pas « quelle ville est la plus proche de mon appartement » ; demandez où se concentrent vos dépôts Git, registres de conteneurs, services TestFlight/signature et fuseaux d’astreinte. Pages région : Singapour, Japon, Corée, Hong Kong, US Est, US Ouest.
Sur chaque finaliste, lancez le même script : git clone --depth=1, tirer un artefact ~1 Go, comparer xcodebuild -showBuildSettings à froid et à chaud. Le RTT SSH pour les admins est un confort — il ne domine pas le temps mur CI.
Avec proxy d’entreprise ou VPN scindé, mesurez depuis l’hôte runner, pas depuis un portable invité. La politique de sortie (registres autorisés, endpoints Apple, API GitHub) fait partie du choix de région. Consignez les baselines dans une feuille partagée pour les prochains renouvellements matériel.
| Région | Profil typique | Note d’équipe |
|---|---|---|
| Singapour | Builds utilisateurs Asie du Sud-Est, miroirs GitHub APAC, équipes SG/MY. | Arbitrer avec Hong Kong selon l’emplacement du dépôt principal. |
| Japon | Conformité entité JP, collaborateurs Tokyo, releases nocturnes JP. | Adapté au découpage « dev APAC + QA Japon ». |
| Corée | Apps marché KR, origines CDN locales, astreinte Séoul en SSH. | Décider sur le plan de données, pas sur le ping seul. |
| Hong Kong | Équipes mixtes Grande Chine / HK, Git hébergé sud de la Chine. | Bureaux continentaux : souvent meilleur ressenti SSH qu’US Ouest. |
| US Est | Trajets GitHub US Est par défaut, SaaS côte Est, biais cache npm/Actions Est. | Optimiser les routes d’artefacts, pas la distance cartographique. |
| US Ouest | Collaboration Pacifique, miroirs Ouest, builds nocturnes US Pacific. | SSH APAC plus lent possible ; pulls de dépendances parfois plus rapides. |
3) M4 16 Go/256 Go vs 24 Go/512 Go et M4 Pro : sièges concurrents et plafond simulateur
Sur Apple Silicon, un processus actions-runner correspond à une cible runs-on: self-hosted ; le chevauchement de jobs dépend du paramètre de concurrence et des pics RAM Xcode/Simulateur. M4 16 Go convient à une grosse compile ou deux jobs légers ; 24 Go à un Archive + un test UI sur un simulateur ; les paliers M4 Pro visent des matrices multi-simulateur ou de gros monorepos.
| Config | Jobs concurrents suggérés (règles empiriques) | Signaux OOM / blocage |
|---|---|---|
| M4 16 Go / 256 Go | 1× xcodebuild complet, ou 2× lint/unitaires seuls. |
memory_pressure souvent Yellow ; Simulateur ne démarre pas. |
| M4 24 Go / 512 Go | 1× Archive + 1× test UI, ou 2× compiles moyennes avec racines DerivedData séparées. | Tests UI parallèles chargent WindowServer ; swap dégrade la latence. |
| M4 Pro (palier supérieur) | Matrice multi-OS simulateur ; deux versions mineures Xcode installées. | Plafond IOPS disque avant CPU sur d’énormes arbres DerivedData. |
Dans les workflows, préférez runs-on: [self-hosted, macOS, compile] vs runs-on: [self-hosted, macOS, ui-test] plutôt que de monter la concurrence sur une seule machine.
Le paramètre concurrency du runner à 2 sur un hôte 16 Go est une voie fréquente vers l’OOM lors de lancements Simulateur simultanés. Partez de 1 pour les pipelines Archive, mesurez la mémoire résidente de pointe sur votre plus gros schéma, puis augmentez seulement si memory_pressure reste Normal une semaine de release complète.
4) Extensions 1 To/2 To et DerivedData : worktrees parallèles, rétention et règles de vidage
Les jobs hébergés repartent propres — le DerivedData ne s’accumule pas. Les runners auto-hébergés gagnent quand ~/Library/Developer/Xcode/DerivedData survit aux PR. Pour des jobs parallèles, ne partagez jamais un même répertoire DerivedData : fixez DERIVED_DATA_PATH (ou -derivedDataPath) par job et utilisez des worktrees Git si besoin.
- Sur disque : DerivedData, cache SwiftPM, arbres CocoaPods si versions épinglées.
- Mieux en cache Actions : archives toolchain reproductibles, caches lint, grosses dépendances téléchargeables.
- Alertes : sous 20 % d’espace libre, LRU sur les 30 % DerivedData les plus anciens ; sous 10 , drainer le runner (pas de nouveaux jobs).
| Disque | Usage CI typique | Upgrader quand |
|---|---|---|
| 256 Go–512 Go de base | Un Xcode + DerivedData d’un dépôt ; purger les Archives régulièrement. | DerivedData mono-repo >40 Go ou deux versions Xcode requises. |
| 1 To | 2–3 caches de branches actives + runtimes simulateur ; deux worktrees parallèles. | Matrice nightly complète sur monorepo. |
| 2 To | Plusieurs mineures Xcode, archives de symboles, gros caches binaires SPM. | Vous refusez de rm -rf DerivedData entre chaque job. |
5) Capacité parallèle : labels multi-Mac, shards et montée journalière → mensuelle
Quand une machine atteint le plafond mémoire, ajoutez un deuxième Mac distant et sharder par label :
mac-ci-compile—xcodebuild builduniquement ; DerivedData chaud.mac-ci-archive— signature et upload ;concurrencyworkflow pour éviter deux jobs sur le trousseau.mac-ci-ui— tests simulateur sur la boîte 24 Go ou Pro.
Parcours : location journalière pour prouver les workflows → hebdomadaire pour durcir la politique de cache → mensuelle pour IP et identité runner stables → machines supplémentaires pour le shard. actions/cache peut encore partager des blobs reproductibles ; DerivedData reste local par hôte.
Alignez les dimensions matrix sur les labels plutôt que de surcharger un runner. Documentez quels secrets existent sur quel label pour que les PR depuis des forks n’attendent pas des identifiants de signature absents sur la machine d’archive.
6) HowTo : enregistrer un runner auto-hébergé sur le Mac distant
Suivez le guide GitHub : ajouter un runner auto-hébergé (les jetons UI peuvent changer selon la version). Sur votre hôte Nuvcloud :
- Connexion SSH ; installer Xcode CLT / Xcode cible ; accepter les licences.
- Créer un utilisateur Unix dédié ou un répertoire
actions-runner— ne signez pas d’IPA de prod avec un Apple ID personnel sur ce compte. - Depuis Paramètres du dépôt → Actions → Runners, exécuter
config.sh; ajouter des labelsmacos,m4, code région. - Installer en service (
svc.sh installvialaunchd) pour que les jobs survivent à la déconnexion SSH. - Dans les workflows, définir
DERIVED_DATA_PATH; ajouterconcurrency: { group: codesign, cancel-in-progress: false }sur les jobs de signature.
env:
DERIVED_DATA_PATH: ${{ github.workspace }}/DerivedData/${{ github.run_id }}
RUNNER_TOOL_CACHE: /Users/runner/actions-toolcache
xcodebuild \
-scheme "YourApp" \
-derivedDataPath "$DERIVED_DATA_PATH" \
build
7) TCO journalier, hebdomadaire et mensuel — et quand redimensionner
Séparez la dépense « expérimentation » de la dépense « runner de production » :
| Durée | Idéal pour | Précautions CI |
|---|---|---|
| Journalier | A/B sur six régions, prouver le gain DerivedData, essai d’enregistrement runner. | Exporter notes de signature et inventaire cache avant teardown ; pas de secrets prod sur hôtes éphémères. |
| Hebdomadaire | Crunch release, migration workflows hors macOS hébergé, charge-test avant deuxième machine. | Geler le patch Xcode ; journaliser les minutes économisées vs hébergé. |
| Mensuel | Builds quotidiens sur main, nom runner fixe, listes blanches IP, politique cache stable. | Planifier upgrades : 16→24 Go, extension disque, second shard label. |
Comparaison grossière sur 36 mois (exemple) : Mac mini possédé + énergie + temps admin = C_cap ; loyer cloud = 36 × R. Les équipes sans admin Mac dédié sous-estiment souvent C_cap. En comparant les minutes hébergées, intégrez le coût d’opportunité des files, pas seulement le prix affiché.
Choisissez SKU et durée sur la page Tarifs Mac mini ; renouvelez et redimensionnez dans le tableau de bord. Plus d’articles dans l’index du blog.
8) FAQ
Q1 : L’auto-hébergement est-il autorisé par les conditions GitHub ?
Oui sur du matériel que vous possédez ou louez ; ne revendez pas la capacité runner à des tiers sans lien (voir Conditions GitHub).
Q2 : Peut-on mélanger hébergé et auto-hébergé macOS ?
Oui — ex. PR sur hébergé, main sur auto-hébergé. Branchez les workflows quand secrets/signature n’existent que sur votre Mac.
Q3 : Quand purger DerivedData ?
Après upgrade Xcode, coupes de branche majeures, ou disque <20 % libre — LRU, pas rm -rf pendant des jobs actifs.
Q4 : La déconnexion SSH arrête-t-elle le job ?
Non — les jobs tournent sous le service runner. Utilisez launchd ; SSH est pour vous, pas pour le worker.
Q5 : Que devient le cache en changeant de région ?
DerivedData est local au chemin ; migration = réchauffement. Utilisez le cache Actions pour SPM/outillage, puis une compile complète.
Q6 : Combien de simulateurs sur 16 Go ?
Évitez plusieurs tests UI lourds en parallèle — routez vers un runner mac-ci-ui.
Q7 : Pourquoi sérialiser la signature ?
Déverrouillages trousseau parallèles et Archives dupliquées peuvent verrouiller certificats ou écraser des IPA — concurrency sur l’étape signature.
Q8 : Comment décommissionner un hôte journalier en sécurité ?
Retirez le runner dans GitHub, faites tourner jetons d’enregistrement/PAT, effacez trousseau et clés ~/.ssh temporaires après vérification des dépendances.
Sur un Mac mini cloud, la CI reste chaude et la facture prévisible
Un runner macOS GitHub Actions auto-hébergé, c’est du DerivedData persistant, un loyer mensuel prévisible et une capacité dédiée multi-régions que vous contrôlez. Les hôtes Mac mini M4 bare metal Nuvcloud offrent l’outillage Unix natif, les bases Gatekeeper/SIP/FileVault et une enveloppe énergétique adaptée aux builds sans surveillance — de l’essai journalier par région à une flotte mensuelle, avec 24 Go, SSD plus grands ou une deuxième machine pour le shard par labels quand les pipelines grandissent.
Si vous quittez des minutes macOS hébergées volatiles, le Mac mini M4 cloud Nuvcloud est un excellent point de départ — découvrir les offres et régions pour choisir nœud, mémoire et stratégie de cache une fois pour toutes, pas à chaque release.