2026 : cinq régions, runners GitHub Actions macOS auto-hébergés
files Xcode, disque, M4 16/256 · 24/512 · Pro 64/2 To, 1–2 To et parallèle

Rédaction kvmmac 2026-04-30 9 min

Quitter les minutes GitHub hébergées pour des runners macOS auto-hébergés, ce n’est presque jamais un problème d’installation d’agent : c’est tenir des files de compilation Xcode lisibles pendant que le gonflement disque transforme chaque job en crawl d’E/S.

Sur Singapour, Tokyo, Séoul, Hong Kong et US Est, les petites équipes release gagnent avec une flotte étiquetée par job plutôt qu’un seul héros surdimensionné. Voici comment répartir M4 16/256, M4 24/512 et M4 Pro 64/2 To, acheter 1–2 To au bon moment, puis du parallèle seulement si la file Actions le justifie.

Étiquetez par profil de job (lint, unitaires, archive, UI), pas par personne : la file et l’espace disque prédisent le coût mieux qu’un pic CPU isolé.

ICe que les Actions auto-hébergées changent à la facture

GitHub orchestre, mais vous possédez disque, Xcode et nettoyage. Un runner mêlé archives et caches peut sembler « CPU OK » tandis que DerivedData ronge le SSD ; sur cinq fuseaux, alignez aussi miroirs et caches, sinon le réseau mange le gain de silicium.

Ouvrez une voie de base par métro utile, puis ajoutez des voies quand Queued domine le temps mural — pas pour flatter un poste bureau.

IIRépartir M4 16/256, M4 24/512 et M4 Pro 64/2 To

Table de routage pour runs-on : paliers chers pour jobs lourds, paliers modestes pour le reste.

Palier Idéal pour Points de vigilance Quand monter
M4 · 16/256 SPM, lint, unitaires, builds simples sans écran 256 Go : deux trains Xcode + caches Pods/Tuist remplissent vite File sur ce label, CPU idle : suspect disque
M4 · 24/512 Debug interactif, petites grilles Simulateur, intégration légère UI + archives sur un seul hôte = sursouscription OOM ou fermetures Simulateur en rafale
M4 Pro · 64/2 To Archives parallèles, gros modules, matrices UI Coûteux s’il sert de runner par défaut à tout Après disque/files OK, CPU+RAM toujours pleins

Pour durée de bail, stockage et parallélisme d’équipe sur les mêmes métros, intégrez l’économie des runners au même tableur que le reste du Mac distant. En savoir plus : acheter ou louer un Mac distant sur cinq régions — M4, M4 Pro, extension et parallèle

IIIExtension 1 To contre 2 To sous Xcode qui enfle

La pression disque se lit d’abord en étapes lentes, avant le CPU. Deux trains Xcode, DerivedData et caches mangent 256 Go vite ; 1 To est souvent le meilleur rapport temps mural / euro : moins de purges, dépendances épinglées sans ménage nocturne.

Prenez 2 To quand branches, gros caches et artefacts longue durée cohabitent sans ménage permanent — souvent si App Store et TestFlight ne partagent pas la même ardoise. Si l’espace semble bon mais les jobs rampent, vérifiez instantanés APFS et runtimes Simulateur avant un saut processeur.

Piège fréquent
Acheter du M4 Pro pour la « vitesse » alors que le runner creve d’E/S transforme un goulot temporaire en surcoût permanent de référence. Étendez le stockage d’abord, remesurez la file, puis décidez du Pro.

IVOptions parallèles : payer des voies pour les jobs en attente

Les runners parallèles doivent répondre à combien de jobs Actions attendent, pas au nombre de postes humains. Ajoutez un second label M4 16/256 avant de promouvoir chaque workflow vers M4 Pro. Séparez les archives release des contrôles PR, isolez les hôtes de signature, plafonnez les sessions UI qui se chevauchent lorsque les matrices nocturnes partent en même temps.

Prix les options en heures de compile par euro : doubler les voies peut valoir le coup si le temps mural s’effondre pour peu de surcoût — utile quand App Store Connect aligne les deadlines.

Quand le calendrier alterne semaines de sprint bruyantes et itérations plus calmes, modélisez les sièges burst à part du socle continu pour ne pas payer du Pro inactif. En savoir plus : sprint vs milieu de bail, mix M4 et parallèle pour le coût par siège

VCinq régions : placer les runners pour des heures de build utiles

Mesurez RTT et sorties CI, puis alignez miroirs et caches sur le métro loué — un runner mal placé brûle des minutes en téléchargements même « puissant » sur le papier.

Un silicium mal alimenté en données est du silicium à ne pas louer : un peering lent érode les heures de bail plus vite qu’une puce plus petite bien nourrie.
3× Paliers : CI légère, interactif, Pro lourd
1er Disque avant le saut Pro
GH Parallèle indexé sur la profondeur de file

VIPourquoi Mac mini et macOS restent le socle CI et release

Les runners restent sur macOS : Unix utile, signature prévisible, Gatekeeper, SIP, FileVault — moins de surprises qu’une flotte Windows typique. L’unified memory Apple Silicon tient les longs xcodebuild quand le refroidissement suit.

Un Mac mini M4 local reste silencieux, consomme environ 4 W en veille, et partage la même ISA que vos runners hébergés — couplez-le à des voies M4/M4 Pro louées pour ne pas réserver du Pro à l’inactivité quand la CI crève les plafonds. Pour ancrer ce schéma sur du matériel sobre et stable, le Mac mini M4 est le meilleur point d’entrée : franchissez le pas depuis l’accueil et l’encart ci-dessous.

VIIQuestions fréquentes

Q Faut-il router tous les workflows vers le runner M4 Pro ?
Non : réservez le Pro aux jobs qui saturent CPU et RAM ensemble ; routez lint, tests unitaires et la majorité des PR vers les paliers M4 pour garder le Pro disponible pour archives et matrices UI lourdes.
Q Quand 2 To bat-il 1 To pour des hôtes Actions ?
Lorsque plusieurs piles Xcode, caches volumineux et artefacts de branches qui se chevauchent doivent rester en ligne sans nettoyage constant — surtout si la semaine release ne tolère pas les misses de cache.

VIIIEn synthèse

Étiquetez par forme de job, ajoutez 1–2 To avant le Pro lorsque la douleur est d’E/S, achetez du M4 parallèle lorsque les files Actions le démontrent, et alignez les hôtes cinq régions sur les miroirs pour que chaque euro achète du temps de compilation — pas des cœurs inactifs.

Mac cloud · kvmmac

Capacité de build macOS en minutes, pas en semaines

Sans logistique matérielle : activation rapide et ressources alignées sur la façon dont votre CI consomme réellement disque et parallèle.

Obtenir maintenant Découvrir kvmmac
Mac cloud — agir