Vous louez un Mac mini physique dédié, pas une machine virtuelle. Le CPU, le GPU, la mémoire unifiée et le stockage ne sont pas partagés avec d’autres locataires. Votre équipe gère le code source, les certificats et les artefacts de build selon ses propres règles.
Commencez par définir à qui appartient chaque ressource, configurez les droits d’accès, puis organisez les sauvegardes et la fin de location.
L’isolation physique empêche le partage de ressources entre locataires. Au sein du système, votre équipe doit toujours gérer les droits des utilisateurs, des processus, des tâches CI et des secrets. Distinguez ces deux niveaux pour appliquer des règles de sécurité claires.
Les builds, les simulateurs et les tâches d’inférence s’exécutent sur le nœud physique qui vous est attribué. Les ressources de calcul ne sont pas partagées avec d’autres locataires et vos tâches ne sont pas limitées par un quota de machine virtuelle.
Machine dédiéeLa mémoire unifiée et le stockage du nœud font partie de votre environnement de travail pendant la location. Les répertoires de projet, DerivedData, le trousseau et le cache du runner ne sont pas des espaces de travail partagés accessibles à d’autres locataires.
Isolation entre locatairesLe fait d’avoir une machine dédiée ne signifie pas que tous les membres de l’équipe doivent partager les identifiants administrateur. Séparez les comptes système des développeurs et des builds automatisés, limitez les répertoires accessibles au runner et ne donnez pas les secrets de production à toutes les tâches de build.
Droits selon les rôlesDistinguez la réinitialisation du système, l’effacement sécurisé et la sauvegarde de votre activité. Les deux premières étapes établissent une séparation entre locataires ; la sauvegarde permet de reprendre votre travail et d’utiliser vos certificats sur une autre machine.
Après l’attribution du nœud physique, le système est réinitialisé pour créer un nouvel environnement de location. À la réception des informations de connexion, vérifiez l’identifiant de l’instance et la version du système avant d’importer votre code et vos certificats. Ne réutilisez pas directement des mots de passe partagés avec un autre environnement.
Vous pouvez lancer une réinstallation du système depuis la console. Elle peut affecter les fichiers locaux et la configuration de développement : exportez les données à conserver, arrêtez les builds en cours et vérifiez que votre équipe n’a aucune tâche dépendant de ce nœud avant de procéder.
À la fin de la location, le nœud fait l’objet d’un effacement sécurisé avant d’entrer dans le processus de réattribution. Exportez vos données avant l’échéance : ne comptez ni sur la conservation du disque après expiration ni sur la récupération des fichiers comme solution de sauvegarde.
SSH, le bureau graphique et la console sont des points d’accès distincts. Gérez leurs identifiants séparément et révoquez-les individuellement en cas de départ, de transfert ou de fin de tâche. N’utilisez pas le même mot de passe pour tous les accès.
Utilisez une clé distincte pour chaque membre et chaque tâche automatisée. Vérifiez l’empreinte de l’hôte lors de la première connexion et contrôlez la liste des clés autorisées lors d’un transfert. Quand un membre quitte l’équipe, supprimez également sa clé publique.
Ne déposez pas de clé privée dans le dépôt de code et ne l’inscrivez pas dans les journaux de build.
Protégez le bureau graphique par un mot de passe robuste et unique. Sur les nœuds qui n’exécutent que des builds en ligne de commande, vous pouvez désactiver VNC depuis Internet. Si une interface graphique est nécessaire, configurez les accès en fonction des besoins réels.
Après avoir changé le mot de passe, vérifiez quels clients utilisent encore l’ancien identifiant.
Le compte de la console permet de gérer les instances et la facturation. Suivez les demandes de vérification en deux étapes lors de la connexion et des opérations sensibles. Protégez la boîte mail qui reçoit les codes et ne les transférez pas à d’autres membres.
Utilisez votre propre compte pour les opérations d’administration et évitez les sessions partagées.
Ne laissez pas une demande de fusion externe non vérifiée accéder directement au trousseau de signature ou aux identifiants de publication. Séparez les tâches de test et de publication ; pendant la publication, ne donnez accès aux secrets nécessaires qu’aux branches de confiance.
Les étiquettes du runner servent à planifier les tâches, pas à autoriser leur accès.
Tous les nœuds fonctionnent toute l’année, 365 jours par an. L’engagement de disponibilité concerne le service : il ne garantit ni la réussite des builds d’un projet ni un débit identique pour chaque connexion via Internet.
Engagement de disponibilité mensuelle
99.9%
Si la disponibilité mensuelle passe sous 99,9 %, la compensation prend la forme d’un crédit de location calculé au prorata de la durée d’indisponibilité.
Les 13 périodes ci-dessous indiquent uniquement la plage couverte par les relevés ; elles ne représentent ni des jours de fonctionnement ni des jours de panne. Cette page n’affiche pas d’état quotidien non vérifié et ne présente pas l’engagement de service comme un résultat mesuré.
Dans un ticket de la console, indiquez l’identifiant de l’instance, les heures de début et de fin de l’incident avec le fuseau horaire, le mode de connexion et le message d’erreur. Joignez des journaux expurgés des données sensibles pour faciliter la vérification de la durée d’indisponibilité du service.
Les incidents de service sont examinés séparément des problèmes dus à vos propres opérations, aux échecs de projet ou à des cas de force majeure. L’évaluation s’appuie sur les conditions de service ; le graphique des périodes couvertes ne sert pas à calculer la compensation.
Seuls les deux types de paiement ci-dessous sont acceptés ; tous les paiements sont réglés en dollars américains (USD). Les moyens effectivement disponibles dépendent de la réponse de l’interface de paiement. Vérifiez le statut dans les commandes de la console : une capture d’écran d’un e-mail ou un message du navigateur ne fait pas foi.
Les paiements par carte sont traités par Stripe ; MergeMac ne stocke pas les numéros de carte. Effectuez le paiement dans le parcours de commande. N’envoyez jamais par e-mail ou dans un ticket votre numéro de carte complet, votre cryptogramme ou des informations de vérification de paiement.
Traité par StripeEffectuez le transfert sur le réseau, à l’adresse et pour le montant indiqués dans votre commande. Une fois la transaction confirmée sur la blockchain, vérifiez le statut de la commande. Pour toute vérification de paiement, fournissez l’identifiant de commande et le hash de transaction, jamais la clé privée ni la phrase de récupération de votre portefeuille.
Vérification de la transaction sur la blockchainLe code source peut être récupéré ; les secrets, eux, ne se restaurent pas par déduction. Intégrez à votre procédure de transfert les règles concernant les personnes autorisées à importer les certificats, les tâches pouvant les déverrouiller et le moment où les révoquer. Vous éviterez ainsi de découvrir à l’échéance que vos certificats ne disposent d’aucune sauvegarde exploitable.
Créez un trousseau distinct pour la signature CI et n’y importez que les certificats et les clés privées nécessaires au projet en cours. Déverrouillez-le uniquement pendant le build, puis verrouillez-le à la fin de la tâche. Ne donnez pas à toutes les sessions interactives accès aux éléments de publication.
Stockez les valeurs sensibles dans les variables secrètes chiffrées de votre plateforme CI et limitez leur accès aux branches protégées ou aux environnements de publication. Désactivez les commandes de débogage susceptibles d’afficher des secrets. Avant de partager des journaux, vérifiez qu’ils ne révèlent aucun jeton, chemin ou variable d’environnement sensible.
Avant la fin de la location ou une réinstallation, exportez les éléments de signature à conserver et chiffrez-les hors du nœud. Après avoir vérifié la sauvegarde, désenregistrez le runner et révoquez les jetons et les clés de connexion qui ne sont plus utilisés.
En cas de fuite d’identifiants, de connexion suspecte ou de suspicion d’accès non autorisé, révoquez d’abord les clés et les jetons concernés et restreignez les accès affectés. Conservez les journaux nécessaires, n’étendez pas les tests et ne consultez ni ne diffusez les données d’autres utilisateurs.
Pour signaler en priorité un problème lié à une commande existante, ouvrez un ticket dans la console. Indiquez l’identifiant de l’instance, la date et l’heure avec le fuseau horaire, les mesures déjà prises pour limiter les risques et le minimum d’étapes nécessaires pour reproduire le problème.
Se connecter et ouvrir un ticketEnvoyez votre signalement à support@mergemac.com avec « Signalement de sécurité » en objet. Commencez par un résumé expurgé des données sensibles. N’ajoutez en pièce jointe ni clé privée de certificat, ni code de vérification, ni mot de passe de connexion complet, ni secret de portefeuille.
Contacter l’assistance sécurité par e-mailNous examinons les signalements de sécurité en priorité selon le niveau de risque et l’étendue de l’impact, puis vous informons du suivi dans le ticket ou par e-mail. Une première réponse ne signifie pas que le problème est résolu. Conservez le même fil de discussion et ajoutez-y tout nouvel élément pour éviter de fragmenter le contexte en plusieurs signalements.
Le nœud physique dédié isole les ressources ; la sécurité de votre charge de travail dépend de la gestion des accès, des sauvegardes et des certificats. Lorsque vous êtes prêt, choisissez la durée de location qui vous convient.