Erste Verbindung
Knoten, Quelladresse und Zugriffsweg prüfen, zunächst die eigene Sitzung einrichten und erst danach an Teammitglieder übergeben.
Verbinden, bauen, prüfen
Vom ersten Zugriff bis zum stabilen Betrieb des Cloud-Macs immer den nächsten Schritt kennen
Prüfen Sie zuerst Zugriffsweg und Sicherheitsgrenzen, dann konfigurieren Sie Xcode, Runner, MLX oder Medien-Workflows. Bei Problemen arbeiten Sie sich über Netzwerk, Authentifizierung, Speicher, Toolchain, Prozesse und regionale Verbindungen vor, ohne mehrere Variablen gleichzeitig zu ändern.
Die Standardbereitstellung dauert etwa 4 Minuten. Maßgeblich ist der in der Konsole angezeigte Echtzeitstatus von Knoten und Bestellung.
SUPPORT / RUNBOOK
Board für Aufgaben und Diagnose
Umsetzbare Schritte
Build und Ausführung
Toolversionen, Cache-Verzeichnisse und Parallelitätsgrenzen festlegen, damit Xcode- oder Runner-Jobs reproduzierbar laufen.
Fehlerdiagnose
Zeitraum, Originalfehlermeldung, Ressourcenwerte und Reproduktionsschritte sichern und anschließend über die Konsole ein Ticket senden.
Dedizierter physischer Apple-Silicon-Knoten
Keine virtuelle Maschine
365 Tage im Jahr verfügbar
Empfohlene Reihenfolge
Schnellstart-Index
Fünf Schritte in Abhängigkeitsreihenfolge. Die Aufzeichnungen des vorherigen Schritts dienen als Eingabe für den nächsten. Im Team sollten Schlüsselrotation und Zugriffsentzug nicht übersprungen werden.
-
01
Bestellung abschließen
Modell, Mietdauer, Knoten und Speicheroptionen wählen, Zahlung bestätigen und auf den Bestellstatus in der Konsole warten. Verfügbarkeit nicht anhand alter Screenshots beurteilen.
-
02
Zugangsdaten erhalten
Instanz, Knoten und Zugriffshinweise in der Konsole prüfen. Zugangsdaten ausschließlich in einem kontrollierten Passwortmanager speichern, nicht in Chats weiterleiten oder ins Repository übernehmen.
-
03
Erste Anmeldung durchführen
Über ein vertrauenswürdiges Netzwerk eine Remote-Desktop- oder SSH-Sitzung aufbauen. Zeitpunkt, Clientversion und öffentliche Quelladresse dokumentieren.
-
04
Schlüssel rotieren
Eigene SSH-Schlüssel und Konten mit minimalen Rechten erstellen. Erst den neuen Zugang prüfen, dann temporäre Zugangsdaten widerrufen, damit keine Sperrung entsteht.
-
05
An das Team übergeben
Aufgabe, Branch, Cache-Status, laufende Prozesse und Ausgabepfad übergeben, jedoch keine persönlichen Zugangsdaten. Verantwortliche Person und Datenexport vor Mietende festlegen.
Vorbereitung der Verbindung
Vier Zugriffswege, jeweils mit eigener Kurzprüfung
Bei Verbindungsproblemen zuerst den verwendeten Weg bestimmen. Remote-Desktop, SSH, Dateiübertragung und Firewall-Freigaben haben unterschiedliche Prüfpunkte und sollten getrennt untersucht werden.
Grafische Sitzung
Sicherer Remote-Desktop
Einen Client mit verschlüsselter Verbindung verwenden und zunächst in einem einzigen vertrauenswürdigen Netzwerk testen. Clientversion, Auflösung, Tastaturlayout und Proxy-Nutzung dokumentieren.
- Erste Verbindung mit einem Monitor und Standardauflösung herstellen
- Prüfen, ob Zwischenablage und Dateizuordnung den Teamrichtlinien entsprechen
- Bei ungewöhnlicher Eingabeverzögerung einen zusammenhängenden Testzeitraum dokumentieren
Geeignet für Xcode, Final Cut Pro und grafische Verwaltung
Befehlszeile
SSH
Jeder Person einen eigenen Schlüssel zuweisen und vor der ersten Verbindung die Instanzdaten prüfen. Automatisierte Jobs verwenden ein eigenes Konto, keine persönliche Sitzung.
- Privaten Schlüssel auf einem kontrollierten Gerät speichern und Dateirechte beschränken
- Autorisierte öffentliche Schlüssel getrennt pro Teammitglied verwalten
- Bei Verbindungsfehlern ausführliche Ausgabe sichern, aber vertrauliche Inhalte entfernen
Geeignet für Automatisierung, Logprüfung und Remote-Befehle
Datenkanal
Dateiübertragung
Für große Dateien bevorzugt fortsetzbare Tools verwenden und Verzeichnisse für Eingaben, Zwischendateien und Ausgaben trennen. Zuerst ein kleines Beispiel übertragen und Rechte sowie Speicher prüfen.
- Dateianzahl und Prüfsummen vor und nach der Übertragung vergleichen
- Modelle, Medien und Build-Caches getrennt speichern
- Dateien nicht direkt in laufenden Cache-Verzeichnissen überschreiben
Geeignet für Modelle, Medien, Build-Artefakte und Logübertragung
Zugriffsgrenzen
Firewall-Allowlist
Nur bestätigte öffentliche Quelladressen und notwendige Ports freigeben. Ändert sich die Adresse eines Heim- oder Mobilnetzes, die Regel aktualisieren statt unkontrollierte Netze freizugeben.
- Büronetz, Runner und Administrationsausgang getrennt dokumentieren
- Für temporäre Quellen einen eindeutigen Widerrufszeitpunkt festlegen
- Nach Änderungen jeweils einmal von einer erlaubten und einer nicht erlaubten Quelle testen
Geeignet für feste Büroausgänge und kontrollierte Automatisierungsnetze
Continuous Integration
GitHub-Actions-Self-Hosted-Mac-Runner als aufräumbare Jobs betreiben
Die Stabilität des Runners hängt von festen Versionen, Parallelitätsgrenzen, Cache-Zuordnung und Bereinigung nach dem Job ab. Der Zustand eines vorherigen Jobs darf keine unsichtbare Abhängigkeit bilden.
Labels nur für überprüfbare Fähigkeiten verwenden
Labels sollten Chiparchitektur, Xcode-Hauptversion, Zweck und Queue-Grenzen abbilden. Temporäre Projektnamen sind keine dauerhaften Fähigkeitslabels, sonst verfälschen sich Planungsregeln.
- Registrierung
- Für Organisation oder Repository
- Ausführungskonto
- Eigenes Konto mit minimalen Rechten
- Prüfung
- Ein Testjob ohne vertrauliche Informationen ausführen
Parallelität zuerst begrenzen, dann Ressourcenspitzen beobachten
Mit einer Einzeljob-Basislinie beginnen und CPU, Unified Memory, Schreibvorgänge sowie Build-Dauer dokumentieren. Parallelität erst erhöhen, wenn Jobs unabhängig sind und Spitzenreserven bleiben.
- Abhängigkeits-Cache
- Nach Lockdatei und Toolversion aufteilen
- Abgeleitete Daten
- Pro Projekt isolieren und Bereinigungsgrenze setzen
- Parallelitätsentscheidung
- Ressourcenspitzen und Warteschlange gemeinsam bewerten
Signaturmaterial gehört nicht in den allgemeinen Cache
Vertrauliches Material nur in den erforderlichen Jobphasen einfügen. Danach temporäre Dateien, Umgebungsvariablen und Hintergrundprozesse entfernen. Erfolgs- und Fehlerpfad müssen dieselbe Bereinigung ausführen.
- Vertrauliches Material
- Eigene Berechtigungen und eigener Lebenszyklus
- Fehlerwiederholung
- Reste bereinigen und erst danach erneut einreihen
- Mietende
- Runner, Schlüssel und Zugriffsregeln widerrufen
Entwicklungsumgebung
Toolversionen, Installationsquellen und Cache-Verzeichnisse müssen nachvollziehbar sein
Zuerst den Ist-Zustand dokumentieren, dann aktualisieren. Für Build-Hosts sind stabile, reproduzierbare Versionen meist wichtiger als die neueste Version.
| Tool | Ersteinrichtung | Laufende Pflege | Bei Problemen zuerst prüfen |
|---|---|---|---|
| Xcode | Hauptversion festlegen sowie Auswahl der Kommandozeilentools und Status beim ersten Start dokumentieren. | Vor Upgrades Projekkompatibilität sichern und DerivedData pro Projekt isolieren. | Aktueller Auswahlpfad, SDK, Simulatorstatus, freier Speicher und vollständiges Build-Log. |
| Homebrew | Mit einem einzigen kontrollierten Konto installieren und Abhängigkeitsliste sowie erforderliche Versionsvorgaben speichern. | Vor Updates Änderungen prüfen und Abhängigkeiten nicht während eines Build-Jobs aktualisieren. | Pfadpriorität, Verzeichniseigentümer, Architekturkompatibilität und Formula-Version. |
| Ruby | Die vom Projekt deklarierte Version verwenden und Bundler sowie Abhängigkeitsdateien sperren. | Wiederverwendbare Abhängigkeiten cachen, aber inkompatible Ruby-Versionen nicht mischen. | Interpreterpfad, Gem-Installationsverzeichnis, Lockdatei und Build-Ausgabe nativer Erweiterungen. |
| Node.js | Laufzeit und Paketmanager pro Projekt festlegen und Lockdateiprüfung aktivieren. | Downloads statt undurchsichtiger Arbeitsverzeichnisse cachen und veraltete Caches regelmäßig löschen. | Node-Pfad, Paketmanager-Version, Lockfile-Differenzen und Architektur nativer Module. |
| Alternative für Container | Linux-Container-Schritte in einer externen Linux-Umgebung ausführen; der Mac-Knoten übernimmt macOS-spezifische Builds und Tests. | Eingaben und Artefaktformate per Skript vereinheitlichen und manuelle Transfers zwischen Plattformen reduzieren. | Plattformannahmen, Dateirechte, Zeilenenden, Architektur und Artefaktpfad prüfen. |
| Build-Cache | Cache-Schlüssel nach Projekt, Branch-Strategie, Toolversion und Lockdatei erstellen. | Kapazitätsgrenze und Bereinigungsreihenfolge festlegen: zuerst reproduzierbare Caches, danach Arbeitsdateien löschen. | Trefferquote, Verzeichnisrechte, freier Speicher, Dateianzahl und parallele Schreibzugriffe. |
Aufgaben mit viel Speicher und großen Dateien
MLX-Inferenz und Medienproduktion benötigen gemeinsames Management von Speicher, Festplatte und Rückübertragung
Beide Aufgabentypen können Unified Memory lange belegen und große Ausgaben erzeugen. Vor Beginn Eingaben, temporäres Verzeichnis, Abschlusskriterien und Übertragungsweg festlegen.
MLX-Inferenz
Nach dem Speichern des Modells zunächst eine Kleinbatch-Basislinie erstellen
Modelldateien, Quantisierung, Eingabebeispiele und Ergebnisse in klar erkennbaren Verzeichnissen speichern. Mit einer Kleinbatch beginnen und Ladezeit, maximalen Unified Memory, Inferenzzeit und Ausgabegröße dokumentieren.
- Dateivorbereitung:Integrität der Modelldateien prüfen und ausreichend Platz für Modell, Cache und Ausgabe reservieren.
- Ressourcen beobachten:Speicherdruck, Swap-Aktivität, Festplattenzugriffe und Prozessdauer gleichzeitig beobachten.
- Lange Jobs am Laufen halten:Eine wiederaufnehmbare Aufgabenverwaltung verwenden und Phasenfortschritt sowie Zwischenergebnisse ausgeben.
- Ergebnisse übertragen:Zuerst Liste und Prüfsummen erzeugen, dann Ergebnisse übertragen; den Abschluss nicht nur anhand des Dateinamens beurteilen.
Für speicherintensive 64-GB-Aufgaben kann VPSGit M4 Pro bewertet werden: M4 Pro, 64 GB, 2 TB.
Medienproduktion
Proxy-Medien, Projektdateien und fertige Ausgaben getrennt synchronisieren
Bei der Remote-Nutzung von Final Cut Pro zunächst mit kurzen Proxy-Clips Eingabeverzögerung, Vorschaufluss und Audio-Video-Synchronität prüfen. Vor dem Upload des vollständigen Materials freien Speicher und Zeitbudget für die Rückübertragung bestätigen.
- Mediensynchronisierung:Originalmedien, Proxy-Dateien und Projektdateien in getrennten Verzeichnissen speichern, damit verwendete Medien nicht überschrieben werden.
- Schnitt-Basislinie:Remote-Desktop-Auflösung, Netzwerkpfad und Wiedergabequalität dokumentieren, um Veränderungen vergleichen zu können.
- Exportverwaltung:Vor dem Export Zielformat, temporären Speicher und Benennungsregeln prüfen; bei langen Exporten Phasenprotokolle aufbewahren.
- Fertige Ausgabe übertragen:Zuerst ein kleines Beispiel prüfen, dann die endgültige Datei mit Prüfinformationen übertragen und anschließend reproduzierbare Dateien löschen.
Für große Medien können +1 TB SSD oder +2 TB SSD gewählt werden; Zeit für den Datenexport vor dem Job prüfen.
Schrittweise Diagnose
Immer nur eine Ebene prüfen und jedes Ergebnis dokumentieren
Zuerst feststellen, ob das Problem lokal, auf dem Verbindungsweg oder innerhalb des Knotens liegt. Nach jedem Schritt notieren, ob sich das Verhalten geändert hat. Nicht gleichzeitig Tools aktualisieren, Netzwerk ändern und Cache löschen.
-
01
Netzwerk
Grundlegende Erreichbarkeit, Paketverlust und Jitter von derselben Quelle testen, danach über ein bekannt stabiles Netzwerk wiederholen. Netzwerktyp, Proxy-Nutzung und Problemzeitraum dokumentieren.
-
02
Authentifizierung
Aktuelles autorisiertes Konto und Schlüssel bestätigen sowie lokale Dateirechte, Berechtigungsumfang und letzte Rotation prüfen. Keine Zugangsdaten in das Ticket schreiben.
-
03
Festplatte
Freien Speicher, Verzeichniseigentümer, Dateianzahl und Ursache wachsender großer Verzeichnisse prüfen. Bei Build-Fehlern auch temporäre, Cache- und Ausgabeordner kontrollieren.
-
04
Build-Toolchain
Versionen von Xcode, SDK, Ruby, Node.js, Paketmanager und Lockdateien dokumentieren, mit dem letzten erfolgreichen Job vergleichen und kein globales Upgrade vorwegnehmen.
-
05
Prozessressourcen
CPU, Unified Memory, Swap-Aktivität, Schreibvorgänge und verbliebene Unterprozesse beobachten. Einzelspitze, dauerhafte Belegung und nach Jobende nicht freigegebene Ressourcen unterscheiden.
-
06
Regionale Verbindung
Mit demselben Client, derselben Aktion und ähnlichen Zeiträumen vergleichen, damit unterschiedliche Lasten nicht als regionale Unterschiede erscheinen. Bei Regionswechseln Verzeichnisse neu prüfen und Datentransfer planen.
Vor dem Ticket
Reproduzierbare Informationen in einem Diagnoseblatt sammeln
Tickets werden nach Auswirkungsbereich und Bestellstatus bearbeitet. Vollständige Angaben reduzieren Rückfragen; Schlüssel, Passwörter, Signaturmaterial und Geschäftsdaten bitte entfernen.
- Bestellnummer, gewählter Knoten und Modell
- Beginn und Dauer des Problems
- Betroffener Zugriffsweg oder Jobabschnitt
- Kürzeste reproduzierbare Schrittfolge
- Vollständige Originalfehlermeldung und notwendige Logauszüge
- Durchgeführte Prüfungen und Ergebnis jedes Schritts
Definition der Dienstverfügbarkeit
99,9 %Ziel der Dienstverfügbarkeit
Alle Knoten laufen 365 Tage im Jahr normal. Die Verfügbarkeit wird innerhalb des in den Servicebedingungen definierten Messbereichs berechnet; eigene Handlungen, Drittanbieterabhängigkeiten und unkontrollierbare Ereignisse werden dort geregelt.
Status der letzten 90 Tage
Darstellung in drei aufeinanderfolgenden 30-Tage-Zeiträumen. Einzelereignisse und aktueller Status sind in der Konsole maßgeblich.
Letzte 30 TageAktueller Zeitraum
Nach bestätigten Ereignissen aktualisiert
Tag 31–60Historischer Zeitraum
Nach Dienstereignissen archiviert
Tag 61–90Historischer Zeitraum
Auswirkungsbereich der Ereignisse dokumentiert
Serviceguthaben
Wenn die Voraussetzungen der Servicebedingungen erfüllt sind, kann für den betroffenen Zeitraum ein Serviceguthaben beantragt werden. Antrag mit Bestellung, Zeitraum und überprüfbaren Auswirkungen einreichen; Entscheidung und Umfang richten sich nach den Servicebedingungen.
Sichere Abläufe
Vom Zugriff auf den Knoten bis zum Mietende muss eine verantwortliche Person feststehen
Sicherheit ist keine einmalige Einstellung. Für Konten, Rechte, Schlüssel, vertrauliche Daten, Backups und Widerruf eigene Prüfpunkte einrichten und bei der Übergabe einzeln bestätigen.
Eigene Konten
Jede Person verwendet ein zuordenbares Konto und keine gemeinsam genutzte Sitzung. Automatisierte Runner nutzen ein von manuellen Aktionen getrenntes Dienstkonto.
Prüfung: Person und Konto sind eindeutig zugeordnet
Minimale Rechte
Nur Verzeichnisse, Befehle und Netzwerkzugriffe freigeben, die für die aktuelle Aufgabe erforderlich sind. Temporäre Rechte mit Zweck und Widerrufszeitpunkt versehen.
Prüfung: Keine dauerhaften Hochrechte ohne Zweck
Schlüsselrotation
Nach Mitgliederwechsel, Geräteverlust oder Änderung der Berechtigungsgrenzen sofort rotieren. Neuen Schlüssel prüfen, alten widerrufen und Ergebnis dokumentieren.
Prüfung: Berechtigungsliste und tatsächliche Konfiguration stimmen überein
Vertrauliche Daten bereinigen
Signaturdateien, temporäre Tokens, Umgebungsvariablen und vertrauliche Logauszüge nach dem Aufgabenlebenszyklus löschen und nicht in den allgemeinen Cache aufnehmen.
Prüfung: Erfolgs- und Fehlerpfad bereinigen
Vor Ende sichern
Vor Mietende Quellcodeänderungen, Build-Artefakte, Modellergebnisse, Medienprojekte und notwendige Logs exportieren und die Lesbarkeit des Backups prüfen.
Prüfung: Backup-Ort und Prüfergebnis dokumentiert
Zugriff widerrufen
Nach Abschluss Konto, öffentlichen Schlüssel, Runner-Registrierung, Allowlist und temporäre Freigaben widerrufen und sicherstellen, dass Hintergrundprozesse beendet sind.
Prüfung: Alle externen Zugänge zum Knoten entfernt
Jetzt starten
Zuerst Modell und Knoten wählen, dann die Bereitstellung nach diesem Runbook abschließen
Drei Varianten dedizierter physischer Apple-Silicon-Knoten können tage-, wochen-, monats- oder quartalsweise gemietet werden. Zahlung per USDT-TRC20 sowie Visa / Mastercard / Amex über Stripe; Abrechnung einheitlich in USD.