Vom ersten Login bis zum Build-Archiv

Verbinden. Migrieren. Losbauen.

Dieser Leitfaden behandelt die erste Verbindung, die Migration der Umgebung, die CI-Integration und die Rückgabe. Prüfen Sie zuerst mit einem SSH-Befehl, ob der Knoten erreichbar ist, und übertragen Sie dann Code, Signaturdaten und Toolchain. Sie erhalten eine exklusive physische Maschine, keine VM, mit vollständigem macOS-Desktop und Terminal.

Schon bestellt? Prüfen Sie zuerst in derKonsoleden Instanzstatus und die Zugangsdaten. Veröffentlichen Sie keine Passwörter, privaten Schlüssel oder Signaturzertifikate in öffentlichen Logs.

Schritt 1 · Verbindung prüfen

Erst verbinden, dann Umgebung migrieren.

Öffnen Sie die Instanzdetails in der Konsole und prüfen Sie Knotenadresse, Benutzername, Port und temporäres Passwort. Ersetzen Sie die Adresse in den folgenden Befehlen durch den tatsächlichen Wert. Verwenden Sie bei abweichendem Port den in den Instanzdetails angegebenen Port.

SSH

Terminal: einmal interaktiv anmelden

Prüfen Sie beim ersten Verbindungsaufbau den Host-Fingerabdruck. Akzeptieren Sie ihn erst, wenn er mit den vertrauenswürdigen Instanzdaten übereinstimmt. Deaktivieren Sie die Host-Key-Prüfung nicht, nur um die Abfrage zu überspringen.

ssh admin@<Knotenadresse>

Verwendet die Instanz einen abweichenden SSH-Port, ergänzen Sie den Befehl um -p <Port>. Führen Sie nach dem Login zuerst diese Prüfungen aus, um aktuellen Benutzer, Systemversion und freien Speicherplatz zu kontrollieren.

whoami
sw_vers
df -h
passwd

passwd ändert das Passwort des aktuellen Benutzers interaktiv. Erzeugen Sie anschließend lokal einen separaten ed25519-Schlüssel und hängen Sie den öffentlichen Schlüssel an ~/.ssh/authorized_keysdes Knotens an. Der private Schlüssel bleibt auf Ihrem eigenen Gerät oder in einem kontrollierten Schlüsselmanagement.

ssh-keygen -t ed25519
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Führen Sie die Berechtigungsbefehle auf dem Knoten aus. Prüfen Sie in einem zweiten Terminal, ob die Anmeldung mit dem Schlüssel funktioniert. Passen Sie danach die Passwortanmeldung gemäß den Sicherheitsrichtlinien Ihres Teams an, damit Sie sich nicht aussperren.

Prüfung: Anmeldung mit Schlüssel in neuem Terminal
VNC

Desktop: interaktive Einrichtung abschließen

Wenn Sie den Schlüsselbund bedienen, Xcode-Einstellungen prüfen oder den Simulator ansehen müssen, verwenden Sie die in den Instanzdetails angegebenen Zugangsdaten für die Bildschirmfreigabe. Verbindungsadresse und SSH-Adresse müssen nicht denselben Port verwenden – übernehmen Sie den Port nicht einfach nach Gefühl.

  1. Prüfen Sie, ob die Instanz bereit ist, und rufen Sie Adresse, Port und Benutzer für die Bildschirmfreigabe in der Konsole ab.
  2. Stellen Sie auf Ihrem lokalen Mac über die Bildschirmfreigabe-App eine Verbindung her und melden Sie sich mit den bereitgestellten Zugangsdaten an.
  3. Ändern Sie nach dem ersten Login am Desktop das temporäre Passwort und prüfen Sie, ob sich der Login-Schlüsselbund entsperren lässt.
  4. Öffnen Sie die benötigte Xcode-Version, bestätigen Sie die Lizenz und installieren Sie erforderliche Komponenten. Prüfen Sie anschließend alles im Terminal.
xcode-select -p
xcodebuild -version

Wenn Sie die Bildschirmfreigabe über einen SSH-Tunnel nutzen, richten Sie lokale Weiterleitung und Zielport entsprechend der tatsächlichen Instanzkonfiguration ein. Erlauben Sie den Zugriff nur von erforderlichen Quellen und machen Sie den Port für die grafische Verbindung nicht für alle zugänglich.

Ein schwarzer Bildschirm bedeutet nicht zwingend, dass der Knoten offline ist. Prüfen Sie zuerst per SSH, ob die Maschine erreichbar ist, und kontrollieren Sie dann grafische Sitzung, Kontoberechtigungen und Verbindungsport. Setzen Sie das System nicht wiederholt auf Verdacht zurück.

Prüfung: Desktop sichtbar, richtige Xcode-Version
Schritt 2 · Abhängigkeiten der Reihe nach migrieren

Lokaler Mac → Cloud-Mac.

Die Reihenfolge lautet: Daten, Toolchain, CI. Migrieren Sie zuerst ein Projekt, das sich unabhängig prüfen lässt. Kopieren Sie nicht gleich das gesamte Benutzerverzeichnis. Die Zeitangaben sind Richtwerte; Repository-Größe, Netzwerk und Downloads beeinflussen den tatsächlichen Ablauf.

01 / Daten

Code und Signierung zuerst

Klonen Sie das Repository mit Git und wechseln Sie zum selben Commit wie auf Ihrem lokalen Rechner. Verwenden Sie für private Repositories einen eingeschränkten Deploy-Schlüssel oder ein kurzlebiges Token. Schreiben Sie keine langfristigen Zugangsdaten in die Repository-URL.

git clone <Repository-Adresse>
git rev-parse HEAD
rsync -av --progress ./Assets/ \
  admin@<Knotenadresse>:~/work/Assets/

Wenn Sie signieren müssen, exportieren Sie aus dem lokalen Schlüsselbund eine Datei mit privatem Schlüssel im Format .p12 und übertragen Sie sie mit einem separaten Passwort verschlüsselt. Importieren Sie die Datei anschließend in den Schlüsselbund des Knotens. Migrieren Sie das Bereitstellungsprofil separat und prüfen Sie Zertifikatslaufzeit, Team und Zielkonfiguration.

Synchronisieren Sie größere Ressourcen inkrementell mit rsync. Verwenden Sie beim ersten Lauf keine Löschoptionen. Prüfen Sie zuerst das Zielverzeichnis, damit keine neu erzeugten Artefakte auf dem Knoten versehentlich gelöscht werden.

Voraussichtlich 3–10 Minuten · ohne große Dateien
02 / Toolchain

Versionen wiederherstellen, Caches nicht kopieren

Exportieren Sie lokal ein Brewfile und übertragen Sie es auf den Knoten, um die Umgebung wiederherzustellen. Lesen Sie die Paketliste vorher durch und entfernen Sie nicht benötigte Desktop-Apps sowie veraltete Abhängigkeiten, damit der erste Download kleiner ausfällt.

brew bundle dump --file=Brewfile
brew bundle --file=Brewfile
xcodes list
xcodes install <benötigte-Version>

Prüfen Sie, welche Versionen von Xcode, Ruby und CocoaPods das Projekt benötigt. Beachten Sie bei der Installation mit xcodes die Lizenzbedingungen und Downloadberechtigungen. Prüfen Sie nach der Installation mit xcodebuild -version welche Version tatsächlich ausgewählt ist.

Bei Projekten mit Gemfile führen Sie bevorzugt bundle exec pod installaus. SPM löst Abhängigkeiten anhand der projektspezifischen Lockdatei auf. Der erste Build dient zum Aufwärmen des Caches und sagt nichts über die Geschwindigkeit späterer Builds aus.

Voraussichtlich 5–15 Minuten · Downloads nicht eingerechnet
03 / CI-Integration

Erst manuell erfolgreich bauen, dann Runner registrieren

Führen Sie zuerst in einer interaktiven Sitzung einen Build mit Signierung durch. Registrieren Sie erst dann einen GitHub Actions self-hosted runner oder GitLab Runner, wenn sich über die Kommandozeile ein Archiv erstellen lässt. So müssen Sie Toolchain und CI-Konfiguration nicht gleichzeitig prüfen.

bundle exec fastlane match development --readonly
bundle exec fastlane gym

Signierungstyp und konkrete Lane für match richten sich nach der Projektkonfiguration. Verwenden Sie in CI eingeschränkte Zugangsdaten und speichern Sie Schlüssel in geschützten Variablen oder einem Schlüsselmanagement – niemals Passwörter direkt im Skript.

Weisen Sie dem temporären Runner ein eigenes Label zu und lassen Sie zunächst nur vertrauenswürdige Branches darauf laufen. Prüfen Sie, ob das ausführende Konto auf den Signierungsschlüsselbund und das Arbeitsverzeichnis zugreifen kann und der Build ohne Dialogfenster durchläuft.

Voraussichtlich 3–8 Minuten · vorhandene Pipeline vorausgesetzt

Die Migration ist abgeschlossen, wenn:derselbe Commit mit derselben Xcode-Version und derselben Lockdatei auf dem Knoten ein abrufbares Archiv erzeugt. Eine erfolgreiche Installation der Abhängigkeiten allein reicht nicht als Nachweis für eine vollständige Umgebungsmigration.

Bereitstellung · ca. 4 Minuten

Wenn es hakt, prüfen Sie den jeweiligen Schritt.

Vom Bestellen bis zum einsatzbereiten Knoten dauert es in der Regel etwa 4 Minuten. Eigene Codeübertragungen, Tool-Downloads und der erste Build sind nicht eingerechnet. Maßgeblich für Zahlung, Zuweisung und Bereitstellung ist der aktuelle Status in der Konsole.

  1. 01

    Bestelldaten prüfen

    ca. 40 Sekunden

    Wählen Sie Modell, Laufzeit und Knoten aus und prüfen Sie Zusatzoptionen sowie Gesamtbetrag. Wenn Sie nicht weiterkommen, kontrollieren Sie Pflichtfelder und Fehlermeldungen auf der Seite. Legen Sie dieselbe Bestellung nicht mehrfach an.

  2. 02

    In US-Dollar bezahlen

    ca. 60 Sekunden

    Unterstützt werden ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex (über Stripe); abgerechnet wird in USD. Prüfen Sie bei Verzögerungen den Zahlungsstatus. Bestätigungen auf der Blockchain und Prüfungen der kartenausgebenden Bank können zusätzliche Zeit beanspruchen.

  3. 03

    Initialisierung des Knotens abwarten

    ca. 2 Minuten

    Nach bestätigtem Zahlungseingang beginnt die Zuweisung eines exklusiven physischen Knotens. Prüfen Sie bei Verzögerungen den Instanzstatus und Systemhinweise. Bleibt der Status trotz bezahlter Rechnung längere Zeit unverändert, notieren Sie die Bestellnummer und erstellen Sie ein Support-Ticket.

  4. 04

    Bereitstellungsnachricht abrufen

    Zugangsdaten per E-Mail / Konsole

    Prüfen Sie Posteingang und Spam-Ordner und vergleichen Sie die Angaben mit den Verbindungsdaten in der Konsole. Antworten Sie nicht auf unbekannte E-Mails mit einem Passwort. Wenn keine Benachrichtigung eingeht, prüfen Sie zuerst, ob die Instanz bereits bereit ist.

  5. 05

    Ersten Login prüfen

    ca. 20 Sekunden

    Stellen Sie zuerst die SSH-Verbindung her und prüfen Sie danach die grafische Oberfläche. Wenn Sie nicht weiterkommen, notieren Sie die vollständige Fehlermeldung, Zeitpunkt und Zeitzone. Ordnen Sie das Problem anhand der folgenden Checkliste Netzwerk, Authentifizierung oder Sitzung zu.

Vor der Rückgabe · Daten sichern

Die Maschine geben Sie zurück.
Ihre Artefakte nehmen Sie mit.

Nach Ablauf wird nicht automatisch verlängert. Wenn Sie die Instanz weiter nutzen möchten, verlängern Sie die Mietzeit vor Ablauf manuell in der Konsole und prüfen Sie, ob die Verlängerung bestätigt wurde. Gehen Sie nicht davon aus, dass laufende Builds die Mietzeit verlängern.

Nach der Rückgabe wird der gesamte Datenträger sicher gelöscht. Der Knoten ist kein dauerhafter Backup-Speicher. Kopieren Sie das letzte Archiv, Debug-Symbole und erforderliche Logs in einen kontrollierten Speicher und prüfen Sie, ob sich die Dateien öffnen lassen. Lokale Dateien zu löschen ersetzt nicht den Widerruf des Fernzugriffs.

Mit diesen 4 Schritten sauber übergeben

  1. Build-Artefakte exportieren.Holen Sie .xcarchive, .ipa, dSYM und erforderliche Build-Logs ab und prüfen Sie, ob der Upload oder Download abgeschlossen ist.
  2. Temporären Runner abmelden.Entfernen Sie die Runner-Registrierung in der CI-Plattform, stoppen Sie den lokalen Runner-Prozess und widerrufen Sie Deploy-Schlüssel sowie temporäre Zugriffstoken.
  3. Signierungsmaterial entfernen.Entfernen Sie importierte private Zertifikatsschlüssel, Bereitstellungsprofile und temporäre Konfigurationen. Prüfen Sie, dass weder Schlüssel noch Passwörter in den Pipeline-Logs offengelegt wurden.
  4. Ablaufdatum und Backups prüfen.Prüfen Sie Ablaufzeit und Zeitzone in der Konsole und planen Sie genügend Zeit für den letzten Build und die Übertragung der Artefakte ein.

Bestimmen Sie bei der Teamarbeit eine Person, die für die abschließende Rückgabeprüfung zuständig ist. Verlassen Sie sich nicht darauf, dass eine andere Person die Dateien schon heruntergeladen hat.

Typische Anwendungsfälle · sofort nutzbare Rezepte

Erst einen Ablauf zum Laufen bringen, dann zur Pipeline ausbauen.

Beide Konfigurationen sind exklusive physische M4-Maschinen: SDK Pack 16 mit 16 GB / 256 GB und SDK Pack 24 mit 24 GB / 512 GB. Wählen Sie Arbeitsspeicher und Speicherplatz passend zum Projektbudget. Bündeln Sie nicht alle parallelen Aufgaben im ersten Test.

App-Builds automatisieren

Prüfen Sie zuerst, ob das Scheme freigegeben und die Signierung korrekt konfiguriert ist und der Schlüsselbund erreichbar ist. Hat das Projekt ein Gemfile, legen Sie die Fastlane-Version mit Bundler fest und erstellen Sie anschließend das Archiv.

bundle install
bundle exec fastlane gym
bundle exec fastlane pilot upload \
  --ipa ./build/App.ipa

Ersetzen Sie Beispielpfade durch den tatsächlichen Speicherort des Artefakts. Konfigurieren Sie vor dem Upload mit pilot den vom Projekt verwendeten API-Schlüssel für die Veröffentlichung und speichern Sie ihn in einer geschützten CI-Variablen. Uploadberechtigung und erfolgreicher Build müssen separat geprüft werden.

Prüfung: Archiv abrufbar, Upload abgeschlossen

Remote-Mac-Entwicklung

Prüfen Sie zuerst eine normale SSH-Verbindung und lassen Sie VS Code Remote-SSH dieselbe Verbindungskonfiguration verwenden. Schlägt die Editorverbindung fehl, prüfen Sie zuerst die Logs der Remote-Erweiterung, statt direkt Systemberechtigungen zu ändern.

Host sdk-build
  HostName <Knotenadresse>
  User admin
  IdentityFile ~/.ssh/id_ed25519
  ServerAliveInterval 30

Legen Sie die Konfiguration lokal unter ~/.ssh/configab. Prüfen Sie nach der Verbindung, auf welcher Maschine das Terminal läuft und welches Arbeitsverzeichnis geöffnet ist. Simulator und grafisches Debugging erfolgen über Bildschirmfreigabe; für Codebearbeitung und Git genügt SSH.

Prüfung: Bearbeitung und Build im selben Arbeitsbereich

GPU-Rendering und MLX-Inferenz

Prüfen Sie zuerst, ob die Aufgabe Apple Silicon und das benötigte Grafik-Backend unterstützt. Richten Sie anschließend eine isolierte Python-Umgebung ein. Planen Sie ausreichend Speicherplatz für Modellgewichte, Arbeitsspeicherbedarf der Anwendung und Zwischenergebnisse ein.

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install mlx
python -c "import mlx.core as mx; print(mx.default_device())"

Prüfen Sie Abhängigkeiten und Geräteauswahl zuerst mit kleinen Eingaben. Erhöhen Sie anschließend schrittweise Auflösung, Batch-Größe oder Kontextlänge. Notieren Sie Anwendungsversion und Parameter. Ob ein bestimmtes Modell läuft, hängt von der Größe der Gewichte und dem tatsächlichen Speicherbedarf ab.

Prüfung: Kleine Aufgabe abgeschlossen, Ressourcenverbrauch im Rahmen
Fehlerbehebung · jeweils nur eine Variable ändern

Ordnen Sie den Fehler der richtigen Kategorie zu.

Sichern Sie zuerst die ursprüngliche Fehlermeldung, bevor Sie etwas ändern. Die vier folgenden Kategorien betreffen Netzwerk, grafische Sitzung, Signierungsberechtigungen und Speicherplatz. Eine Neuinstallation ist meist nicht der erste Schritt.

SSH-Timeout oder Authentifizierungsfehler

Timeout:Prüfen Sie Adresse, Port, Instanzstatus und Einschränkungen Ihres lokalen Netzwerks. Verwenden Sie ssh -v um festzustellen, ob der Verbindungsaufbau oder die Authentifizierung scheitert.

Authentifizierungsfehler:Prüfen Sie Benutzername, Schlüsselpfad und Berechtigungen von authorized_keys. Ändert sich der Fingerabdruck, klären Sie zuerst, ob der Knoten neu bereitgestellt wurde. Löschen Sie den bekannten Host-Eintrag nicht einfach.

Ticketangaben: Originalfehler, Port, Zeitpunkt

Bildschirmfreigabe zeigt schwarzen Bildschirm

Prüfen Sie per SSH, ob der Knoten erreichbar ist, und kontrollieren Sie anschließend Port für die Bildschirmfreigabe und Login-Konto. Prüfen Sie, ob noch Initialisierungsaufgaben laufen oder Ihr lokaler Client lediglich eine alte Verbindung gespeichert hat.

Beenden Sie den Client und verbinden Sie sich erneut. Bei einem Tunnel prüfen Sie, ob der Weiterleitungsprozess noch läuft. Starten Sie die Maschine nicht wiederholt neu, solange die Artefakte noch nicht gesichert sind.

Ticketangaben: Client-Version und geschwärzter Screenshot

Schlüsselbunddialog blockiert CI

Prüfen Sie in einer grafischen Sitzung, ob der private Signierungsschlüssel importiert wurde und das Zertifikat noch gültig ist. Stellen Sie sicher, dass der Runner unter genau dem Konto ausgeführt wird, für das die Signierungsumgebung eingerichtet wurde.

Verwenden Sie für CI einen separaten Signierungsschlüsselbund und konfigurieren Sie Entsperrung und Zugriffsrechte gemäß den Richtlinien Ihres Teams. Testen Sie zuerst einen Build ohne Interaktion und geben Sie das Schlüsselbundpasswort niemals in Logs aus.

Ticketangaben: fehlgeschlagener Schritt und Signierungsfehlercode

Nicht genügend Speicherplatz

Führen Sie zuerst df -haus und prüfen Sie anschließend DerivedData, Archive, Simulatordaten und Container-Images. Entfernen Sie nur Caches, die sich nachweislich wiederherstellen lassen. Noch nicht exportierte Archive und Debug-Symbole bleiben erhalten.

Wenn Projekt und Ressourcen dauerhaft mehr Speicherplatz benötigen, wählen Sie bei der Bestellung zusätzlichen Speicherplatz mit +1TB SSD oder +2TB SSD. Wie sich eine bestehende Instanz erweitern lässt, klären Sie zuerst per Support-Ticket. Gehen Sie nicht davon aus, dass zusätzlicher Speicher sofort verfügbar ist.

Ticketangaben: freier Speicherplatz und größte Verzeichnisse
Weiterlesen · direkt zum passenden Thema

Für mehr Details geht’s weiter zu den technischen Artikeln.

Diese Seite führt vollständig durch die Arbeitsschritte von der Verbindung bis zur Rückgabe. Ausführliche Informationen zu Containern, Abhängigkeitsmigration, sicheren Verbindungen und Mietoptionen finden Sie im Verzeichnis der technischen Artikel. Maßgeblich sind die dort tatsächlich veröffentlichten Beiträge.

Zuerst herausfinden, auf welcher Ebene das Problem liegt

Toolchain:Installiert heißt nicht automatisch buildfähig. Notieren Sie Xcode-Version, Paketmanager und Lockdatei und vergleichen Sie zuerst die Versionen auf Ihrem lokalen Rechner und dem Knoten.

Sicherheit:Eine Verbindung bedeutet nicht automatisch korrekte Berechtigungen. Verwenden Sie für temporäre Knoten separate Schlüssel und eingeschränkte Token. Widerrufen Sie bei der Rückgabe die Registrierung und verwenden Sie keine persönlichen, langfristigen Zugangsdaten erneut.

Auswahl:Ein erfolgreicher Test garantiert keine langfristige Eignung. Beobachten Sie tatsächliche Arbeitsspeicher-Spitzen, zusätzlichen Speicherbedarf und parallele Aufgaben, bevor Sie Modell und Mietdauer festlegen.

Gemeinsam mit einem Engineer prüfen

Halten Sie die Details fest,
wir beginnen mit der Fehlersuche.

Bei Problemen mit einer gemieteten Instanz melden Sie sich in der Konsole an und erstellen Sie ein Support-Ticket. Geben Sie Bestellnummer, Knoten, Zeitpunkt und Zeitzone, Schritte zur Reproduktion sowie bereinigte Logs an. Bei Fragen vor der Bestellung oder Login-Problemen können Sie auch eine E-Mail an support@macsdk.comsenden.

Maßgeblich sind die im Ticket angezeigten Bearbeitungs- und Antwortfortschritte. Eine automatische Eingangsbestätigung ist keine Antwort durch unser Team. Beeinträchtigt das Problem einen laufenden Build, nennen Sie den Umfang im Betreff und sichern Sie den Fehlerzustand. Übermitteln Sie keine privaten Schlüssel, Passwörter oder vollständigen Signaturdateien.