Déléguez vos tâches sans réécrire vos workflows

Confiez ces tâches à
un Mac Apple Silicon dans le cloud

Builds nocturnes, tests de régression automatisés, expérimentation de modèles. Gardez vos outils habituels et confiez l’exécution à un Mac mini physique dédié, pas à une machine virtuelle.

Commencez par une tâche mesurable et testez-la à la journée. Choisissez ensuite le modèle et la durée selon la mémoire utilisée, l’espace disque consommé et la fréquence des tâches.

Louer un Mac dans le cloud Voir les configurations et les tarifs

Deux configurations · cinq régions · $20.2par jour. La disponibilité réelle est indiquée en temps réel dans la console.

Commencez par une tâche concrète

Quatre types de tâches, quatre façons de démarrer

Les configurations recommandées sont un point de départ pour vos tests, pas une garantie de performances. Rien ne vaut un essai avec votre propre projet.

01 / BUILD

Builds nocturnes React Native

Codez en local le jour et confiez les builds iOS au cloud la nuit. Commencez par une branche dédiée et vérifiez que les versions de Node, CocoaPods, Xcode et Fastlane reproduisent vos résultats actuels.

Commencez par une file de tâches unique et conservez les fichiers de verrouillage des dépendances. Stockez séparément le cache des dépendances et les artefacts finaux. Ne videz pas tout le cache après chaque build et ne stockez pas les certificats de signature dans le dépôt.

Vérifiez trois points :les dépendances s’installent, le build se termine avec le bon code de sortie et les artefacts sont utilisables par les tests suivants. Mesurez séparément les builds à cache froid et les builds répétés.

Formule hebdomadaire conseillée · couvre un cycle de publication

Flow M4
M4 / 16GB / 256GB

Louer Flow M4 pour vos builds
02 / RELEASE

Builds Flutter multiplateformes

Centralisez les builds iOS et macOS dans un même environnement macOS. Fixez les versions de Flutter SDK, Dart et Xcode pour que le même commit utilise les mêmes paramètres de build en local et dans le cloud.

Migrez d’abord une plateforme cible, puis ajoutez les autres. Les simulateurs, DerivedData et caches de dépendances occupent de l’espace disque en continu. Gardez les runtimes nécessaires et définissez des règles de nettoyage du cache.

Vérifiez trois points :le diagnostic de l’environnement passe, les artefacts ciblés sont générés et journaux et artefacts peuvent être récupérés. Si vous devez lancer plusieurs builds en parallèle, évaluez Flow M4 Pro plutôt que de maximiser d’emblée la concurrence.

Formule mensuelle conseillée · environnement de développement fixe

Flow M4
M4 / 16GB / 256GB

Louer Flow M4 pour vos builds
03 / INFERENCE

Expériences d’inférence locale avec MLX

Testez des modèles quantifiés avec les 64GB de mémoire unifiée du M4 Pro. Définissez d’abord la version du modèle, la quantification, la longueur de contexte et les entrées de test. Pour vérifier qu’un modèle tient en mémoire, comptez aussi l’utilisation du runtime et du cache.

Utilisez un environnement Python distinct pour chaque expérience. Stockez séparément les poids du modèle, le cache de téléchargement et les résultats. Si vos modèles occupent beaucoup d’espace, envisagez l’option SSD +2TB pour éviter de saturer le disque système avec des téléchargements répétés.

Vérifiez trois points :le modèle se charge, le pic de mémoire reste acceptable et le débit est reproductible avec les mêmes entrées. Validez d’abord à la journée, puis envisagez une formule trimestrielle. Ajouter du stockage n’augmente pas la mémoire unifiée.

Essai à la journée conseillé · passez à une location longue après validation

Flow M4 Pro
M4 Pro / 64GB / 2TB

Louer Flow M4 Pro pour vos expériences
04 / TEST

Tests de régression XCUITest

Exécutez votre suite de tests fixe sur un nœud dédié pour éviter que les tests de régression et le développement quotidien se disputent les ressources locales. Fixez la version de Xcode, le runtime du simulateur et la configuration des appareils de test. Validez d’abord en série, puis augmentez progressivement la concurrence.

Conservez à chaque exécution les résultats de test, les captures d’écran des échecs et le commit correspondant. Si les tests nécessitent une session graphique, vérifiez les prérequis de cette session : une connexion SSH ne garantit pas que tous les tests d’interface puissent s’exécuter directement.

Vérifiez trois points :les résultats restent stables d’une exécution à l’autre, les échecs sont consignés intégralement et la mémoire reste suffisante en parallèle. Les tests sur simulateur dans le cloud n’incluent pas d’appareils de test physiques.

Formule hebdomadaire conseillée · pour une campagne complète de régression

Flow M4 Pro
M4 Pro / 64GB / 2TB

Louer Flow M4 Pro pour vos tests
Validez d’abord en parallèle, puis basculez en production

Migrez vos tâches locales en trois étapes

Validez séparément les données, la chaîne d’outils et la CI. En cas de problème, revenez à l’étape concernée sans modifier toutes les variables à la fois.

01 · Données

Transférez d’abord le code et les caches

Sur le Mac local

Répertoriez les projets, fichiers de verrouillage des dépendances, caches nécessaires et répertoires d’artefacts. Écartez les fichiers temporaires et les artefacts de build inutiles, puis créez une sauvegarde indépendante.

Sur le Mac dans le cloud

Créez le répertoire du projet et transférez les fichiers de manière incrémentielle avec rsync. Si le projet et les caches sont volumineux, évaluez les options SSD +1TB ou SSD +2TB selon l’espace nécessaire. Vérifiez l’emplacement de montage du disque ajouté sur la machine.

Définissez MAC_HOST comme adresse de connexion, puis exécutez

rsync -av --progress ./ "$MAC_HOST:~/workspace/"

Transfert terminé :les fichiers sont lisibles et modifiables, les permissions des répertoires sont correctes et les sommes de contrôle des fichiers essentiels correspondent. La synchronisation rsync ne remplace pas une sauvegarde indépendante. Lors d’une première migration, n’activez pas l’option qui supprime les fichiers de destination.

02 · Chaîne d’outils

Éliminez les différences de versions, une par une

Sur le Mac local

Notez les versions de Xcode et des outils en ligne de commande, puis exportez la liste des dépendances Homebrew. Identifiez les éléments nécessaires dans le trousseau de certificats et vérifiez les autorisations d’accès ainsi que leur portée.

Sur le Mac dans le cloud

Installez et sélectionnez les versions d’outils correspondantes, puis restaurez les dépendances d’après la liste. Importez les certificats dans le trousseau par un processus contrôlé. Vérifiez d’abord que les tâches en ligne de commande peuvent y accéder dans la session prévue ; ne consignez pas le mot de passe de déverrouillage dans les journaux.

Vérifiez les outils de développement et leurs chemins

xcodebuild -version
xcode-select -p

Transfert terminé :le même commit se compile avec les mêmes paramètres. Exécutez d’abord une commande complète, puis passez à l’automatisation. Ne définissez pas directement un environnement non validé comme exécuteur par défaut.

03 · Intégration CI

Testez d’abord le nouveau label, gardez l’ancien chemin

Sur le Mac local

Conservez la configuration actuelle du pipeline et répertoriez les étapes de build, de test, d’archivage et de téléversement. Remplacez les chemins locaux codés en dur par une variable de répertoire de travail et précisez le label d’exécution à rétablir en cas de retour arrière.

Sur le Mac dans le cloud

Enregistrez un runner self-hosted avec un label dédié et les permissions minimales. Faites d’abord pointer une branche de test vers le nouveau nœud, vérifiez le téléversement des artefacts et le retour des journaux, puis remplacez le label du pipeline de production.

Exemple de label d’exécuteur GitHub Actions

runs-on: [self-hosted, macOS, ARM64, cloud-build]

Transfert terminé :les tâches s’exécutent bien sur le nouveau nœud, les résultats sont traçables et les identifiants ne figurent pas dans la sortie. N’autorisez pas les commits externes non fiables à accéder directement à un runner contenant des certificats de signature.

Choisissez selon le goulot d’étranglement, pas le nom

Commencez par la mémoire, puis évaluez le stockage et la collaboration

Pour les builds légers, commencez par Flow M4 ; pour les builds parallèles et MLX, évaluez Flow M4 Pro en priorité. La collaboration entre plusieurs machines relève d’une configuration distincte : plusieurs machines ne deviennent pas pour autant une seule machine dotée d’une mémoire plus importante.

Correspondance entre tâches et deux configurations, avec les points à vérifier pendant l’essai
Tâche et goulot d’étranglement Configuration de départ recommandée Durée conseillée Points à vérifier pendant l’essai
Builds légers, file de tâches unique Flow M4
M4 / 16GB / 256GB		 Louez à la semaine pour couvrir une publication ; évaluez une formule mensuelle après une période d’utilisation stable. Durée des builds à cache froid et chaud, pic de mémoire et croissance du répertoire de build.
Builds parallèles, nombreux tests sur simulateur Flow M4 Pro
M4 Pro / 64GB / 2TB		 Validez la concurrence à la journée, puis lancez une suite complète de tests à la semaine. Augmentez progressivement le nombre de tâches et surveillez la pression sur la mémoire, la stabilité des tests et les écritures disque.
Inférence de modèles quantifiés avec MLX Flow M4 Pro
M4 Pro / 64GB / 2TB		 Testez à la journée et choisissez une formule mensuelle ou trimestrielle une fois la compatibilité du modèle confirmée. Occupation totale des poids, du contexte et du cache d’exécution, ainsi que débit avec des entrées fixes.
Projets, modèles ou caches volumineux Choisissez selon les besoins en mémoire du modèle ; évaluez aussi les options SSD +1TB ou SSD +2TB. Vérifiez le tarif de l’option avec la période de facturation choisie. Emplacement des répertoires, point de montage, espace restant et intégrité de la sauvegarde indépendante.
Répartition du travail entre plusieurs nœuds Choisissez d’abord une machine selon les tâches, puis évaluez l’interconnexion Thunderbolt 5, facturée par machine. Validez d’abord les besoins logiciels et de connexion, puis choisissez une durée de location longue. Répartition des tâches et mode de transfert des données. L’interconnexion ne fusionne pas automatiquement la mémoire unifiée et ne rend pas les logiciels distribués automatiquement.

Choisir un nœud

Cinq régions sont disponibles : Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et côte est des États-Unis. Les deux configurations sont proposées dans chacune. Pour un travail interactif, privilégiez la proximité de l’utilisateur ; pour les builds automatisés, tenez aussi compte du chemin de transfert du code et des artefacts.

Comment consigner les essais

Utilisez le même commit et les mêmes versions d’outils, puis mesurez séparément la préparation, le build, les tests et le téléversement. Sans les mêmes entrées et le même environnement, un essai rapide ne suffit pas à confirmer que la tâche sera adaptée à long terme.

Comparer les tarifs des quatre durées et des options Consulter le guide de configuration et d’intégration CI
Définissez plus précisément votre objectif de migration

Moins de transferts, plus de validation

Formulez un objectif vérifiable en une phrase : le processus actuel s’exécute correctement ou l’expérience confirme la compatibilité. Décidez de la suite une fois ce résultat obtenu.

« Nous avons déplacé la CI de notre machine locale vers le nœud de Séoul : il a suffi de modifier une ligne de label dans le pipeline pour que tout fonctionne. »

Ingénieur d’une équipe React Native

« J’ai commencé par louer une machine à la journée pour tester MLX ; une fois la configuration validée, je suis passé à la formule trimestrielle. »

Développeur de prototypes de produits IA

Choisissez un cas d’usage et lancez un essai

Munissez-vous d’un projet, d’un jeu d’entrées et d’un critère de validation. Faites d’abord fonctionner la tâche, puis décidez quelle part de votre travail confier au cloud.

Location à la journée, à la semaine, au mois ou au trimestre. Paiement uniquement par USDT-TRC20 ou par Visa / Mastercard / Amex via Stripe, en dollars américains. Les moyens de paiement réellement disponibles sont indiqués dans la console.

Louer un Mac dans le cloud Comparer les deux configurations