RunnerVPS propose des Mac dans le cloud exécutés sur des nœuds physiques Apple Silicon dédiés, et non sur des machines virtuelles. Choisissez d’abord la mémoire, le stockage, le nœud et la durée, puis connectez-vous en SSH ou VNC et validez la chaîne d’outils avec une tâche minimale.
À partir de $20.6/jourDeux configurations M4 couvrant 5 nœuds ; la disponibilité réelle est indiquée en temps réel dans la console.
Le compte, l’adresse e-mail de notification, la clé publique SSH, la version cible de Xcode et la durée influencent directement la première connexion et la configuration. Réunissez ces informations dans une même fiche de tâche interne pour faciliter le relais entre les membres de l’équipe.
Créez le compte avec une adresse e-mail à laquelle l’équipe conservera l’accès. Si vous avez déjà un compte, vérifiez d’abord l’accès à la console et les coordonnées affichées.
Choisissez une adresse capable de recevoir les notifications de commande et d’appareil. Évitez l’adresse personnelle d’un membre sur le départ afin de conserver l’accès aux informations de commande.
Préparez la clé publique générée sur votre poste actuel et notez qui conserve la clé privée correspondante. Ne transmettez que la clé publique ; ne partagez jamais la clé privée par e-mail, ticket ou dépôt de projet.
Déterminez la version cible à partir de la configuration de build, des dépendances et des tâches CI existantes. Si l’équipe gère plusieurs projets, choisissez d’abord celui qui servira de référence pour la première validation.
Choisissez une durée à la journée, à la semaine, au mois ou au trimestre selon la tâche. Les validations de compatibilité ponctuelles conviennent généralement à la journée ou à la semaine ; la CI continue et les pipelines fixes sont mieux gérés au mois ou au trimestre.
La checklist doit contenir uniquement le responsable, la version cible, la clé publique et le périmètre de la tâche. Transmettez les mots de passe, clés privées, fichiers de signature et jetons via le processus de gestion des secrets de votre équipe.
Commencez avec Runner M4 pour le développement courant, les builds d’un projet et l’automatisation légère. Choisissez Runner M4 Plus pour exécuter davantage de tâches en parallèle, conserver un cache de dépendances plus important ou traiter une charge de travail plus volumineuse.
Idéal pour le développement Xcode à distance, les tests d’un projet, les builds signés et un runner self-hosted léger.
Pour les tâches parallèles, les caches volumineux, plusieurs processus de build et les workflows expérimentaux exigeant davantage de mémoire.
| Critère | Runner M4 | Runner M4 Plus |
|---|---|---|
| Tâches parallèles | Build, tests et automatisation légère pour un seul projet | Plusieurs processus de build ou davantage de tâches simultanées |
| Dépendances et cache | Nettoyage régulier des dépendances, simulateurs et archives | Conserver un cache de dépendances et une charge de travail plus importants |
| Interface graphique | Xcode à distance, débogage et prévisualisation courante | Développement à distance avec davantage de tâches en arrière-plan |
| Quand évoluer | Continuer tant que la mémoire reste stable et que l’espace disque est suffisant | Privilégier cette offre lorsque le swap mémoire est fréquent ou que le nettoyage du cache ralentit les tâches |
Privilégiez le nœud proche des principaux utilisateurs, du dépôt de code et du lieu de réception des livrables. Les deux offres couvrent Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong et l’est des États-Unis.
Adapté aux workflows dont les principaux collaborateurs se trouvent en Asie du Sud-Est ou dont les livrables y sont fréquemment transférés.
Adapté aux équipes situées au Japon et dans les régions voisines qui utilisent régulièrement SSH et l’interface graphique.
Adapté aux tâches de développement, de test et de build en Corée du Sud et dans les régions voisines, avec un accès quotidien facilité.
Adapté aux projets collaboratifs en Asie ; évaluez l’expérience SSH et le transfert de fichiers selon le chemin réseau réel de l’équipe.
Adapté aux projets et pipelines dont les collaborateurs, services de code ou flux de réception se trouvent dans l’est de l’Amérique du Nord.
Testez d’abord le chemin entre le réseau de l’utilisateur principal et la région cible, puis considérez le sens des téléchargements depuis le dépôt et du retour des livrables. Ne vous fiez pas uniquement à la distance géographique et ne tirez pas de conclusion durable d’une seule perturbation réseau.
Avant de confirmer, revérifiez le modèle, le nœud de livraison, la durée de départ et le stockage requis. Tous les prix sont facturés en dollars ; les moyens de paiement et les passerelles disponibles sont indiqués dans la console.
Runner M4 ou Runner M4 Plus
Choisir l’un des 5 nœuds disponibles
À la journée, à la semaine, au mois ou au trimestre
Vérifier que le SSD de base couvre les dépendances, le cache et les livrables
Choisir la liaison Thunderbolt 5 uniquement si le workflow l’exige réellement
L’utilisateur effectif doit confirmer la configuration et le nœud avant l’envoi. Si la commande est liée à un projet, consignez son usage dans le système de tâches de l’équipe, sans y inscrire de mot de passe, clé privée ni identifiant de paiement complet.
La première connexion ne consiste pas à transférer immédiatement tous les projets, mais à confirmer l’identité de l’appareil, le mode d’accès, la version du système et le chemin réseau de base.
Depuis la console, vérifiez le nom de l’appareil, le nœud, l’adresse d’accès et l’empreinte de l’hôte.
Avant d’accepter la clé d’hôte pour la première fois, comparez caractère par caractère l’empreinte affichée dans la console ; en cas de différence, interrompez la connexion et ouvrez un ticket.
Vérifiez les permissions de la clé privée locale et ouvrez la session uniquement avec la clé publique enregistrée.
Après la connexion, vérifiez le nom d’hôte, la version de macOS, l’espace disque et les permissions de l’utilisateur actuel.
Vérifiez que la cible correspond à l’appareil commandé, puis préparez un réseau contrôlé ou un tunnel SSH.
Utilisez le client VNC approuvé par l’équipe et ajustez la résolution selon l’écran et le réseau locaux.
Vérifiez le verrouillage d’écran, la reconnexion après coupure et les règles du presse-papiers ; évitez d’enregistrer des identifiants persistants sur un poste partagé.
Après la première validation, mettez immédiatement à jour les identifiants d’accès initiaux et attribuez les privilèges minimaux selon les responsabilités de chacun.
Découpez la configuration en cinq parties : chaîne d’outils, dépôt, éléments de signature, exécuteur automatisé et retour des livrables. Laissez une sortie vérifiable après chaque étape au lieu d’importer toutes les dépendances d’un coup.
Confirmez les versions de macOS, Xcode, des outils en ligne de commande et du gestionnaire de paquets du projet. Inscrivez la version cible dans la documentation du projet ou la configuration CI afin d’éviter des références différentes selon les membres.
xcodebuild -versionUtilisez une clé de déploiement aux privilèges minimaux ou un mode d’accès approuvé par l’équipe pour récupérer un dépôt de test. Validez d’abord les opérations en lecture seule, puis ajoutez les privilèges nécessaires au processus de publication.
git remote -vFournissez les certificats, fichiers de signature et jetons via le processus de gestion des secrets de l’équipe. Ne placez pas de données sensibles dans le dépôt, les journaux de build ou les e-mails de contact ordinaires.
security list-keychainsLors de l’enregistrement du nœud physique comme runner self-hosted, limitez le périmètre des projets, utilisez des libellés explicites et notez l’équipe et le dépôt responsables de l’exécuteur.
runner: macos-m4Choisissez une petite tâche terminée en quelques minutes pour valider la résolution des dépendances, la compilation, les tests, la signature et le répertoire des livrables. N’utilisez pas une publication complète pour le premier essai.
xcodebuild -showBuildSettingsDéfinissez le répertoire d’archivage, le nommage des fichiers, la méthode de vérification et le lieu de réception. Confirmez que les livrables peuvent sortir de l’appareil avant d’augmenter la charge ou d’ouvrir l’accès à d’autres projets.
shasum -a 256 artifact.zipCes termes décrivent les limites de l’appareil, les modes d’accès et le processus de build. Employer la même terminologie dans les tâches et les documents de remise réduit les confusions entre appareil, instance et exécuteur.
Mettre fin à la location ne consiste pas seulement à fermer le dernier terminal. Récupérez d’abord les livrables, supprimez ensuite les comptes, clés et données de projet, puis vérifiez dans la console la durée et les associations de l’appareil.
Choisissez Runner M4 ou Runner M4 Plus, puis confirmez l’un des 5 nœuds, la durée à la journée, à la semaine, au mois ou au trimestre et les options nécessaires. Seuls USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) sont acceptés ; toutes les commandes sont facturées en dollars américains (USD).