Sie benötigen eine E-Mail-Adresse für den Bestätigungscode, ein verfügbares Zahlungsmittel und einen SSH- oder Bildschirmfreigabe-Client. Mieten Sie einen exklusiven physischen Server und rufen Sie nach bestätigter Zahlung die Zugangsdaten in der Konsole ab.
Zwei Modelle · 6 Standorte · $21.4ab $21.4/Tag. Etwa 4 Minuten sind ein Richtwert für einen reibungslosen Ablauf. Blockchain-Bestätigungen, erforderliche Prüfungen und die Netzwerkverbindung beeinflussen die tatsächliche Dauer.
Prüfen Sie zuerst, ob E-Mail-Adresse und Zahlungsmittel verfügbar sind. Wählen Sie dann Modell, Standort und Mietdauer. Alle Bereitstellungsdaten finden Sie in der Konsole; Sie müssen die Zugangsdaten nicht anderswo suchen.
Verwenden Sie eine E-Mail-Adresse, auf die Sie dauerhaft zugreifen können. Prüfen Sie, ob Sie Posteingang und Spam-Ordner öffnen können – Sie benötigen diese Adresse für Bestellbenachrichtigungen und die Kontoverifizierung.
Verwenden Sie den Bestätigungscode nur im laufenden Verifizierungsvorgang und leiten Sie ihn nicht weiter.
Zahlung in USD mit USDT-TRC20 oder Visa, Mastercard und Amex über Stripe. Prüfen Sie bei USDT vorab das Netzwerk und die auf der Seite angegebenen Zahlungsdetails.
Welche Zahlungsoptionen tatsächlich verfügbar sind, zeigt die Kasse an.
Für Aufgaben in der Kommandozeile benötigen Sie einen SSH-Client. Für die grafische macOS-Oberfläche richten Sie einen Bildschirmfreigabe-Client ein. Prüfen Sie vor der ersten Verbindung, ob Ihr lokales Netzwerk den benötigten Port beschränkt.
Richten Sie zuerst eine Verbindungsmethode ein und anschließend die andere.
Öffnen Sie die Konsole, geben Sie Ihre E-Mail-Adresse ein und folgen Sie den Anweisungen zur Verifizierung. Wenn Sie bereits ein Konto haben, melden Sie sich direkt an. Prüfen Sie die Schreibweise der Adresse, bevor Sie einen Bestätigungscode anfordern, damit Sie nicht auf eine Nachricht an die falsche Adresse warten.
Wählen Sie passend zu Ihrer Aufgabe den XN Core M4 oder XN Pro M4P und anschließend Standort und Mietdauer – tage-, wochen-, monats- oder quartalsweise. Die sechs Standorte sind Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, US-Ostküste und US-Westküste. Beide Modelle sind an allen sechs Standorten verfügbar; maßgeblich ist die Verfügbarkeit, die die Konsole in Echtzeit anzeigt.
Visa, Mastercard und Amex über Stripe werden sofort bestätigt; gegebenenfalls müssen Sie trotzdem die auf der Seite angezeigte Verifizierung abschließen. Bei USDT-TRC20 hängt die Bestätigung vom Ablauf auf der Blockchain ab – eine feste Dauer von einer Minute können wir nicht zusagen. Prüfen Sie nach dem Absenden zuerst den Bestellstatus und zahlen Sie nicht erneut, nur weil die Seite noch nicht aktualisiert wurde.
Nach bestätigter Zahlung weist das System Ihnen einen exklusiven physischen Server zu und zeigt die Verbindungsdaten in der Konsole an. Prüfen Sie Standort, Modell, Hostadresse und Port. Rufen Sie Zugangsdaten ausschließlich in der angemeldeten Konsole ab und fügen Sie Passwörter nicht in öffentliche Build-Protokolle ein.
Verbinden Sie sich mit Host, Port und Benutzername aus der Konsole. Vergewissern Sie sich, dass Sie auf der richtigen Maschine sind, ändern Sie dann das initiale Passwort und prüfen Sie das System. Ein erfolgreicher SSH-Login bedeutet nicht, dass auch die grafische Verbindung eingerichtet ist – testen Sie beide Methoden separat.
≈ 4 Minuten Richtwert von der Registrierung bis zu den Zugangsdaten
Softwareinstallation, Projekt-Upload und vollständige Builds sind nicht enthalten. Dauert die Bestätigung auf der USDT-TRC20-Blockchain länger, verzögert sich die Bereitstellung entsprechend. Wie lange der erste Login dauert, hängt außerdem von Ihrem lokalen Netzwerk und der Vorbereitung des Clients ab.
Wenn Sie Ihren langfristigen Bedarf noch nicht kennen, testen Sie Ihr Projekt zunächst tageweise. Entscheidend ist, ob sich das Projekt vollständig bauen lässt, ob der Arbeitsspeicher für Spitzenlasten ausreicht und ob genügend Platz für Artefakte und Cache vorhanden ist.
$21.4/Tag
Geeignet für App-Builds, Simulator-Tests und gängige CI-Aufgaben. Führen Sie zunächst ein vollständiges Archive aus und prüfen Sie anschließend, wie viel Speicher Build-Cache, Abhängigkeiten und Simulator-Daten belegen.
Wenn Aufgaben nacheinander laufen und Ihr Projekt überschaubar ist, können Sie mit diesem Modell beginnen. Bündeln Sie nicht unbegrenzt mehrere Runner auf einer Maschine und schließen Sie dann anhand der Wartezeit auf deren Leistung.
$59.3/Tag
Geeignet für rechenintensive parallele Builds, mehrere Entwicklungsaufgaben und Experimente mit großen Modellen. 64 GB Arbeitsspeicher und eine 2-TB-Systemplatte bieten mehr Platz für Modelldateien, Abhängigkeiten und Build-Cache.
Prüfen Sie vor MLX- oder Core ML-Aufgaben Modellgröße, Quantisierung und Anforderungen der Laufzeitumgebung. Die Speicherkapazität garantiert nicht, dass jedes Modell direkt ausgeführt werden kann – testen Sie Ihre konkrete Aufgabe zuerst.
Beide Modelle sind exklusive physische Rechner, keine virtuellen Maschinen. Wählen Sie zunächst den Standort in der Nähe der Personen, die damit arbeiten, und prüfen Sie die Verbindung in der Praxis. Berücksichtigen Sie bei automatisierten Builds auch den Übertragungsweg für Quellcode und Artefakte. Preise für alle vier Mietlaufzeiten und externe Erweiterungslaufwerke finden Sie in der vollständigen Preisliste.
Lassen Sie die aktuell funktionierende Verbindung bestehen und ändern Sie Sicherheitseinstellungen Schritt für Schritt. Prüfen Sie insbesondere nach Änderungen an Firewall und SSH die Verbindung in einer zweiten Sitzung, damit Sie sich nicht aussperren.
Verwenden Sie ein starkes, individuelles Passwort, das Sie sonst nirgends nutzen. Ändern Sie es über den dafür vorgesehenen Systemablauf und speichern Sie es nicht unverschlüsselt in Befehlsparametern, Skripten oder Tickets. Legen Sie bei gemeinsam genutzten Build-Servern fest, wer die Zugangsdaten verwaltet.
Prüfen Sie die macOS-Firewall und die Einstellungen der Remotedienste. Lassen Sie nur die Zugriffe zu, die Sie für Ihre Aufgaben benötigen. Bevor Sie Quell-IP-Adressen einschränken, prüfen Sie, ob Ihre öffentliche IP-Adresse statisch ist. Testen Sie neue Regeln, bevor Sie die bestehende Verbindung schließen.
Notieren Sie die macOS-Version und verwenden Sie uname -m um zu prüfen, ob die native Architektur arm64ist. Prüfen Sie, ob Projektabhängigkeiten und Toolchain-Anforderungen zusammenpassen, bevor Sie entscheiden, ob Sie die Xcode-Version wechseln müssen.
Mit df -h sehen Sie den freien Speicherplatz. Die angegebene Kapazität der Systemplatte entspricht nicht dem aktuell verfügbaren Speicher: System, Entwicklungstools und Cache belegen ebenfalls Platz. Berechnen Sie den benötigten Speicher, bevor Sie große Modelle oder andere Dateien hochladen.
Nur lesende Prüfungen · ändern keine Systemeinstellungen
sw_vers
uname -m
df -h
xcode-select -pDer letzte Befehl zeigt den aktuell verwendeten Pfad der Entwicklungstools an. Wenn noch keine Toolchain eingerichtet ist und ein Fehler erscheint, installieren und wählen Sie die Tools im nächsten Abschnitt aus.
Die grafische macOS-Oberfläche und die Kommandozeile sind vollständig einsatzbereit. Prüfen Sie zuerst die vorhandene Umgebung, damit Sie nichts unnötig installieren. Softwareinstallation, Downloads von Abhängigkeiten und der erste Build zählen nicht zur Bereitstellungszeit von etwa 4 Minuten.
Prüfen Sie die installierte Xcode-Version und die Anforderungen Ihres Projekts. Wenn Sie Xcode installieren oder wechseln müssen, verwenden Sie ein rechtmäßig bezogenes Installationspaket. Kontrollieren Sie nach der Installation, ob der Pfad der Entwicklungstools auf die gewünschte Version verweist.
Kommandozeilen-Tools enthalten Compiler und gängige Abhängigkeiten, sind aber kein vollständiges Xcode. Für Simulator, Archive oder SDKs benötigen Sie eine vollständige Entwicklungsumgebung – prüfen Sie das separat.
xcodebuild -version
xcode-select -p
xcrun --find clang
xcrun simctl list devices availablePrüfen Sie zuerst Version und verfügbare Geräte, bevor Sie das Projekt ausführen.
Führen Sie zuerst command -v brew aus, um festzustellen, ob Homebrew bereits installiert ist. Falls nicht, folgen Sie der offiziellen Installationsanleitung von Homebrew und führen Sie keine Installationsskripte unbekannter Herkunft aus.
Prüfen Sie Architektur und Pfad des verwendeten Terminals, bevor Sie Projektabhängigkeiten installieren. Nutzen Sie bei Teamprojekten vorrangig die vorhandene Abhängigkeitsliste und Lockdatei, damit Sie nicht bei jeder Miete andere Versionen installieren.
command -v brew
brew --version
git --version
ruby --versionPrüfen Sie Versionen nur, wenn das jeweilige Tool bereits installiert ist.
Importieren Sie Signaturzertifikate und Provisioning-Profile über einen vom Team genehmigten sicheren Kanal. Erteilen Sie nur die für die aktuelle Aufgabe erforderlichen Berechtigungen und verwahren Sie Zertifikatspasswörter in einem kontrollierten Geheimnismanagement – nicht im Code-Repository.
Führen Sie zunächst manuell einen signierten Build aus und prüfen Sie, ob Zertifikat, Ablaufdatum, Bundle-ID und Provisioning-Profil zusammenpassen. Schlägt ein automatisierter Lauf fehl, klären Sie zuerst, ob ein Build- oder ein Berechtigungsproblem vorliegt.
Entfernen Sie nicht mehr benötigte Zertifikatskopien und temporäre Dateien, bevor das Projekt abgeschlossen ist.
Wenn das Projekt bereits eine Gemfile enthält, installieren Sie die festgelegten Abhängigkeiten und führen Sie vorhandene Lanes mit bundle exec fastlane aus. Lassen Sie zuerst einen lokalen Build erfolgreich durchlaufen und aktivieren Sie anschließend den CI-Trigger.
Legen Sie für Runner eindeutige Arbeitsverzeichnisse und eine passende Parallelität fest. Prüfen Sie, ob Build-Ausgaben Schlüssel, Passwörter oder Signaturmaterial preisgeben, bevor Sie erfolgreiche Artefakte in Ihren eigenen Speicher übertragen.
bundle install
bundle exec fastlane --version
bundle exec fastlane lanesDiese Befehle setzen voraus, dass das Projekt bereits mit Gemfile und Fastlane eingerichtet ist.
Nehmen Sie für die Abnahme am ersten Tag ein echtes Projekt: Abhängigkeiten abrufen, Build ausführen, Artefakte exportieren, in Ihren eigenen Speicher übertragen und den Zugriff über eine neue Verbindungssitzung prüfen. Eine angezeigte Toolversion allein bedeutet nicht, dass sich das Projekt reproduzierbar bauen lässt.
Nutzen Sie den Cloud-Mac für die Ausführung von Aufgaben, nicht als einzigen Speicherort für wichtige Dateien. Für Mietdauer, Verlängerungen und Änderungen an Bestellungen sind die Angaben in der Konsole maßgeblich.
Synchronisieren Sie Änderungen am Quellcode, Build-Artefakte und notwendige Konfigurationen mit Ihrem eigenen Speicher. Cache lässt sich neu erstellen; die einzige Kopie eines Zertifikats, nicht eingecheckter Quellcode und Versuchsergebnisse sollten nicht nur auf dem Server liegen.
Öffnen Sie testweise eine zurückübertragene Datei – erst dann ist das Backup geprüft.
Beachten Sie die Hinweise zum Mietende in der Konsole und planen Sie Verlängerung oder Sicherung passend zu Ihren Aufgaben. Prüfen Sie bei langen Builds, Dateiübertragungen und Modellevaluierungen vor dem Start, wie viel Mietzeit noch verbleibt – nicht erst nach Abschluss.
Gehen Sie nicht davon aus, dass Ihre Daten nach Mietende noch verfügbar sind.
Wenn Sie den Server weiter nutzen möchten, öffnen Sie die betreffende Bestellung in der Konsole und veranlassen Sie dort die Verlängerung. Prüfen Sie vor einem Upgrade zuerst Ablauf, Datenmigration und Kosten, bevor Sie Änderungen vornehmen.
Ein Upgrade überträgt Dateien auf dem bisherigen Server nicht automatisch auf den neuen.
Starten Sie keine neuen CI-Aufgaben und warten Sie, bis laufende Aufgaben abgeschlossen sind. Exportieren und prüfen Sie wichtige Dateien, widerrufen Sie temporäre Zugriffsschlüssel und Tokens und entfernen Sie sensible Daten. Klären Sie in der Bestellung, wie lange Daten aufbewahrt und wann sie gelöscht werden. Planen Sie nicht mit unbestätigten Fristen.
Wenn die Grundprüfungen abgeschlossen sind, optimieren Sie den Fernzugriff und den Build-Ablauf. Notieren Sie bei Problemen Modell, Standort, Zeitpunkt und Fehlermeldung und wenden Sie sich über ein Support-Ticket in der Konsole an uns. Fügen Sie keine Passwörter oder privaten Schlüssel bei.
Wählen Sie je nach Aufgabe SSH oder Bildschirmfreigabe und richten Sie die Dateiübertragung ein. Prüfen Sie zuerst Host, Port und Zugangsdaten. Funktioniert nur eine der Methoden nicht, kontrollieren Sie die Client-Einstellungen und den jeweiligen Dienst getrennt.
Planen Sie die Parallelität der Runner, Cache-Verzeichnisse und Speicher passend zu Ihrem Projekt. Testen Sie zuerst einen vollständigen Ablauf und erweitern Sie dann die Automatisierung. So vermeiden Sie, Toolchain, Modell und Aufgaben gleichzeitig zu ändern und Fehlerquellen schwer zu finden.
Wählen Sie Modell, Standort und Mietdauer. Nach bestätigter Zahlung rufen Sie Ihre Zugangsdaten in der Konsole ab. Bringen Sie zuerst die heutige Aufgabe zum Laufen und entscheiden Sie danach, wie lange Sie verlängern möchten.