Équipe d’infrastructure pour développeurs

Donnez à vos builds continus un Mac dans le cloud clairement attribué

RunnerVM fournit des nœuds Mac mini physiques dédiés pour iOS, macOS, CI/CD et les expérimentations d’IA. Nous ne présentons pas des ressources virtuelles partagées comme des appareils dédiés : modèle, région, prix, état de livraison et procédure de traitement des incidents sont détaillés séparément.

1 configuration disponible

5 nœuds ou centres de données

365 jours de fonctionnement normal des nœuds

Louer Runner M4 maintenant Voir la configuration et les tarifs

RUNNERVM Fiche d’exécution du build

Nœud physique

Commit de code Mac dédié Artefacts de build

Modèle disponible: Runner M4
Matériel: M4 / 16 Go / 256 Go
Type d’appareil: Machine physique dédiée, pas une machine virtuelle
Régions disponibles: Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong, États-Unis — côte Est

Configuration vérifiable Commande traçable Incident analysable

Origines de la marque

RunnerVM est né d’une chaîne de build exécutée encore et encore

Construire une application mobile n’est pas une simple opération distante ponctuelle. Checkout du code, restauration des dépendances, injection des éléments de signature, archivage, export et conservation des journaux se répètent constamment. Les équipes ont besoin d’un environnement d’exécution réutilisable et clairement attribué.

Nous avons d’abord résolu la question : où le build s’exécute-t-il ?

Un poste de développement local convient au travail interactif, mais pas forcément aux tâches automatisées longues et répétitives. RunnerVM transforme un Mac mini physique dédié en infrastructure de développement louable à la durée, afin que les scripts de build, répertoires de cache, chaînes d’outils et chemins d’artefacts restent gérables par l’équipe.

L’essentiel du service n’est pas de déplacer un bureau dans le navigateur, mais de fournir un Mac dans le cloud utilisable via interface graphique ou ligne de commande. Les développeurs peuvent y exécuter Xcode, xcodebuild, fastlane, des outils de test et les workflows habituels de gestion des dépendances.

Identifier les tâches répétitives

Sortir des appareils personnels les opérations fréquentes de signature, d’archivage, d’export et de collecte des journaux.

Stabiliser l’environnement d’exécution

Conserver une chaîne d’outils, des caches et des répertoires de build gérables sur un nœud physique dédié.

Conserver une piste de vérification

Suivre configuration, commande, nœud, ticket et journaux d’exécution sur une même chaîne.

Périmètre du service

Quelles tâches confier à RunnerVM et quelles décisions restent à la charge de l’équipe

Définir clairement le périmètre est plus important que de tout attribuer aux « capacités du cloud ». Nous fournissons l’environnement d’exécution et la gestion des nœuds ; l’architecture du projet, la stratégie de signature, les versions des dépendances et les décisions de publication restent sous le contrôle de l’équipe.

Pour les builds continus et le développement à distance

Convient à la compilation iOS et macOS, aux exécuteurs CI/CD, aux builds iOS React Native, à l’archivage automatisé Xcode, aux tâches en ligne de commande, à la préparation du débogage distant et aux expérimentations d’IA nécessitant explicitement un environnement Apple Silicon.

Besoin d’un environnement de calcul dédié et d’une arborescence stable
Besoin d’utiliser l’appareil à la journée, à la semaine, au mois ou au trimestre
Besoin de choisir un point d’accès parmi cinq régions disponibles

Nous ne présentons pas des ressources partagées comme des appareils dédiés

Le service RunnerVM disponible repose sur des Mac mini physiques dédiés, livrés sans virtualisation. La page ne remplace pas le véritable modèle par une vague « instance haute performance » et n’invente aucune combinaison de mémoire, de stockage ou de puce absente du catalogue.

Nous ne décidons pas à la place de l’équipe des dépendances ni du processus de publication
Nous ne garantissons pas une durée de build non validée par le projet
Nous ne présentons pas des ressources virtuelles partagées comme des nœuds physiques dédiés

Principes d’exploitation

Les faits produit sont uniques, même si leur présentation varie selon la langue

Les pages multilingues, descriptions des offres, configurations de commande et réponses du support RunnerVM s’appuient sur les mêmes faits produit. Changer de langue ne doit modifier ni la configuration, ni le prix, ni la région, ni les moyens de paiement disponibles.

Configuration fidèle

Chaque appareil disponible précise sa puce, sa mémoire, son stockage et ses caractéristiques physiques. Runner M4 correspond actuellement à M4, 16 Go et 256 Go ; aucun modèle non disponible n’est ajouté et aucun stockage supplémentaire n’est présenté comme configuration de base.

Tarifs cohérents

Les tarifs à la journée, à la semaine, au mois et au trimestre restent identiques sur les pages d’offre, de commande et dans les informations associées. Toutes les commandes sont réglées en dollars américains ; les options sont détaillées séparément, sans prix d’appel masquant le coût complet de la période.

Nœuds vérifiables

Le catalogue répertorie clairement cinq régions disponibles. Lorsqu’une région est sélectionnée, seules les combinaisons prises en charge par le modèle actuel sont affichées. Les diagnostics réseau consignent le nœud source, le nœud cible, l’heure et la sortie complète.

Incidents traçables

Les incidents techniques sont traités dans un ticket à partir de la commande, du nœud, de l’heure, des étapes de reproduction et de journaux désensibilisés. État, informations complémentaires et conclusion sont mis à jour dans le même ticket afin d’éviter la dispersion des informations.

Catalogue des configurations 1 offre

Catalogue des régions 5 nœuds

Périodes de facturation Jour / semaine / mois / trimestre

Moyens de paiement USDT-TRC20 ou carte bancaire

Le paiement par carte comprend uniquement Visa, Mastercard et Amex, traité par Stripe ; les passerelles réellement disponibles sont celles renvoyées par l’interface backend. Toutes les commandes sont réglées en dollars américains (USD).

Répartition des nœuds

Cinq nœuds couvrent les principales voies d’accès en Asie et la côte Est des États-Unis

Le choix d’un nœud ne dépend pas uniquement de la distance géographique. L’équipe doit aussi tester l’emplacement des membres, les sources du code et des dépendances, le parcours des opérations distantes, la destination des artefacts et la sortie réseau de l’entreprise avant de sélectionner la région de commande.

Singapour

Convient aux équipes de développement d’Asie du Sud-Est et constitue également un point d’accès asiatique pour la collaboration interrégionale. Avant de commander, testez la latence et le routage depuis le réseau réellement utilisé au bureau.

Japon (Tokyo)

Convient aux équipes basées au Japon ou proches des chemins réseau de Tokyo. Pour les workflows utilisant fréquemment le bureau à distance, observez également les performances p50, p95 et aux heures de pointe.

Corée du Sud (Séoul)

Offre un point d’accès régional pour les tâches de développement et de build orientées vers la Corée du Sud. Pour les dépendances ou artefacts volumineux, testez à la fois les sources de téléchargement et les cibles d’envoi.

Hong Kong

Convient aux équipes ayant besoin d’un accès transfrontalier en Asie. Le routage réel pouvant varier selon l’opérateur, le nom de la région ne remplace pas les mesures effectuées sur le réseau du projet.

US-E

États-Unis — côte Est

Convient aux tâches dont les membres de l’équipe, services de code ou chaînes de livraison se trouvent principalement sur la côte Est des États-Unis. Pour les opérations intercontinentales, privilégiez l’exécution automatisée et conservez des journaux complets.

Testez d’abord l’interaction distante, puis la chaîne de build

Depuis le réseau réellement utilisé, vérifiez séparément ping, traceroute, DNS et le port cible, puis lancez une récupération de dépendances et un envoi d’artefacts proches du projet réel. Les données publiques de latence servent à comparer, pas à remplacer les tests de votre équipe.

Consulter le guide de diagnostic réseau

Responsabilités concernant les appareils et les données

De la vérification avant livraison à la fin de la commande, chaque étape a un responsable clairement défini

Un appareil dédié ne dispense pas de contrôler les accès. RunnerVM prend en charge la livraison du nœud, le processus des identifiants côté service et le traitement à la fin de la commande. L’utilisateur prend en charge les réglages de sécurité initiaux, les autorisations du projet, les éléments de build et la sauvegarde des données métier.

01

Vérifier l’appareil avant livraison

Vérifiez le modèle disponible, la mémoire, le stockage de base, la connexion réseau et l’accessibilité de l’appareil, puis associez la commande à la région choisie par l’utilisateur. Les informations de livraison sont celles de la commande et de la console.
RunnerVM prend en charge : cohérence entre configuration et nœud
02

Mettre à jour les paramètres de sécurité après la première connexion

Après avoir reçu les identifiants de connexion, l’utilisateur doit vérifier l’empreinte de l’hôte, modifier le mot de passe initial, limiter les sources d’accès inutiles et confirmer que les connexions au bureau distant et à la ligne de commande respectent la politique de l’équipe.
L’utilisateur prend en charge : conservation des identifiants et attribution des droits
03

Contrôler les données du projet pendant la location

Les certificats, profils, sources, caches, journaux et artefacts de build doivent être organisés dans des répertoires distincts par projet. Lorsqu’ils sont partagés avec l’équipe, appliquez le principe du moindre privilège et conservez une sauvegarde indépendante des artefacts essentiels.
Objectif commun : limiter la propagation des droits et le mélange des données
04

Révoquer les accès à la fin de la commande

Le service révoque les identifiants de connexion associés à la commande et lance le traitement de l’appareil. L’utilisateur doit exporter à l’avance les artefacts à conserver, supprimer les clés du projet et vérifier qu’aucune tâche automatisée n’envoie encore de données au nœud.
Conditions de clôture : accès révoqués, tâches arrêtées, données traitées

Éléments à sauvegarder par l’utilisateur

Artefacts de build hors dépôt source, fichiers exportés, journaux du projet, scripts personnalisés, fichiers existant uniquement dans le cache et informations de configuration encore nécessaires à l’équipe.

Désensibiliser les informations avant de contacter le support

Les journaux doivent conserver l’heure, la commande, le code d’erreur et le contexte, tout en supprimant mots de passe, jetons, clés privées, mots de passe de certificats et tout autre élément permettant un accès direct.

État public et amélioration

Le suivi d’état explique ce qui s’est passé ; l’analyse indique quoi améliorer ensuite

L’objectif de disponibilité du service RunnerVM est de 99,9 %. Les nœuds fonctionnent normalement 365 jours par an ; les incidents liés aux appareils, aux réseaux externes ou à la configuration utilisateur sont consignés et traités selon leur impact réel.

Objectif de disponibilité 99,9 %

La qualification, la vérification et le périmètre de traitement des événements réels sont définis par les conditions de service applicables.

Il y a 90 jours 3 jours par case Dernier relevé

La barre d’état représente la période des 90 derniers jours. La disponibilité réelle du nœud au moment de la commande est celle renvoyée en temps réel par la console.

Suivi

Les événements sont localisables

Consignez les heures de début et de fin, les nœuds concernés, les symptômes visibles, le mode de confirmation et le résultat du rétablissement, plutôt que de publier une conclusion d’état sans périmètre défini.

Traitement

Rétablir d’abord, vérifier le périmètre ensuite

Rétablissez en priorité l’appareil ou la connectivité, puis vérifiez le périmètre affecté à partir de la commande, du nœud, de l’heure et des journaux, en mettant à jour l’état dans le ticket.

Analyse

Les actions d’amélioration doivent être exécutables

Le résumé distingue les problèmes liés à l’appareil, au réseau, à la livraison et au processus, et précise les points de contrôle, responsables et méthodes de validation, sans promesses absolues invérifiables.

Suivi quotidien Connexion des nœuds et état du service

Suivi des événements Heure, périmètre, symptômes et résultat du rétablissement

Résumé d’analyse Catégories de causes, actions d’amélioration et méthode de validation

La configuration et les tarifs diffèrent-ils selon la langue de la page ?

Non. La langue modifie uniquement la formulation, pas les modèles disponibles, les tarifs par période, les options, le catalogue des régions ni les moyens de paiement. En cas d’incohérence, envoyez les pages concernées et des captures via support@runnervm.com ou un ticket dans la console.

RunnerVM choisit-il un nœud à la place de l’équipe ?

Non, nous ne décidons pas directement pour le projet. Nous publions le catalogue des cinq nœuds de Singapour, du Japon (Tokyo), de la Corée du Sud (Séoul), de Hong Kong et de la côte Est des États-Unis, avec une méthode de diagnostic réseau. L’équipe doit tester puis choisir selon son réseau professionnel, ses sources de dépendances et ses objectifs de livraison.

Comment accélérer le diagnostic en cas de problème de build ou de connexion ?

Commencez par noter l’identifiant de commande, la région du nœud, l’heure, les étapes de reproduction et la sortie complète de l’erreur, puis consultez le guide du support. Si le problème persiste, connectez-vous à la console pour ouvrir un ticket ; supprimez les identifiants et données sensibles des journaux avant l’envoi.

Prochain build

Confiez vos builds répétitifs à un Mac dédié dans le cloud

Vérifiez d’abord la configuration, la période et les cinq régions disponibles pour Runner M4, puis passez la commande. Pour discuter des besoins du projet, contactez l’équipe par e-mail du support ou via un ticket dans la console.

Commencer à louer un Mac dans le cloud Contacter l’équipe support