Runner propose des Mac dans le cloud à louer par projet. Chaque commande correspond à une machine Apple Silicon physique dédiée, et non à une machine virtuelle, idéale pour les équipes qui ont besoin d’une chaîne d’outils fixe, d’un macOS graphique complet ou de tâches exécutées en continu.
Commencez par la durée, la mémoire, l’interface graphique et le parallélisme requis par la tâche, sans avoir à deviner le modèle.
Le type d’application ne suffit pas à déterminer la configuration. Commencez par vérifier la durée d’exécution, le pic de mémoire, la dépendance à une interface graphique et le nombre de processus de build ou d’expérimentation lancés simultanément.
Une validation ponctuelle peut être planifiée à la journée ; un sprint de version convient à la semaine ; l’intégration continue et les expérimentations permanentes se planifient au mois ou au trimestre pour limiter les réinitialisations de l’environnement.
Les projets Xcode courants et l’automatisation légère peuvent commencer avec 16 Go ; pour exécuter simultanément des simulateurs, plusieurs builds ou des modèles volumineux, évaluez en priorité 24 Go.
Pour les scripts et commandes de build uniquement, privilégiez SSH ; si vous devez utiliser Xcode, une timeline, des fenêtres d’aperçu ou les réglages système, prévoyez aussi une interface graphique distante.
Notez si les tests, le packaging, l’inférence de modèles et les exports se chevauchent. Les tâches parallèles consomment ensemble mémoire, cache disque et bande passante : choisissez selon le pic, pas la moyenne.
Ces scénarios ne s’excluent pas mutuellement. Un même nœud peut servir au débogage, puis rejoindre un pipeline automatisé ; l’essentiel est de délimiter clairement environnement, cache et livrables pour chaque étape.
Ouvrez Xcode via l’interface graphique, récupérez le code et sélectionnez la chaîne d’outils requise par le projet. Après les tests, produisez un build signé, puis renvoyez l’archive et les journaux vers votre espace de stockage.
Enregistrez le nœud dans le projet ou l’organisation souhaité, limitez les sources autorisées, conservez le cache des dépendances et renvoyez rapports de test, archives et fichiers de symboles vers le stockage d’artefacts du pipeline.
Dans un environnement Apple Silicon, vérifiez la compatibilité du modèle, du framework et des dépendances. Estimez la mémoire selon les poids, la longueur du contexte et les requêtes simultanées, en séparant données et résultats d’expérimentation.
Transférez d’abord les fichiers proxy ou les ressources nécessaires, puis vérifiez la timeline et l’aperçu via l’interface graphique distante. Séparez cache, fichiers source et répertoire d’export, puis récupérez rapidement les rendus et fichiers de projet.
Les tâches de développement ralentissent souvent lorsque « cela fonctionne en local, mais pas à distance ». Répertoriez clairement versions, dépendances, éléments de signature et chemins des artefacts afin de passer de la machine de débogage à la machine de build en toute stabilité.
Développement d’un projet, tests unitaires courants, un build principal à la fois, avec 16 Go de mémoire et 256 Go de SSD suffisants pour le code, les dépendances et le cache nécessaire.
Vérifiez branche, sous-modules, sources des dépendances et périmètre d’accès au dépôt ; n’enregistrez pas d’identifiants persistants dans le répertoire du projet.
Figez les versions de Xcode et des outils en ligne de commande requises par le projet, puis effectuez un contrôle de l’environnement avant d’installer les dépendances.
Commencez par un petit ensemble de tests pour vérifier simulateur, plateforme cible et autorisations, puis passez à la suite complète.
Injectez certificats et fichiers de signature depuis un emplacement contrôlé, puis produisez l’archive, le rapport de test et les journaux de diagnostic nécessaires.
Renvoyez archive et journaux vers le stockage de l’équipe, vérifiez leur intégrité, puis nettoyez le répertoire temporaire et les éléments sensibles.
Une machine physique dédiée offre des ressources clairement délimitées, mais le pipeline doit encore restreindre les sources de déclenchement, le périmètre des projets et les autorisations des identifiants. Gérez séparément l’enregistrement du runner, la stratégie de cache, le nettoyage des tâches et le retour des artefacts pour réduire les risques de contamination croisée.
Si compilation, tests, archivage ou plusieurs projets s’exécutent simultanément, mesurez le pic de mémoire et le volume du cache. Pour plus de mémoire et un SSD local plus grand, évaluez en priorité Runner M4 Plus.
Associez le nœud à un projet ou une organisation précis et contrôlez les workflows autorisés à l’utiliser.
L’équipe injecte jetons, certificats et variables d’environnement via son propre processus de gestion des secrets, puis révoque les autorisations temporaires à la fin de la tâche.
Stockez cache des dépendances, fichiers intermédiaires de build et artefacts finaux dans des répertoires distincts, avec des règles de nettoyage vérifiables.
Renvoyez rapports de test, archives, fichiers de symboles et informations de contrôle vers le stockage du pipeline ; ne faites pas du nœud l’unique copie.
Sur Apple Silicon, commencez par les versions des frameworks, le format des modèles et la prise en charge des opérateurs, plutôt que de recopier les paramètres d’un autre matériel. Les tests MLX et de modèles locaux partagent la mémoire unifiée : poids, contexte, requêtes simultanées et autres processus doivent donc être budgétés ensemble.
Lorsque poids de modèle, contexte long, prétraitement des données et plusieurs processus d’expérimentation doivent rester simultanément en mémoire, ou lorsque l’environnement 16 Go subit souvent une pression mémoire, Runner M4 Plus offre davantage d’espace de travail.
Dans les tâches audiovisuelles distantes, l’attente ne vient pas uniquement de l’export. Envoi des médias, génération des proxys, qualité de l’affichage distant et téléchargement des résultats influencent l’expérience globale ; ne promettez donc pas une durée de rendu fixe. Vérifiez plutôt réseau, stockage et état de la tâche étape par étape.
En plus des médias source, prévoyez de l’espace pour les proxys, le cache de rendu, les sauvegardes automatiques du projet et l’export final. Si 256 Go ne suffisent pas, choisissez la configuration m4-24-512 ou évaluez l’extension SSD sur la page des formules.
Envoyez en priorité les médias ou proxys nécessaires au projet, conservez une copie locale des originaux et vérifiez l’intégrité du transfert.
Ajustez la résolution de la session graphique selon le réseau ; la fluidité de l’aperçu ne garantit pas la qualité de l’export final.
Stockez cache et médias source dans des répertoires distincts et vérifiez l’espace disque disponible avant un export important.
Après l’export, vérifiez la taille et la lisibilité du fichier, renvoyez-le au stockage de l’équipe, puis supprimez les copies temporaires.
Les deux formules proposent une machine physique dédiée, SSH et une interface graphique macOS. Elles se distinguent par la mémoire, la capacité SSD et le prix, et non par des ratios flous de ressources partagées.
Adapté au développement Xcode sur un seul projet, à un build principal à la fois, aux runners self-hosted légers, aux validations de compatibilité courtes et aux workflows nécessitant peu de médias locaux.
Adapté à l’exécution parallèle de simulateurs et de builds, à plusieurs tâches automatisées, aux expériences MLX plus volumineuses, à davantage de cache de dépendances et aux workflows stockant temporairement proxys et exports sur le nœud.
Rassemblez taille du projet, version de Xcode, nombre de tâches simultanées, volume du cache et durée prévue, puis envoyez-les à l’équipe via la page de contact. Ne transmettez jamais de mot de passe, clé privée ou justificatif de paiement complet.
Runner est disponible à la journée, à la semaine, au mois ou au trimestre. Tous les paiements sont facturés en dollars américains ; seuls USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) sont acceptés. Les passerelles réellement disponibles sont celles renvoyées par la console.