Mieten Sie einen dedizierten physischen Cloud-Mac und integrieren Sie Ihr bestehendes Repository, Ihre Toolchain und Ihre Build-Pipeline. Diese Anleitung folgt der empfohlenen Reihenfolge. Wenn Repository und Build-Skripte bereits vorhanden sind, sollten Sie für die Migration etwa 30–60 Minuten einplanen; Datenübertragung und Xcode-Download kommen hinzu.
Sie haben bereits eine Instanz? Melden Sie sich an der Konsole an, um die Verbindungsdaten einzusehen. Die Befehle und Ausgaben unten dienen als Beispiele. Die tatsächlichen Adressen und Zugangsdaten finden Sie in der Konsole.
Legen Sie bei der Bestellung drei Dinge fest: Das Modell bestimmt die Ressourcen für Builds und parallele Jobs, der Standort beeinflusst die Latenz bei der Fernsteuerung und der Abrechnungszeitraum die Nutzungsdauer. Alle drei Modellklassen bieten einen vollständig dedizierten Rechner statt einer virtuellen Maschine. Der aktuelle Verfügbarkeitsstatus wird in der Konsole angezeigt.
ZSH 16 eignet sich, um zunächst einen einzelnen Build-Workflow zu testen. Für parallele Builds oder einen dauerhaft verfügbaren Runner kommt ZSH 24 infrage. Wenn Sie für MLX-Experimente mehr Unified Memory benötigen, sehen Sie sich ZSH Pro 64 an. Wählen Sie anschließend den Standort passend zum hauptsächlichen Verbindungsort Ihres Teams.
Prüfen: Modell, SSD-Kapazität, Standort und Laufzeit (Tag/Woche/Monat/Quartal).
Zahlung mit USDT-TRC20 oder per Stripe mit Visa / Mastercard / Amex. Prüfen Sie vor einer USDT-Überweisung das TRC20-Netzwerk. Kartenzahlungen wickeln Sie über das Gateway auf der Checkout-Seite ab.
Prüfen: Zahlungsergebnis und Bestellstatus in der Konsole. Welche Gateways verfügbar sind, richtet sich nach der Rückmeldung des Backends.
Notieren Sie nach der Bereitstellung der Instanz in der Konsole die Verbindungsadresse, den Benutzernamen, die Zugangsdaten für die erste Anmeldung und den Host-Fingerprint. Speichern Sie diese Informationen nicht im Repository, in Build-Logs oder in allgemein zugänglichen Teamdokumenten.
Prüfen: SSH-Anmeldung möglich und macOS-Schreibtisch erreichbar.
Sorgen Sie zuerst dafür, dass sich ein Repository auf dem neuen Rechner eigenständig erfolgreich bauen lässt. Binden Sie erst danach automatisierte Jobs an. So können Sie Fehler leichter auf fehlende Daten, abweichende Toolversionen oder die Runner-Konfiguration zurückführen.
Übertragen Sie Ihr Repository mit rsync oder klonen Sie es erneut aus einer verwalteten Remote-Quelle. Übertragen Sie Zertifikate, Provisioning-Profile und Schlüsselbund-Exporte jeweils verschlüsselt. Legen Sie private Schlüssel nicht in einem gewöhnlichen Synchronisationsordner ab.
Richtwert für die manuelle Prüfung: 10–20 Minuten; die Übertragungsdauer hängt von der Datenmenge ab.
Installieren Sie Kommandozeilen-Abhängigkeiten mit Homebrew und verwalten Sie die benötigten Xcode-Versionen des Projekts mit xcodes. Prüfen Sie zuerst, wohin xcode-select zeigt. Synchronisieren Sie anschließend die benötigten Abhängigkeiten für fastlane, CocoaPods und SPM.
xcodebuild -version und die vom Projekt benötigte Version.Richtwert für die manuelle Prüfung: 10–20 Minuten; Software-Downloads kommen hinzu.
Binden Sie den Rechner in Ihren bestehenden GitHub-Actions- oder GitLab-Runner-Workflow ein. Folgen Sie den Registrierungsschritten Ihres Repositorys oder Ihrer Organisation und führen Sie Build-Jobs unter einem dedizierten Systemkonto aus.
Richtwert für die manuelle Prüfung: 10–20 Minuten; der erste Job kommt hinzu.
Diese Zeitangaben dienen nur der Planung manueller Prüfungen und sind keine Zusage für Bereitstellungs- oder Downloadzeiten. Wenn Ihr Build viele Caches benötigt, migrieren Sie zuerst reproduzierbare Konfigurationen und entscheiden Sie anschließend, ob Cache-Dateien übertragen werden sollen.
Die folgenden Terminalausgaben sind Beispiele und zeigen weder eine echte Instanzadresse noch einen echten Fingerprint oder ein tatsächliches Build-Ergebnis. Ersetzen Sie die Beispieladresse und das Scheme durch die Werte aus der Konsole und Ihrem Projekt. Vergleichen Sie beim ersten SSH-Zugriff den angezeigten Host-Fingerprint Zeichen für Zeichen mit dem Eintrag in der Konsole.
Verbindung und Fingerprint prüfen
zsh % ssh -o StrictHostKeyChecking=ask mac@203.0.113.10
The authenticity of host '203.0.113.10' can't be established.
Host key verification required before continuing.Build prüfen
zsh % xcodebuild -version
Xcode 16.2
zsh % xcodebuild -scheme App -configuration Release build
** BUILD SUCCEEDED **Distributionsprozess prüfen
zsh % fastlane beta
Running lane 'beta'
Archive complete
Upload to TestFlight completeSSH eignet sich zum Installieren von Abhängigkeiten, Abrufen von Code und Ausführen von Builds. Für Xcode-Einstellungen, Simulatoren und grafische Tools verwenden Sie die macOS-Bildschirmfreigabe. Die Adresse und Zugangsdaten für die Bildschirmfreigabe Ihrer Instanz finden Sie in der Konsole. Stellen Sie die Verbindung über den Bildschirmfreigabe-Client Ihres lokalen Rechners her.
Prüfen Sie nach dem ersten Aufruf des Schreibtischs, ob Auflösung und Skalierung für Ihre Netzwerkverbindung passen. Wenn die Fernsteuerung verzögert reagiert, reduzieren Sie zunächst die Auflösung und deaktivieren Sie unnötige Animationen. Vergleichen Sie anschließend die Verbindung über verschiedene Netzwerke. Synchronisieren Sie über die Zwischenablage nur unkritische Texte. Für Zertifikate und private Schlüssel verwenden Sie einen separaten, kontrollierten und verschlüsselten Übertragungsweg.
Eine erfolgreiche Verbindung bedeutet noch nicht, dass die Übergabe abgeschlossen ist. Erledigen Sie die vier folgenden Punkte, bevor Sie die Instanz in eine dauerhaft laufende CI einbinden. Das Team, das den Rechner tatsächlich nutzt, sollte jeden Punkt bestätigen – verlassen Sie sich nicht allein auf einen Screenshot einer erfolgreichen Anmeldung.
softwareupdate -l aus, um nach Updates zu suchen. Sichern Sie vor Upgrades, die sich auf die Build-Umgebung auswirken, Ihre Daten und prüfen Sie die Kompatibilität mit Xcode und Ihrem Projekt.
Start- und Enddatum des aktuellen Zeitraums, Rechnungen und Verlängerungsmöglichkeiten finden Sie auf der Bestellseite der Konsole. Maßgeblich für Erinnerungen zum Ablauf sind ebenfalls die Konsole und tatsächlich zugestellte Servicebenachrichtigungen – verlassen Sie sich nicht nur auf lokale Kalendereinträge. Wenn Sie die Instanz weiter nutzen möchten, prüfen Sie Modell, Standort, Laufzeit und Betrag in der Konsole, bevor Sie verlängern.
Sichern Sie vor dem Ende der Nutzung nicht gepushte Änderungen im Repository, Signaturmaterial, Build-Artefakte und erforderliche Audit-Protokolle. Prüfen Sie auf einem anderen Gerät, ob sich das Backup öffnen lässt, und geben Sie die Instanz anschließend über die Konsole frei. Danach werden die Festplatte gelöscht und das System neu installiert. Die Freigabe ersetzt kein Backup.
Wenn Sie SSH, VNC und Ihre tägliche Entwicklungsumgebung genauer einrichten möchten, suchen Sie in der Artikelsammlung nach Anleitungen für Remote-Mac-Entwicklungsumgebungen. Für Build-Parameter, Caches und die Runner-Konfiguration finden Sie weitere Informationen in der Anleitung zu Xcode Cloud-Builds. Bei Problemen mit der Instanz oder der Rechnung wenden Sie sich an den technischen Support.
Erfahren Sie mehr über SSH-Schlüssel, die Ersteinrichtung von Homebrew, Bildschirmfreigabe und den Fernzugriff über Ihre Entwicklungsumgebung.
Prüfen Sie Xcode-Versionen, Build-Caches, Testbefehle und die Anbindung eines Self-hosted Runners.
Bei Verbindungsfehlern, Problemen mit der Build-Umgebung oder Fragen zur Verlängerung helfen die Schritte zur Fehlerbehebung weiter. Eröffnen Sie anschließend über die Konsole ein Support-Ticket.
Wählen Sie zunächst Modell, Standort und Laufzeit. Sobald Ihre Instanz bereitsteht, folgen Sie dieser Anleitung, um Verbindung, Migration und Prüfung abzuschließen.