Cette page répond aux questions sur les modèles, les régions, la facturation, les connexions, les autorisations et la fin de location. Chaque commande correspond à un nœud physique Apple Silicon dédié, sans partage des ressources de calcul.
Clarifions d’abord les ressources : OrbVPS fournit des nœuds physiques Apple Silicon dédiés, et non des machines virtuelles découpées par quota.
Chaque commande valide correspond à un Mac physique doté d’une configuration définie. Le processeur, la mémoire et le disque système ne sont pas attribués à d’autres locataires pendant la location, et la machine n’est pas divisée en plusieurs instances virtuelles. Les informations matérielles, la charge système et la température proviennent directement du nœud.
Les nœuds sont déployés dans une infrastructure distante et fournissent, via le réseau, une ligne de commande SSH et une interface graphique VNC. Les équipes peuvent ainsi exécuter Xcode, des scripts de build, un self-hosted runner, des tests automatisés et des tâches de modèles locaux adaptées à la configuration, sans installer la machine au bureau.
Non. Le service fournit une machine physique dédiée. Le système fonctionne sur du matériel Apple Silicon réel, sans instances virtuelles sur un hôte partagé. Pour tester plusieurs systèmes, planifiez les disques, les toolchains et les bases de repli sur le nœud au lieu de supposer que des instantanés de machine virtuelle peuvent être clonés à volonté.
Les usages courants incluent les builds Xcode continus, les tests automatisés iOS et macOS, les builds React Native, les self-hosted runners, le montage à distance et les petites expériences d’IA. Le nœud convient aux tâches nécessitant la conservation des dépendances, caches, certificats et journaux de build, mais pas à l’exposition directe de scripts à haut risque non évalués sur Internet.
Le catalogue disponible comprend uniquement les trois configurations suivantes. La mémoire et le stockage intégré sont fixes ; le stockage supplémentaire se choisit séparément à la commande.
Convient aux builds Xcode sur un seul dépôt, à un CI/CD iOS léger, aux tâches en ligne de commande et aux tests automatisés à faible parallélisme. Estimez l’espace requis par DerivedData, les caches de dépendances et les artefacts de build.
Choisir Orb M4 16Convient aux projets avec de nombreuses dépendances, aux builds React Native de taille moyenne, aux tests parallèles et aux builds continus conservant davantage de cache. Un choix équilibré pour la plupart des pipelines d’équipe stables.
Choisir Orb M4 24Convient aux grands projets, aux builds multitâches, aux tests macOS plus lourds, aux workflows vidéo et aux petites expériences de modèles contrôlées. Vérifiez néanmoins les versions logicielles, le parallélisme et la croissance du disque avant le déploiement.
Choisir Orb M4 ProSingapour, Japon (Tokyo), Corée du Sud (Séoul) et Hong Kong proposent les trois configurations. Toutes les combinaisons du catalogue sont indiquées comme disponibles.
Adapté aux builds et accès à distance pour les équipes collaborant en Asie du Sud-Est. Sélection directe à la commande.
Choisir un nœud à SingapourAdapté aux builds Xcode, aux tests et aux workflows à distance des équipes japonaises et est-asiatiques.
Choisir un nœud au JaponAdapté au déploiement de builds continus et de tests automatisés pour les équipes coréennes et nord-est asiatiques.
Choisir un nœud en CoréeAdapté à la collaboration de développement interrégionale et à l’accès distant entre la Chine méridionale et l’Asie du Sud-Est.
Choisir un nœud à Hong KongPrivilégiez la région la plus proche du dépôt de code, du service CI, du stockage des artefacts et du réseau de vos principaux opérateurs. Avant la migration, testez les allers-retours SSH, la récupération du dépôt et l’envoi d’artefacts ; ne vous fiez pas uniquement à la distance sur la carte.
« Disponible » signifie que la combinaison modèle-région appartient au catalogue généralement commandable. La disponibilité effective lors de la configuration est celle renvoyée en temps réel par la console. Le résultat actuel affiché par la console fait foi.
Un changement de région ne modifie pas l’emplacement du matériel existant. Il faut généralement créer une nouvelle commande dans la région cible, migrer dépôt, toolchain, stratégie de cache et données métier, puis terminer la location du nœud initial après validation. Conservez une sauvegarde de repli pendant la migration.
Tous les prix sont affichés en dollars américains (USD). Avant confirmation, la configuration précise le modèle, la région, la durée et les options supplémentaires.
Idéal pour une validation courte, un build ponctuel ou un test avant migration. Une courte durée ne dispense pas de sauvegarder les données ni de révoquer les identifiants.
Idéal pour une phase d’accélération, une semaine de publication ou des tests de compatibilité sur plusieurs jours, avec moins de validations quotidiennes.
Idéal pour un CI/CD stable, un nœud de build permanent et les workflows d’équipe conservant durablement les caches de dépendances.
Idéal pour les tâches longues sur un modèle, une région et une toolchain déjà validés. Confirmez la planification de capacité et le responsable interne du renouvellement avant de commander.
La console affiche la période de location et son état d’expiration. Si vous souhaitez continuer, renouvelez avant la fin de la période et vérifiez le résultat de la commande. N’attendez pas la limite de période pour contrôler le renouvellement d’un build critique.
Les durées et configurations proposées sont celles renvoyées par la console au moment de l’opération. Vérifiez la nouvelle durée, le modèle, la région et les options avant de confirmer. Une commande déjà créée n’est pas réécrite par les choix ultérieurs.
Le montant de base dépend du modèle et de la durée ; un SSD supplémentaire ou le raccordement Thunderbolt 5 ajoute un supplément calculé sur la même période. Le détail de la configuration s’affiche avant le règlement, en dollars américains (USD).
OrbVPS accepte l’USDT-TRC20 ainsi que Visa / Mastercard / Amex traitées par Stripe. Toutes les commandes sont réglées en dollars américains (USD).
Effectuez le paiement selon les informations de la page de règlement et vérifiez le réseau ainsi que le montant de la commande.
Les paiements par carte sont traités par Stripe ; la passerelle réellement disponible est celle renvoyée par la console.
Non. Les seuls moyens de paiement publics sont l’USDT-TRC20 et Visa / Mastercard / Amex traitées par Stripe. N’envoyez aucun paiement à une adresse ou un compte qui ne figure pas sur la page de commande.
Le modèle, la durée, les options et le total de la commande sont enregistrés et réglés en dollars américains (USD). La page ne convertit pas automatiquement les montants dans une autre devise.
Conservez d’abord le numéro de commande, l’heure et le montant du paiement ainsi que la preuve vérifiable de la transaction, puis connectez-vous à la console pour ouvrir un ticket. N’envoyez jamais de données bancaires complètes ni d’identifiants sensibles non masqués.
Après l’activation, vérifiez l’adresse du nœud, son empreinte hôte et les identifiants d’accès avant de connecter dépôt, outils de build et tâches CI.
Utilisez l’adresse et le port fournis par la console. Lors de la première connexion, vérifiez l’empreinte hôte ; les permissions de la clé privée doivent généralement la rendre lisible uniquement par l’utilisateur courant.
La session graphique convient à l’interface Xcode, aux réglages d’affichage et aux outils nécessitant un bureau. Après une coupure, reconnectez-vous à la session existante afin d’éviter de lancer des processus graphiques inutiles.
Le nœud permet les opérations administrateur nécessaires à l’installation d’outils de développement, à la configuration des services et aux ajustements système contrôlés. Notez la configuration de référence avant toute modification et ne désactivez pas les services d’accès indispensables.
Utilisez pour l’exécuteur un répertoire de travail dédié, des labels explicites et le minimum d’identifiants requis. Après l’intégration, exécutez d’abord une tâche de test contrôlée, puis migrez progressivement le pipeline de production.
Ajoutez d’abord la nouvelle clé publique à la liste autorisée. Dans l’ancienne session, ouvrez un second terminal et vérifiez la connexion avec la nouvelle clé. Supprimez ensuite l’ancienne clé et notez la date de rotation. Ne supprimez pas l’ancienne avant le test, au risque de perdre tout accès distant.
Arrêtez les builds, bases de données ou tâches d’artefacts en écriture, vérifiez que caches et journaux sont bien enregistrés, puis lancez le redémarrage depuis la console. Après le retour, contrôlez successivement SSH, VNC, montages disque, état du runner et versions des outils de build essentiels.
Vérifiez successivement le réseau du nœud, le processus runner, le mode de démarrage du service, les permissions du répertoire de travail, l’état de l’enregistrement et le parallélisme des tâches. S’il reste hors ligne après le redémarrage du service, rassemblez l’identifiant du nœud, la période concernée, l’état du service et les journaux, puis ouvrez un ticket dans la console.
Ces termes influencent directement le choix, la connexion et le diagnostic des builds. Aligner les concepts réduit les échanges inutiles dans les tickets.
Copiez les dépôts de code, artefacts de build, éléments de signature, journaux, fichiers de configuration et index de cache à conserver.
Dans un autre environnement, décompressez ou récupérez un échantillon du contenu essentiel pour confirmer l’intégrité des fichiers, les permissions et la lecture des clés nécessaires.
Supprimez les clés publiques SSH, jetons d’enregistrement du runner, clés de déploiement des dépôts et identifiants temporaires utilisés par les tâches automatisées.
Retirez le nœud des files CI, de la supervision, des envois d’artefacts et des tâches planifiées afin qu’aucun job ne lui soit envoyé après la fin de location.
Un nœud dédié n’est pas une sauvegarde automatique. La stratégie de sauvegarde du code, des clés, des artefacts de build et des données métier doit être établie dès l’activation du nœud.
Non, le contenu du nœud n’est pas considéré comme automatiquement sauvegardé. Selon vos objectifs de restauration, copiez dépôts, configurations, clés, bases de données, artefacts et journaux nécessaires vers un emplacement contrôlé, puis testez régulièrement la restauration.
Au minimum : code non poussé, configurations de signature et de build, artefacts nécessaires du répertoire CI, liste des dépendances, versions d’environnement et journaux de diagnostic. Après l’export, effectuez une vérification de restauration au lieu de vous contenter de confirmer la copie des fichiers.
Les clés de dépôt, jetons de runner et identifiants de service utilisés sur le nœud peuvent encore autoriser l’accès. Après l’export, révoquez-les ou faites-les tourner auprès des services concernés et supprimez les tâches automatisées qui pointent encore vers le nœud.
Après la fin du service, le nœud suit une procédure de révocation des accès et de traitement des données. Vous devez terminer l’export et la vérification avant la fin de la période ; la procédure suivant la location ne constitue pas une solution de récupération. Pour vérifier une commande, connectez-vous à la console et ouvrez un ticket.
Choisissez le modèle, la région et la durée, puis passez commande. Pour une commande existante, connectez-vous à la console et ouvrez un ticket en indiquant l’identifiant du nœud et la période concernée.