Singapur, Tokio, Seoul, Hongkong und der Osten der USA. Nutzen Sie einen Standort in Ihrer Nähe für die Bedienung und einen exklusiv genutzten physischen Mac mini für Ihre Builds.
Beide Modelle sind an allen Standorten verfügbar. Keine VM: Während der Mietdauer steht Ihnen das gesamte Gerät exklusiv zur Verfügung. Wählen Sie den Standort passend zum Team, zum Code-Repository und zum Downloadpfad Ihrer Build-Artefakte – ein Modellvergleich für jeden Standortwechsel ist nicht nötig.
Arbeiten Sie häufig am Remote-Desktop, ist die Latenz entscheidend. Bei CI-Builds zählen eher die Wege zum Repository, zu den Paketquellen und zum Ziel für Build-Artefakte. Die folgenden Latenzbereiche dienen als Orientierung für die Standortwahl. Sie sind weder Messwerte Ihrer aktuellen Verbindung noch eine Verbindungsgarantie.
Geeignet für Teams in Südostasien und für standortübergreifende Teams, die Entwicklung und Builds im selben asiatischen Arbeitstag erledigen möchten.
Testen Sie zuerst Paket-Downloads und den Rückweg für Build-Artefakte. Danach können Sie entscheiden, ob auch der Remote-Desktop hierher umziehen soll.
Singapur mietenGeeignet für Entwicklungs- und Testteams in der japanischen Zeitzone. Wenn Sie häufig zwischen Xcode und Simulator wechseln, sollten Sie zuerst die Bedienung testen.
Nutzen Sie einen vollständigen Ablauf aus Pull, Archive und Download als Vergleich – nicht nur einen Ping-Test.
Tokio mietenGeeignet für Teams in der südkoreanischen Zeitzone. Nutzen Sie den Standort als Entwicklungsumgebung oder gezielt für automatisierte Builds und Regressionstests.
Bei der Zusammenarbeit im Team sollte die Verbindung der Hauptnutzer den Ausschlag geben. Die Leitung eines einzelnen Teammitglieds ist kein Maßstab für alle.
Seoul mietenGeeignet für Teams mit Schwerpunkt in Südchina und Südostasien. Wenn eine reaktionsschnelle Remote-Verbindung wichtig ist, sollte Hongkong in die engere Wahl kommen.
Die Verbindung kann je nach Anbieter und grenzüberschreitender Route variieren. Testen Sie mit Ihrem üblichen Büronetzwerk, statt allein auf die geografische Nähe zu vertrauen.
Hongkong mietenGeeignet für Teams an der US-Ostküste sowie für Workflows mit Teammitgliedern oder Zielen für Build-Artefakte auf beiden Seiten des Atlantiks.
Die Richtwerte beziehen sich auf Netzwerke in der Nähe der US-Ostküste. Verbindungen aus Westeuropa und Asien sollten Sie separat testen. Die Zeitverschiebung ändert sich mit der Sommerzeit.
Osten der USA mietenÜber jeden Link ist die jeweilige Region bereits vorausgewählt. Modell und Mietdauer legen Sie im nächsten Schritt fest. Die aktuelle Verfügbarkeit sehen Sie in Echtzeit im Portal.
Base M4 und Trunk M4 Pro sind an allen 5 Standorten verfügbar. Die Tabelle zeigt den Katalog, keine Live-Überwachung. Maßgeblich ist die Verfügbarkeit, die das Portal beim Bestellen in Echtzeit anzeigt.
| Modell | Singapur | Tokio | Seoul | Hongkong | Osten der USA |
|---|---|---|---|---|---|
| Base M4M4 · 16GB RAM · 256GB SSD | Verfügbar | Verfügbar | Verfügbar | Verfügbar | Verfügbar |
| Trunk M4 ProM4 Pro · 64GB RAM · 2TB SSD | Verfügbar | Verfügbar | Verfügbar | Verfügbar | Verfügbar |
Wählen Sie zuerst nach Rechenleistung und Unified Memory, dann nach dem Netzwerkpfad. Ein Standort in Teamnähe kann die Remote-Bedienung und Übertragung verbessern, ändert aber weder Chip noch Arbeitsspeicher oder SSD.
Prüfen Sie die Verbindung vom Nutzer zum Mac, vom Mac zum Repository und vom Mac zum Ziel für Build-Artefakte. Desktop-Entwicklung und unbeaufsichtigte CI haben unterschiedliche Engpässe – nicht jede Aufgabe muss am selben Standort laufen.
Teams in Südchina können zuerst Hongkong vergleichen, Teams in Südostasien Singapur. Grenzüberschreitende Routen unterscheiden sich in Festlandchina je nach Anbieter deutlich. Prüfen Sie SSH-Verbindungen, die VNC-Bedienung und Downloads von Build-Artefakten über das übliche Büronetzwerk. Wenn CI nur selten manuelle Eingriffe erfordert, sollten stabile Verbindungen zu Paketquellen und Repositorys Vorrang haben.
Teams in Japan sollten zuerst Tokio testen, Teams in Südkorea zuerst Seoul. Beide Standorte liegen in UTC+9. So lassen sich Builds, Log-Prüfungen und Übergaben einfacher innerhalb desselben Arbeitstags erledigen. Bei standortübergreifender Zusammenarbeit sollten sowohl die Desktop-Erfahrung der Hauptentwickler als auch die Dauer gemeinsamer Repository-Pulls in die Entscheidung einfließen.
Prüfen Sie zuerst den Osten der USA – besonders, wenn Nutzer, Repository oder Ziel für Build-Artefakte an der US-Ostküste liegen. Zugriffe von der Westküste und über den Atlantik sollten Sie separat testen. Wenn Teammitglieder an anderen Standorten nur Build-Ergebnisse ansehen, können sie lokal programmieren und Builds von einem Remote Runner ausführen lassen, um den Desktop-Datenverkehr zu reduzieren.
Testempfehlung: Führen Sie dasselbe Projekt möglichst zur gleichen Tageszeit aus und messen Sie einen frischen Pull, einen Build mit Cache und den Download der Build-Artefakte. Halten Sie Netzwerkumgebung, Cache-Zustand und Projektversion fest, damit ein Cache-Treffer nicht fälschlich als schnellerer Standort gewertet wird.
Jeder Standort bietet eine dedizierte öffentliche IP-Adresse. Verbindungsadresse, Port und Zugangsdaten finden Sie in den Details Ihrer Instanz im angemeldeten Portal. Leiten Sie diese Angaben nicht von öffentlichen Seiten oder beispielhaften Hostnamen ab.
Wenn Sie Repositorys, Artefaktdienste oder Firewalls mit einer Zulassungsliste konfigurieren, tragen Sie die tatsächliche Adresse erst ein, nachdem der Standort zugewiesen wurde. Nach einer Neuinstallation oder Neubestellung sollten Sie die Verbindungsdaten erneut prüfen.
VerbindungsinfosDie angegebene Leitungsbandbreite entspricht nicht automatisch Ihrer Downloadgeschwindigkeit. Die gebuchte Bandbreite sehen Sie in der Bestellkonfiguration und den Instanzdetails. Grenzüberschreitende Routen, Begrenzungen am Zielserver und parallele Übertragungen beeinflussen den Durchsatz.
Bei großen Projekten sollten Sie Paket-Downloads, Cache-Wiederherstellung und Uploads von Build-Artefakten gemeinsam prüfen. Eine niedrige Latenz garantiert keine schnellen Massentransfers; auch der Weg zu den einzelnen Repository-Diensten kann variieren.
Instanzdetails prüfenDer Standort lässt sich nicht spontan an einer bestehenden Maschine umstellen. Für einen Wechsel bestellen Sie im Zielgebiet neu und übertragen nach der Bereitstellung Ihr Projekt, den Cache und die erforderliche Konfiguration.
Erstellen Sie zuerst ein Backup und prüfen Sie anschließend die Zielumgebung. Aktualisieren Sie Runner-Registrierung, Verbindungsadresse und Zulassungslisten und führen Sie einen Build samt Artefaktprüfung durch. Planen Sie das Ende der bisherigen Miete erst, wenn der neue Standort einsatzbereit ist.
Zielstandort wählenJede Bereitstellung umfasst einen exklusiv genutzten physischen Mac mini. CPU, GPU, Unified Memory und Speicherplatz werden nicht mit anderen Mietern geteilt. Alle 5 Standorte sind an 365 Tagen im Jahr in Betrieb. Die Wahl der Region ändert nichts an dieser Isolation.
Bevor Sie Quellcode und Signaturmaterial auf einen Remote-Mac übertragen, prüfen Sie Zugriffsrechte, Backups und den Umgang mit Daten am Ende der Mietdauer. Angaben zu Isolation, Datenlöschung und Ausgleich bei Verfügbarkeitsproblemen finden Sie in den Sicherheitshinweisen.
Base M4 ab $20.3/Tag. Wählen Sie Region, Modell und Mietdauer. Prüfen Sie in der Bestellung die aktuelle Verfügbarkeit und den Preis in US-Dollar, bevor Sie die Zahlung bestätigen.
Zahlung nur mit USDT-TRC20 oder Visa / Mastercard / Amex (über Stripe). Welche Zahlungsoptionen verfügbar sind, zeigt die Backend-Schnittstelle an.