Von der Bestellung zum ersten Build

Etwa 4 Minuten bis zur ersten Verbindung mit einem Cloud-Mac

Wählen Sie zuerst Konfiguration und Standort, schließen Sie dann die Bestellung ab, rufen Sie die Verbindungsdaten ab und prüfen Sie die Entwicklungsumgebung. Jede Instanz entspricht einem dedizierten physischen Mac mini, keiner virtuellen Maschine. Maßgeblich ist der aktuelle Status in der Konsole.

Cloud-Mac jetzt mieten Konfiguration und Preis prüfen

2 verfügbare Konfigurationen

4 verfügbare Standorte

Etwa 4 Minuten Grundlegende Abnahme abgeschlossen

GPUMini-Bereitstellungsprotokoll Erste Verbindungsprüfung

Verifizierbarer Ablauf

Physischer Knoten 1 Instanz entspricht 1 Mac mini

Konfigurationen: GPUMini M4 Core / GPUMini M4 Plus
Standorte: Singapur / Tokio, Japan / Seoul, Südkorea / Hongkong
Bereitstellungsergebnis: Hostdaten, Zugangsdaten und Instanzstatus

01Konfiguration und Laufzeit wählenArbeitsspeicher, Speicherplatz und Aufgabendauer prüfen
02Zugriffsstandort wählenVorzugsweise die Region mit der niedrigsten gemessenen Latenz verwenden
03Verbinden und prüfenSSH, Desktop und Build-Toolchain testen

Vorbereitung

Fünf Informationen vorbereiten und Wechsel während der Einrichtung vermeiden

Sie brauchen keine umfangreichen Unterlagen. Klären Sie jedoch, wer die Zugangsdaten erhält, wo das Projekt ausgeführt wird, wie lange die Nutzung voraussichtlich dauert und womit Sie sich lokal verbinden. Mit diesen Angaben können Sie Konfiguration und erste Abnahme ohne Unterbrechung durchführen.

E-Mail-Adresse für Zugangsdaten

Verwenden Sie eine zuverlässig erreichbare Adresse, die vom tatsächlichen Administrator kontrolliert wird. Prüfen Sie nach Erhalt der Bereitstellungsdaten zunächst Hostname, Standort und Mietkonfiguration. Zugangsdaten gehören nicht in öffentliche Gruppen oder Projektprotokolle.

Zielstandort

Wählen Sie zwischen Singapur, Tokio, Seoul und Hongkong. Entscheiden Sie nicht allein nach dem Ortsnamen: Testen Sie jeden Standort aus Ihrem üblichen Büronetz und dokumentieren Sie Medianlatenz und Verbindungsstabilität.

Geplante Mietdauer

Für kurzfristige Fehleranalyse oder einen einmaligen Build eignen sich Tages- oder Wochenzeiträume. Bei laufender Entwicklung, wiederverwendeten Caches und langen Aufgaben sollten Sie Monats- und Quartalszeiträume vergleichen. Der Endbetrag wird auf der Bestellbestätigungsseite einzeln ausgewiesen.

Remote-Verbindungstools

Halten Sie mindestens einen SSH-Client bereit und bei Bedarf einen kompatiblen Remote-Desktop-Client. Prüfen Sie, ob Ihr lokales Netzwerk die erforderlichen Verbindungen zulässt, und speichern Sie Zugangsdaten nicht dauerhaft auf öffentlichen Geräten.

Benötigte Entwicklungsumgebung

Notieren Sie Xcode-Version, Kommandozeilentools, Fastlane-Abhängigkeiten, den Zugriffsweg zum Code-Repository und den erwarteten zusätzlichen Speicherbedarf. Für mehrere Toolchains sollten Sie zuerst die minimal lauffähigen Versionen und Testbefehle festlegen.

Tarif wählen

Nach Arbeitsspeicher, Speicherplatz und Build-Last wählen – nicht nach dem Namen des Tarifs

Beide Tarife bieten einen dedizierten physischen Cloud-Mac-Knoten. Die Unterschiede liegen vor allem bei Arbeitsspeicher und lokalem Speicher. Entscheiden Sie anhand der tatsächlichen Spitzenwerte Ihres Projekts und berücksichtigen Sie das Wachstum von Caches und Artefakten während der Mietdauer.

Leichte Aufgaben und kurzfristige Tests

GPUMini M4 Core

m4-16-256

M4 16 GB RAM 256 GB SSD

Geeignet für:Entwicklung einzelner Projekte, Funktionstests, Kommandozeilen-Builds und kurzfristige Kompatibilitätsprüfungen.
Zuerst messen:Spitzenverbrauch des Arbeitsspeichers beim vollständigen Kompilieren sowie Speicherbedarf von DerivedData und Abhängigkeits-Cache.
Signal für ein Upgrade:Anhaltender Speicherdruck oder notwendige Build-Artefakte, die auch nach dem Bereinigen des Caches nicht erhalten bleiben.

GPUMini M4 Core wählen

Tägliche Entwicklung und umfangreichere Builds

GPUMini M4 Plus

m4-24-512

M4 24 GB RAM 512 GB SSD

Geeignet für:Laufende Entwicklung, Projekte mit vielen Abhängigkeiten, große Caches, automatisierte Builds und lang laufende Aufgaben.
Zuerst messen:Gemeinsamer Spitzenverbrauch von parallelen Aufgaben, Simulatoren, Build-Cache und exportierten Artefakten.
Grund für die Wahl:Mehr Arbeitsspeicher und lokaler Speicher reduzieren das Bereinigen und erneute Erstellen während Spitzenlasten.

GPUMini M4 Plus wählen

Zuerst Core Wiederholbare Aufgaben, klare Spitzenwerte, kontrollierbarer Cache

Plus bevorzugen Laufende Entwicklung, viele Abhängigkeiten, parallele Builds oder große Artefakte

Noch unsicher Einmal die Spitzenwerte von Arbeitsspeicher und Speicherplatz bei einem vollständigen Build erfassen und danach entscheiden

Standort wählen

Ein näherer Standort bedeutet nicht automatisch eine schnellere Verbindung – messen Sie zuerst im selben Netzwerk

Alle vier Standorte bieten GPUMini M4 Core und GPUMini M4 Plus. Testen Sie unter Ihrem wichtigsten Büronetzwerk mehrmals und bewerten Sie Medianlatenz, Schwankungen und Paketverlust gemeinsam. Verwenden Sie nicht nur den niedrigsten Einzelwert.

Übersicht der vier verfügbaren Standorte
Standort	Wichtigste Referenzregion	Referenzlatenz	Verfügbare Konfigurationen	Bestellzugang
SingapurSG	Zugriff aus Südostasien und regionsübergreifende Zusammenarbeit	20–50 ms	Core / Plus	Singapur wählen
Tokio, JapanJP	Zugriff aus Japan und Ostasien	30–60 ms	Core / Plus	Tokio wählen
Seoul, SüdkoreaKR	Zugriff aus Südkorea und Nordostasien	30–50 ms	Core / Plus	Seoul wählen
HongkongHK	Zugriff aus Südchina und Südostasien	20–40 ms	Core / Plus	Hongkong wählen

Schritt 1

Testnetzwerk festlegen

Testen Sie in dem kabelgebundenen oder stabilen WLAN, das Sie tatsächlich verwenden. Pausieren Sie temporäre Downloads und stark ausgelastete Synchronisierungen, damit lokale Überlastung nicht fälschlich dem Standort zugerechnet wird.

Schritt 2

Mehrere Ergebnisse dokumentieren

Beobachten Sie jeden Standort bei mehreren Anfragen und notieren Sie Medianlatenz, Schwankungsbereich und Paketverlust. Beim Remote-Desktop ist Stabilität besonders wichtig; bei automatisierten Builds zählt außerdem der Standort der Codequelle.

Schritt 3

Nach den Hauptnutzern entscheiden

Bei privater Nutzung zählt der alltägliche Zugriffsstandort. Im Team vergleichen Sie die Verteilung der wichtigsten Mitglieder, den Standort des Code-Repositorys und den Ausgangspunkt automatisierter Aufgaben.

Die Bereiche in der Tabelle dienen der Vorauswahl und sind kein festes Ergebnis für jedes Netzwerk. Provider-Routing, lokales Netzwerk, grenzüberschreitende Leitungen und Testzeitpunkt beeinflussen die tatsächliche Verbindungsqualität.

Bereitstellungszeitplan

Vier Aktionen getrennt abnehmen, damit Abweichungen leichter zu lokalisieren sind

Unter normalen Bedingungen dauert es etwa 4 Minuten von der Konfiguration bis zur grundlegenden Verbindungsprüfung. Die Initialisierung kann je nach Konfiguration und aktuellem Aufgabenfortschritt variieren. Maßgeblich ist der Instanzstatus in der Konsole.

Etwa 4 Minuten Konfiguration, Bestellung, Initialisierung und Verbindungsprüfung insgesamt

01

Konfiguration wählen
Etwa 30 Sekunden

Wählen Sie GPUMini M4 Core oder GPUMini M4 Plus und anschließend einen Tages-, Wochen-, Monats- oder Quartalszeitraum. Prüfen Sie, ob Arbeitsspeicher, Speicherplatz und Zusatzoptionen zur Aufgabe passen.
Abgeschlossen, wenn: Die Konfigurationszusammenfassung der Bestellung Ihren Erwartungen entspricht.
02

Bestellung abschließen
Etwa 1 Minute

Wählen Sie Singapur, Tokio, Seoul oder Hongkong. Prüfen Sie Zeitraum, Basistarif und Zusatzoptionen und senden Sie anschließend die Bestellung ab.
Abgeschlossen, wenn: Die zugehörige Bestellung und Instanz in der Konsole erscheinen.
03

Knoten initialisieren
Etwa 2 Minuten

Warten Sie, bis das System die Standortkonfiguration und Verbindungsdaten vorbereitet hat. Senden Sie Bestellungen nicht wiederholt ab und beurteilen Sie einen Fehler nicht anhand alter Seitendaten, solange sich der Status noch ändert.
Abgeschlossen, wenn: Instanzstatus und Host-Verbindungsdaten in der Konsole geprüft werden können.
04

Verbindung prüfen
Etwa 30 Sekunden

Prüfen Sie zuerst die Hostdaten und versuchen Sie anschließend SSH oder den Remote-Mac-Desktop. Kontrollieren Sie bei der ersten Verbindung den Hostschlüssel-Fingerabdruck oder das Verbindungsziel, damit Sie nicht wegen eines Kopierfehlers eine andere Adresse öffnen.
Abgeschlossen, wenn: Eine Sitzung aufgebaut sowie Systemzeit und Speicherplatz ausgelesen werden können.

Erste Anmeldung

Zuerst Identität und Basisstatus des Rechners prüfen, danach Code und Abhängigkeiten synchronisieren

Ziel der ersten Sitzung ist nicht der sofortige Entwicklungsstart, sondern die Bestätigung, dass Host, Konfiguration, Zeit und Speicherplatz der Bestellung entsprechen. Erst danach ändern Sie Zugangsdaten und synchronisieren das Projekt.

Hostdaten abgleichen

Vergleichen Sie Standort, Hostname und Instanzkennung aus der Konsole Punkt für Punkt mit den Bereitstellungsdaten. Stimmen die Verbindungsziele nicht überein, beenden Sie den Vorgang und kopieren Sie die Adresse erneut. Ändern Sie ähnliche Zeichen nicht aus dem Gedächtnis.

Temporäre Zugangsdaten aktualisieren

Aktualisieren Sie die temporären Zugangsdaten nach der ersten erfolgreichen Anmeldung gemäß den Bereitstellungshinweisen. Speichern Sie die neuen Daten an einem vom Team freigegebenen sicheren Ort, nicht im Code-Repository, in Build-Protokollen oder normalen Chats.

Grundlegende Prüfung der ersten Sitzung

Drei Befehle für System, Zeit und Speicherplatz

Die folgenden Befehle lesen ausschließlich lokale Systeminformationen. Speichern Sie die Ausgabe zusammen mit Konfigurations- und Standortdaten aus der Konsole im Abnahmeprotokoll.

sw_vers
date
df -h /

Entwicklungsumgebung prüfen

Verbindungs-, Tool- und Projektebene nacheinander prüfen

Starten Sie nicht sofort die vollständige Pipeline. Prüfen Sie zunächst die Basisverbindung, danach Xcode und die Kommandozeilentools und führen Sie zuletzt einen kontrollierten, reproduzierbaren Projekt-Build aus. So lässt sich die fehlerhafte Ebene leichter bestimmen.

SSH

Adresse, Konto, Hostbestätigung und Befehlsausführung prüfen. Nach erfolgreicher Verbindung Systemversion und Speicherinformationen auslesen.

Bestanden, wenn: Die Sitzung stabil ist und Befehle normal zurückkehren.

Remote-Mac-Desktop

Grafiksitzung, Bildschirmauflösung, lokale Eingabe und Wiederverbindung prüfen. Beobachten Sie die Interaktionslatenz zunächst mit konservativer Bildqualität.

Bestanden, wenn: Das Bild nutzbar ist und die Sitzung nach einer Trennung wiederhergestellt werden kann.

Xcode

Prüfen Sie, ob die benötigte Version startet, das Projekt geöffnet werden kann und Build-Einstellungen sowie Toolchain-Pfade den Erwartungen entsprechen.

Bestanden, wenn: Die Projektindizierung abgeschlossen ist und keine umgebungsbedingten Fehler auftreten.

xcodebuild

Ermitteln Sie zuerst Version und verfügbare Schemes. Führen Sie anschließend einen eindeutig definierten Test-Build aus und speichern Sie Exit-Code sowie wichtige Protokolle.

Bestanden, wenn: Der Befehl wiederholt ausgeführt wird und konsistente Ergebnisse liefert.

Fastlane

Prüfen Sie Ruby-Umgebung, Installation der Abhängigkeiten und die Liste der Lanes. Führen Sie zunächst eine Prüfaufgabe ohne Produktionsveröffentlichung aus.

Bestanden, wenn: Abhängigkeiten normal aufgelöst werden und die gewünschte Lane erkannt wird.

Zugriff auf das Code-Repository

Prüfen Sie Repository-Host, Berechtigungen des SSH-Schlüssels oder die Konfiguration eines kontrollierten Tokens. Stellen Sie außerdem sicher, dass Submodule und Bezugsquellen erreichbar sind.

Bestanden, wenn: Der angegebene Branch abgerufen werden kann, ohne Zugangsdaten offenzulegen.

Empfohlene Minimalprüfung Zuerst Version lesen, dann Projektziele auflisten und zuletzt einen Test-Build ausführen

ssh user@host
xcodebuild -version
xcodebuild -list -project YourProject.xcodeproj
fastlane lanes

Abnahme der Bereitstellung

Eine Betriebsdokumentation hinterlassen, die andere reproduzieren können

Das Abnahmeprotokoll sollte nicht nur „einsatzbereit“ vermerken. Es muss Standort, Konfiguration, Verbindungsmethode, Projektpfad und den erfolgreich ausgeführten Build-Befehl nennen.

GPUMini-Abnahmeprotokoll für den Knoten

Erste Bereitstellungsdokumentation

Nach Abschluss archivieren

Standort: Einer von: Singapur / Tokio, Japan / Seoul, Südkorea / Hongkong
Konfiguration: GPUMini M4 Core oder GPUMini M4 Plus
Anmeldemethode: Dokumentieren, ob SSH, Remote-Mac-Desktop oder beide geprüft wurden
Projektpfad: Arbeitsverzeichnis dokumentieren, aber keine vertraulichen Zugangsdaten im Abnahmeprotokoll speichern
Test-Build: Befehl, Scheme, Exit-Code und Speicherort der Protokolle dokumentieren
Speicher-Baseline: Verfügbaren Speicher vor und nach der Projektsynchronisierung dokumentieren, um späteres Wachstum zu beurteilen

Abnahmekriterium

Ein reproduzierbarer Build

Führen Sie die Prüfung mit derselben Codeversion, demselben Befehl und demselben Build-Ziel wiederholt aus. Das Ergebnis muss reproduzierbar sein; die Protokolle dürfen keine blockierenden Fehler aufgrund fehlender Umgebung enthalten.

Wenn Unterstützung erforderlich ist

Nachvollziehbare Informationen einreichen

Bereiten Sie Standort, Zeitpunkt, Verbindungsmethode, Reproduktionsschritte, Fehlermeldung und bereinigte Protokolle vor. Fragen zu Bestellung, Instanz und Abrechnung reichen Sie bevorzugt über die Konsole als Ticket ein.

Ticket über die Konsole einreichen

Nächste Schritte

Konfiguration und Standort wählen, bereitstellen und erste Abnahme abschließen

Informationen zur Einrichtung grafischer Sitzungen finden Sie im Leitfaden für Remote-Verbindungen. Bei Build-, Netzwerk- oder Abrechnungsfragen öffnen Sie das Hilfezentrum. Sobald Sie bereit sind, können Sie den Cloud-Mac direkt mieten.

Cloud-Mac jetzt mieten Leitfaden für Remote-Verbindungen öffnen Hilfezentrum öffnen