Munissez-vous d’une adresse e-mail capable de recevoir un code de vérification, d’un moyen de paiement valide et d’un client SSH ou de partage d’écran. Réservez un Mac physique dédié, puis récupérez vos identifiants de connexion dans le portail après confirmation du paiement.
2 modèles · 6 serveurs · à partir de $21.4/jour. Les 4 minutes correspondent à un parcours sans incident ; les confirmations sur la blockchain, les vérifications requises et l’état du réseau peuvent modifier le délai réel.
Vérifiez d’abord votre adresse e-mail et votre moyen de paiement, puis choisissez le modèle, le serveur et la durée. Toutes les informations de livraison sont regroupées dans le portail : pas besoin de chercher vos identifiants ailleurs.
Utilisez une adresse à laquelle vous aurez toujours accès. Vérifiez que vous pouvez consulter la boîte de réception et les courriers indésirables : les notifications de commande et la vérification du compte seront envoyées à cette adresse.
Le code de vérification ne sert que pendant la procédure en cours. Ne le communiquez à personne.
Payez en USDT-TRC20 ou par Visa / Mastercard / Amex via Stripe ; tous les paiements sont en dollars. Pour un paiement en USDT, vérifiez le réseau et les informations de paiement affichées sur la page.
Les moyens disponibles sont ceux proposés sur la page de paiement.
Pour les tâches en ligne de commande, prévoyez un client SSH. Pour utiliser l’interface graphique de macOS, installez un client de partage d’écran. Avant la première connexion, vérifiez que votre réseau local n’impose pas de restrictions sur le port utilisé.
Commencez par configurer une méthode de connexion, puis l’autre.
Ouvrez le portail, saisissez votre adresse e-mail et suivez les instructions pour la vérifier. Si vous avez déjà un compte, connectez-vous directement. Vérifiez l’orthographe de l’adresse avant de demander un code pour éviter d’attendre à cause d’une erreur de saisie.
Selon votre projet, choisissez le XN Core M4 ou le XN Pro M4P, puis un serveur et une durée de location à la journée, à la semaine, au mois ou au trimestre. Les 6 serveurs sont situés à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul), à Hong Kong, dans l’est des États-Unis et dans l’ouest des États-Unis. Les deux modèles sont disponibles dans ces 6 emplacements ; la disponibilité affichée en temps réel dans le portail fait foi.
Les paiements par Visa / Mastercard / Amex via Stripe sont confirmés immédiatement, sous réserve des vérifications demandées à l’écran. Pour l’USDT-TRC20, le délai de confirmation dépend du traitement sur la blockchain : il n’est pas garanti qu’il soit d’une minute. Après le paiement, vérifiez d’abord le statut de la commande au lieu de payer une nouvelle fois si la page n’est pas encore à jour.
Une fois le paiement confirmé, le système attribue un serveur physique dédié et affiche les informations de connexion dans le portail. Vérifiez l’emplacement, le modèle, l’adresse de l’hôte et le port. Consultez vos identifiants uniquement dans le portail après vous être connecté ; ne collez pas votre mot de passe dans des journaux de build publics.
Utilisez l’hôte, le port et le nom d’utilisateur indiqués dans le portail. Vérifiez que vous êtes bien sur la machine cible, puis modifiez le mot de passe initial et contrôlez la configuration du système. Une connexion SSH réussie ne garantit pas que l’interface graphique est configurée : vérifiez les deux méthodes séparément.
≈ 4 minutes Délai indicatif, de l’inscription à la livraison des identifiants
Ce délai n’inclut pas l’installation des logiciels, le transfert du projet ni un build complet. Si la confirmation de l’USDT-TRC20 prend plus de temps, la livraison est retardée d’autant. Le temps nécessaire à votre première connexion dépend aussi de votre réseau local et de la configuration de votre client.
Si vos besoins à long terme ne sont pas encore clairs, commencez par tester votre projet à la journée. Vérifiez que le projet compile entièrement, que la mémoire convient aux pics de charge et que vous avez assez de place pour les artefacts et le cache.
$21.4/jour
Adapté à la compilation d’apps, aux tests sur simulateur et aux pipelines CI classiques. Lancez un premier archive complet, puis vérifiez l’espace occupé par le cache de build, les dépendances et les données du simulateur.
Pour des tâches exécutées séquentiellement et des projets de taille raisonnable, commencez avec ce modèle. Évitez d’accumuler sans limite plusieurs runners sur une même machine et de juger ses performances à partir du temps passé en file d’attente.
$59.3/jour
Adapté aux builds fortement parallélisés, à plusieurs tâches de développement simultanées et aux expérimentations avec des modèles de grande taille. Sa mémoire unifiée de 64GB et son disque principal de 2TB offrent davantage d’espace pour les fichiers de modèles, les dépendances et le cache de build.
Avant d’exécuter des tâches MLX ou Core ML, vérifiez la taille du modèle, sa quantification et les besoins du runtime. La capacité mémoire ne garantit pas que tous les modèles fonctionneront : testez d’abord votre charge réelle.
Les deux modèles sont des Mac physiques dédiés, et non des machines virtuelles. Choisissez d’abord le serveur le plus proche des personnes qui l’utiliseront, puis testez la connexion en conditions réelles. Pour les builds automatisés, tenez aussi compte du chemin de transfert du code source et des artefacts. Consultez les tarifs complets pour comparer les quatre durées de location ou les disques d’extension externes.
Gardez votre connexion actuelle fonctionnelle pendant que vous ajustez les réglages de sécurité, un par un. Après toute modification du pare-feu ou de SSH, testez la nouvelle configuration dans une deuxième session pour éviter de vous bloquer l’accès.
Choisissez un mot de passe robuste, unique et différent de vos autres mots de passe. Utilisez la procédure de changement prévue par le système. Ne le notez pas en clair dans des paramètres de commande, des scripts ou des tickets. Si plusieurs personnes utilisent le serveur de build, désignez clairement la personne responsable des identifiants.
Vérifiez le pare-feu macOS et les réglages des services à distance ; n’autorisez que les accès nécessaires à vos tâches. Avant de restreindre les adresses IP autorisées, vérifiez que votre adresse IP publique est fixe. Testez les nouvelles règles avant de fermer la connexion en cours.
Notez la version de macOS et utilisez uname -m pour confirmer que l’architecture native est arm64. Vérifiez la compatibilité des dépendances du projet et de la chaîne d’outils avant de décider s’il faut changer de version de Xcode.
Utilisez df -h pour consulter l’espace restant. La capacité nominale du disque principal ne correspond pas à l’espace disponible : le système, les outils de développement et les caches occupent déjà de la place. Avant de transférer des modèles ou des ressources volumineux, estimez l’espace nécessaire.
Commandes de vérification en lecture seule · sans modifier la configuration
sw_vers
uname -m
df -h
xcode-select -pLa dernière commande affiche le chemin des outils de développement actifs. Si la chaîne d’outils n’est pas encore configurée et qu’une erreur s’affiche, passez à la section suivante pour l’installer et la sélectionner.
L’interface graphique de macOS et la ligne de commande sont disponibles. Vérifiez d’abord l’environnement existant pour éviter les installations en double. L’installation des logiciels, le téléchargement des dépendances et le premier build ne sont pas inclus dans les quelque 4 minutes de livraison du serveur.
Contrôlez la version de Xcode installée et les exigences du projet. Si vous devez installer ou changer de version, utilisez un installateur obtenu légalement. Une fois l’installation terminée, vérifiez que le chemin des outils de développement pointe vers la version souhaitée.
Les outils en ligne de commande servent à compiler et à utiliser des dépendances courantes ; ils ne remplacent pas Xcode au complet. Pour les simulateurs, les archives ou les SDK, vérifiez aussi que l’environnement de développement complet est installé.
xcodebuild -version
xcode-select -p
xcrun --find clang
xcrun simctl list devices availableVérifiez les versions et les appareils disponibles avant de lancer le projet.
Exécutez d’abord command -v brew pour vérifier si Homebrew est installé. Sinon, suivez les instructions d’installation officielles de Homebrew et n’exécutez pas de script d’origine inconnue.
Vérifiez l’architecture et le chemin utilisés par le terminal avant d’installer les dépendances du projet. Pour un projet d’équipe, réutilisez de préférence la liste des dépendances et le fichier de verrouillage existants afin d’éviter les changements de version à chaque location.
command -v brew
brew --version
git --version
ruby --versionLes commandes de version ne fonctionnent que si les outils correspondants sont installés.
Importez les certificats de signature et les profils de provisionnement depuis un canal sécurisé approuvé par votre équipe. Accordez uniquement les autorisations nécessaires à la tâche et stockez les mots de passe des certificats dans un gestionnaire de secrets contrôlé, jamais dans le dépôt de code.
Effectuez d’abord manuellement un build signé et vérifiez la validité du certificat, l’identifiant de la cible et la concordance du profil de provisionnement. Si l’automatisation échoue, déterminez d’abord s’il s’agit d’un problème de compilation ou d’autorisations de signature.
À la fin du projet, supprimez les copies de certificats et les fichiers temporaires dont vous n’avez plus besoin.
Si le projet contient un Gemfile, installez les dépendances aux versions verrouillées, puis exécutez le lane existant avec bundle exec fastlane. Faites d’abord un build local avant d’activer les déclencheurs d’intégration continue.
Définissez un répertoire de travail et un niveau de parallélisme clairs pour le runner. Vérifiez que les résultats du build ne révèlent ni clés, ni mots de passe, ni éléments de signature, puis transférez les artefacts réussis vers votre propre espace de stockage.
bundle install
bundle exec fastlane --version
bundle exec fastlane lanesCes commandes s’adressent aux projets déjà configurés avec un Gemfile et Fastlane.
Pour valider votre environnement le premier jour, utilisez un vrai projet : récupérez ses dépendances, effectuez un build, exportez les artefacts, transférez-les vers votre propre espace de stockage, puis vérifiez l’accès depuis une nouvelle session. Voir le numéro de version des outils ne suffit pas à garantir un build reproductible.
Utilisez votre Mac dans le cloud pour exécuter des tâches, pas comme unique espace de stockage pour vos fichiers importants. Pour la durée de location, son renouvellement et les modifications de commande, fiez-vous aux informations affichées dans le portail.
Synchronisez les modifications du code source, les artefacts de build et les configurations indispensables vers votre propre espace de stockage. Le cache peut être recréé ; une copie unique d’un certificat, du code non commité ou des résultats d’expérimentation ne doit pas rester uniquement sur le serveur.
Ouvrez un fichier transféré pour vérifier la sauvegarde.
Consultez les rappels d’expiration dans le portail et planifiez le renouvellement ou la sauvegarde en fonction des tâches restantes. Avant un long build, un transfert de ressources ou une expérimentation avec des modèles, vérifiez la durée de location restante au lieu d’attendre la fin de la tâche.
Ne comptez pas sur la conservation des données après expiration comme solution de sauvegarde.
Pour continuer à utiliser le service, ouvrez la commande correspondante dans le portail afin de la renouveler. Pour passer à une configuration supérieure, vérifiez d’abord la procédure, la méthode de migration des données et le détail des frais.
Un changement de modèle ne transfère pas automatiquement les fichiers vers le nouveau serveur.
Arrêtez de lancer de nouvelles tâches CI et laissez les tâches en cours se terminer. Exportez les fichiers importants et vérifiez-les, révoquez les clés d’accès et les jetons temporaires, puis supprimez les données sensibles. Vérifiez dans votre commande les modalités de conservation et de suppression des données ; ne planifiez pas votre travail en vous basant sur un délai non confirmé.
Une fois les vérifications de base terminées, optimisez l’accès à distance et vos builds. En cas de problème, indiquez le modèle, le serveur, l’heure et le message d’erreur dans un ticket depuis le portail. N’y joignez ni mot de passe ni clé privée.
Choisissez SSH ou le partage d’écran selon vos besoins, puis préparez le transfert de fichiers. Vérifiez d’abord l’hôte, le port et les identifiants. Si une seule méthode échoue, contrôlez séparément les réglages du client et le service correspondant.
Adaptez le nombre de runners, le répertoire de cache et le stockage à votre projet. Validez une tâche de bout en bout avant d’étendre l’automatisation : changer simultanément la chaîne d’outils, le modèle et la configuration des tâches complique le diagnostic.
Choisissez un modèle, un serveur et une durée. Après confirmation du paiement, récupérez vos identifiants dans le portail. Commencez par exécuter les tâches du jour, puis décidez de la durée de votre renouvellement.