Commencez par retrouver vos identifiants, puis configurez l’accès par clé et lancez votre premier build. Ce guide suit l’ordre des étapes pour intégrer un Mac dans le quotidien de votre équipe.
Vous disposez d’un serveur physique dédié, et non d’une machine virtuelle. L’interface graphique macOS et la ligne de commande sont entièrement disponibles.
Commandez et mettez en service votre serveur le jour même. Voici le déroulement habituel, pour un total d’environ 4 minutes. Fiez-vous aux informations actualisées de la console pour le paiement et l’état du serveur. Ne créez pas une deuxième commande après avoir payé.
Choisissez parmi nos 4 sites : Singapour, Tokyo, Séoul ou Hong Kong, puis optez pour une facturation à la journée, à la semaine, au mois ou au trimestre. Vérifiez le modèle, les options et la date d’expiration.
Paiement accepté : USDT-TRC20 et Visa / Mastercard / Amex via Stripe. Toutes les transactions sont en dollars américains. Les moyens de paiement disponibles sont ceux indiqués par l’interface côté serveur.
Attendez que le serveur physique soit attribué et que la préparation du système soit terminée avant de vous connecter. Si votre commande est payée mais que l’instance est encore en préparation, vérifiez son état : elle n’est pas encore prête, ce n’est pas forcément un problème réseau.
Connectez-vous à la console, ouvrez la liste des instances, puis les détails du serveur associé à votre commande. Vous y trouverez l’adresse de l’hôte, le port SSH et le nom d’utilisateur. Fiez-vous aux informations affichées et vérifiez le numéro du serveur avant de vous connecter.
Total : environ 4 min. Si vous ne pouvez toujours pas consulter vos identifiants après le paiement, ouvrez un ticket depuis la console en indiquant le numéro de commande et l’état actuel. Ne publiez jamais vos identifiants complets, votre clé privée ni les informations de votre carte bancaire.
Voici des extraits de commandes pour un serveur à Tokyo : connexion SSH, vérification des SDK, archivage et envoi. Remplacez le nom d’hôte par la valeur appropriée, et adaptez le workspace, le scheme et le nom du processus fastlane à votre projet. Il ne s’agit ni d’un test de performances ni d’un journal de commande réel.
$ ssh -v -i ~/.ssh/minissh_ed25519 -p "$NODE_SSH_PORT" "$NODE_USER@$NODE_HOST"
debug1: Server host key: ssh-ed25519 SHA256:…
debug1: Authentication succeeded (publickey).
Authenticated using publickey.
Welcome to your Mac mini.
$ xcodebuild -showsdks
iOS SDKs:
iOS -sdk iphoneos
$ xcodebuild -workspace App.xcworkspace -scheme App -archivePath build/App.xcarchive archive
** ARCHIVE SUCCEEDED **
$ fastlane upload
Uploading build to App Store Connect
Upload completePremière connexion SSH :Commencez par définir NODE_HOST,NODE_USER et NODE_SSH_PORT avec les valeurs indiquées dans les détails du serveur. Lors de la première connexion, vérifiez l’empreinte de la clé de l’hôte. Si vous ne pouvez pas la confirmer, demandez vérification via un ticket au lieu d’ignorer le contrôle d’identité de l’hôte.
Premier build :Commencez par exécuter xcodebuild -version et xcodebuild -showsdkspour noter les versions des outils utilisés. Préparez les dépendances du projet, les éléments de signature et la configuration de build avant de lancer l’archivage ;fastlane upload ne peut être utilisé que si le projet définit le processus correspondant et que les droits d’envoi sont configurés.
Vérifier chaque étape :Une connexion SSH réussie ne garantit pas que le projet peut être compilé ; un archivage réussi ne signifie pas que l’envoi est terminé. Conservez séparément les résultats de la connexion, de l’archivage et de l’envoi pour identifier précisément l’étape qui pose problème.
Attribuez à chacun une clé publique et ne partagez jamais la même clé privée avec toute l’équipe. Avant de modifier les paramètres d’authentification, gardez votre session ouverte et vérifiez qu’une nouvelle connexion fonctionne depuis un autre terminal. Fermez ensuite la session initiale.
Exécutez la commande ci-dessous sur votre ordinateur et protégez votre clé privée par une phrase secrète. Seul le fichier de clé publique .pub peut être téléversé ou distribué ; la clé privée, sans extension, doit rester sur votre ordinateur.
ssh-keygen -t ed25519 -f ~/.ssh/minissh_ed25519Ajoutez la clé publique au fichier de l’utilisateur concerné sur le serveur : ~/.ssh/authorized_keys. Une clé par ligne. Vous pouvez la transmettre via une connexion existante et vérifiée, puis contrôler les permissions du dossier et du fichier.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysOuvrez un autre terminal et testez la connexion en spécifiant explicitement la clé privée. Vérifiez que vous êtes connecté au bon utilisateur et au bon serveur avant de modifier les paramètres d’authentification.
Une personne disposant des droits d’administration doit vérifier la configuration effective du service SSH et définir PasswordAuthentication et KbdInteractiveAuthentication sur no. Après modification, vérifiez la syntaxe et les valeurs réellement appliquées afin de vous assurer qu’aucune autre configuration ne les remplace.
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E 'passwordauthentication|kbdinteractiveauthentication'Appliquez la configuration selon la méthode de gestion des services de votre système, puis testez à nouveau une nouvelle connexion. En cas de doute, ouvrez d’abord un ticket. Ne redémarrez pas le service et ne désactivez pas l’accès à distance depuis votre seule session active.
Après avoir vérifié que le partage d’écran est configuré sur le serveur et que l’utilisateur dispose des droits nécessaires, créez un tunnel SSH en local. Dans cet exemple, le port local 15900 est redirigé vers le port de l’adresse de bouclage du serveur 5900 , sans ouvrir de port sur le réseau local.
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:127.0.0.1:5900 -i ~/.ssh/minissh_ed25519 -p "$NODE_SSH_PORT" "$NODE_USER@$NODE_HOST"Connectez ensuite votre client de bureau local à 127.0.0.1:15900. La connexion sera interrompue à la fermeture du terminal du tunnel. Si SSH fonctionne mais que le bureau ne se connecte pas, vérifiez d’abord le service de partage d’écran sur le serveur, sans exposer directement le port du bureau.
Un serveur physique dédié vous est réservé, mais les tâches de plusieurs utilisateurs ne sont pas automatiquement isolées. Si des membres en Amérique du Nord et en Asie-Pacifique utilisent le même serveur Mac mini, créez d’abord des comptes distincts, convenez des créneaux de build, puis consignez clairement les transmissions.
Créez un compte macOS par membre et ajoutez uniquement sa clé publique. Utilisez un compte standard pour le développement quotidien ; les modifications système sont à confier à la personne désignée comme administrateur.
Lorsqu’un membre quitte l’équipe, supprimez ses autorisations et vérifiez les jetons d’accès enregistrés dans les outils de build. Ne vous contentez pas de changer un mot de passe partagé.
Choisissez un fuseau horaire de référence pour les créneaux de build. Avant de lancer un archivage en Asie-Pacifique, vérifiez qu’aucune tâche d’un collègue d’Amérique du Nord n’est en cours. Évitez autant que possible de lancer simultanément un gros archivage, l’installation de dépendances et une mise à jour système.
Séparez les répertoires du projet et de sortie par utilisateur ou par branche afin que personne ne supprime les artefacts de build d’un autre.
Avant de passer le relais, notez la version du code, la version de Xcode, les commandes exécutées et leur résultat. Si vous devez modifier les outils, prévenez le membre qui prend le relais sur l’autre fuseau horaire pour éviter les mauvaises surprises.
Les performances du bureau à distance varient selon les réseaux de chacun. Pour les tâches longues, privilégiez SSH et conservez les journaux de build pour pouvoir les consulter à nouveau.
Vous pouvez distinguer les tâches récurrentes des besoins ponctuels. Chaque nouveau serveur fait l’objet d’une location indépendante et ne récupère pas automatiquement le code, les dépendances, les clés ni les artefacts de l’ancien. Préparez d’abord l’environnement, puis répartissez les tâches.
Commandez un serveur supplémentaire depuis la page de commande et choisissez une durée adaptée à vos besoins : jour, semaine, mois ou trimestre. Deux modèles sont disponibles : MiniSSH M4 Core (M4 / 16 Go de RAM / SSD 256 Go) et MiniSSH M4 Plus (M4 / 24 Go de RAM / SSD 512 Go). Consultez la page des offres pour les tarifs détaillés et les options.
Transférez le code et les dépendances nécessaires au projet, puis configurez séparément les accès sur le nouveau serveur. Commencez par un build reproductible et vérifiez que vous pouvez récupérer les artefacts avant d’y transférer d’autres branches ou des tâches en masse. Ne conservez pas votre seule sauvegarde sur un serveur temporaire.
Vérifiez la date d’expiration du serveur temporaire dans la console et ne le renouvelez pas. Si une option de renouvellement automatique est proposée, assurez-vous qu’elle est désactivée. À l’échéance, la location s’arrête sans frais de désactivation. Avant cette date, exportez les artefacts et les journaux, puis révoquez les jetons d’accès pour ne pas perdre de fichiers lors de la récupération du serveur.
Les serveurs restent en ligne 365 jours par an. En cas de problème, ouvrez un ticket dans la console et ajoutez-y les nouvelles informations au fur et à mesure. Évitez de réinstaller le système, de modifier plusieurs fois la configuration ou de repayer : ces actions compliquent l’analyse de l’incident.
| Problème rencontré | Premiers points à vérifier | Informations à joindre au ticket |
|---|---|---|
| Impossible de se connecter en SSH | Le serveur est-il prêt ? L’adresse, le port et le nom d’utilisateur correspondent-ils aux détails du serveur ? S’agit-il d’un délai d’attente, d’un refus de connexion ou d’un échec d’authentification ? Conservez le type d’erreur complet. | Numéro du serveur, ville, date et heure de début du problème avec fuseau horaire, réseau utilisé et sortie d’erreur SSH après suppression des informations sensibles. |
| Build bloqué ou en échec | Vérifiez l’espace disque, les autres tâches en cours sur le serveur et les changements récents d’outils ou de dépendances. Distinguez l’absence de nouveaux journaux d’un arrêt effectif du processus. | Commande exécutée, version de Xcode, heure de début, derniers journaux, code de sortie et possibilité de reproduire le problème de façon fiable. |
| Réinstallation du système nécessaire | Sauvegardez le code, les artefacts de build et les configurations nécessaires. Notez l’environnement à conserver ou à reconfigurer. Une réinstallation affecte les données déjà présentes sur le serveur. | Numéro du serveur, motif de réinstallation, confirmation de la sauvegarde et créneau disponible. Organisez l’intervention après avoir confirmé son périmètre dans un ticket. |
| Question sur un paiement ou un renouvellement | Consultez l’état de la commande et de la facture concernées, puis vérifiez à quel serveur correspond l’opération pour éviter de payer deux fois une autre commande. | Numéro de commande ; pour un paiement USDT-TRC20, joignez le hash de transaction. Pour un paiement par carte via Stripe, indiquez le numéro de commande et l’erreur affichée. N’envoyez pas le numéro complet de votre carte. |
Indiquez toujours le fuseau horaire :« 14 h 30, heure locale (UTC+8) » est plus facile à vérifier que « impossible de se connecter dans l’après-midi ». Si votre équipe est répartie entre l’Asie-Pacifique et l’Amérique du Nord, précisez aussi les horaires auxquels vous joindre.
Suivez l’avancement dans le ticket initial :Connectez-vous à la console, ouvrez la liste des tickets, puis la demande concernée pour consulter les réponses et ajouter des informations. Si vous ne pouvez pas vous connecter, envoyez un e-mail à support@minissh.comen indiquant l’adresse e-mail de votre compte et le numéro de commande concerné. N’envoyez ni mot de passe ni clé privée.
Pour approfondir un sujet, consultez les articles techniques sur les trois thèmes ci-dessous. Les commandes de cette page illustrent l’ordre des opérations ; vérifiez les répertoires, les autorisations et les versions des outils en fonction de votre environnement.
Découvrez la gestion des comptes, les répertoires de projet, la préparation des dépendances et le relais entre fuseaux horaires. Commencez par créer un environnement reproductible avant d’y faire accéder le reste de l’équipe.
Découvrez l’authentification par clé publique, la désactivation des mots de passe et la redirection de ports en local. Avant de modifier les paramètres de sécurité, gardez toujours une connexion déjà vérifiée.
Découvrez la vérification des SDK, les paramètres d’archive et les processus fastlane. Vérifiez séparément l’archivage et l’envoi : une seule réussite ne garantit pas que tout le processus est fiable.
Louez à la journée à partir de $20.8/jour. Vous avez déjà un serveur ? Consultez vos identifiants dans la console. Sinon, choisissez un serveur adapté à la durée de votre projet.