Standorte im Asien-Pazifik-Raum

4 Standorte, einheitliche Preise

Exklusiv zugewiesene physische Mac mini statt geteilter virtueller Maschinen. Wählen Sie den Standort nach Team und Datenfluss und testen Sie anschließend die Verbindung über Ihr eigenes Netzwerk. Ein Standortwechsel ändert nichts am Preis der jeweiligen Konfiguration.

Cloud-Mac mieten Preise ansehen
Singapur · Tokio · Seoul · Hongkong 2 M4-Konfigurationen Tag / Woche / Monat / Quartal

Abrechnung in USD. Alle Standorte sind ganzjährig verfügbar. Die aktuelle Verfügbarkeit sehen Sie bei der Bestellung im Kundenportal.

Standortübersicht

Gleiche Konfigurationen, passend zu Ihrem Workflow

Alle vier Standorte bieten GNU Core M4 und GNU Studio M4. Jede Bestellung umfasst einen exklusiv zugewiesenen physischen Rechner. CPU, Arbeitsspeicher und Speicherplatz werden nicht mit anderen Kunden geteilt.

SG Zusammenarbeit in Südostasien

Singapur

Für Entwicklungsteams mit Schwerpunkt Südostasien. Hosten Sie selbstverwaltete CI-Runner, Dependency-Caches und tägliche Builds am selben Standort, damit weniger Daten zwischen Regionen übertragen werden müssen.

  • GNU Core M4M4 · 16GB RAM · 256GB SSD
    Verfügbar
  • GNU Studio M4M4 · 24GB RAM · 512GB SSD
    Verfügbar

Optionale Erweiterungen+1TB SSD, +2TB SSD, Thunderbolt-5-Verbindung (pro Rechner). Klären Sie bei mehreren verbundenen Geräten vorab die Anschlussmöglichkeiten.

Prüfen Sie vor der Wahl die Reaktionszeit über das Büronetzwerk Ihres Teams sowie die Übertragung von Code-Repositories und Build-Artefakten.

In Singapur mieten
JP Workflows für Japan

Tokio

Für die Zusammenarbeit mit Teams in Japan, japanische Lokalisierung und Builds für den japanischen Markt. Führen Sie Xcode- Builds, Simulator-Regressionstests und die Archivierung von Artefakten auf einem Rechner aus.

  • GNU Core M4M4 · 16GB RAM · 256GB SSD
    Verfügbar
  • GNU Studio M4M4 · 24GB RAM · 512GB SSD
    Verfügbar

Optionale Erweiterungen+1TB SSD, +2TB SSD, Thunderbolt-5-Verbindung (pro Rechner). Zusätzliche SSDs eignen sich für Build-Caches oder Asset-Verzeichnisse.

Der Standort beeinflusst nicht die App-Store-Prüfrichtlinien und ersetzt keine Tests mit lokalen Netzwerken, physischen Geräten oder in realen Nutzerumgebungen.

In Tokio mieten
KR Korea & Spieleveröffentlichungen

Seoul

Für Spieleveröffentlichungen, Client-Builds und Lokalisierungstests mit Teams in Korea. Unity- oder Flutter-Projekte lassen sich am Standort für macOS erstellen und anschließend in den Release-Workflow Ihres Teams übertragen.

  • GNU Core M4M4 · 16GB RAM · 256GB SSD
    Verfügbar
  • GNU Studio M4M4 · 24GB RAM · 512GB SSD
    Verfügbar

Optionale Erweiterungen+1TB SSD, +2TB SSD, Thunderbolt-5-Verbindung (pro Rechner). Prüfen Sie bei großen Projekten den gesamten Speicherbedarf für Assets, Caches und Ausgabedateien.

Wenn Sie hauptsächlich interaktiv debuggen, testen Sie zuerst über Ihr tatsächliches Büronetzwerk. Entscheiden Sie nicht allein nach der Entfernung auf der Karte.

In Seoul mieten
HK Zusammenarbeit in der Region

Hongkong

Für Remote-Entwicklung sowie Audio- und Videoarbeit mit Teams in der Region. Führen Sie umfangreiche Transcodierungen in der Cloud aus und übertragen Sie fertige Dateien per SFTP zurück, ohne die grafische Verbindung dauerhaft offen zu halten.

  • GNU Core M4M4 · 16GB RAM · 256GB SSD
    Verfügbar
  • GNU Studio M4M4 · 24GB RAM · 512GB SSD
    Verfügbar

Optionale Erweiterungen+1TB SSD, +2TB SSD, Thunderbolt-5-Verbindung (pro Rechner). Planen Sie bei vielen Assets Projektdateien und Systemlaufwerk getrennt.

Die Verbindung kann je nach Provider variieren. Testen Sie Festnetz, Heimnetz und Mobilfunk jeweils separat.

In Hongkong mieten

„Verfügbar“ bedeutet, dass die Konfiguration regulär bestellt werden kann. Die aktuelle Verfügbarkeit und mögliche Erweiterungen sehen Sie im Kundenportal. Diese Seite enthält keine geschätzten Latenzwerte oder historischen Messdaten.

Wer nutzt den Rechner?

Standortempfehlungen ersetzen keinen Verbindungstest

Ein Team muss nicht alle Aufgaben am selben Standort ausführen. Bei manueller Arbeit zählt die interaktive Verbindung, bei automatisierten Builds der Datenfluss zwischen Repository und Artefaktspeicher. Für Markttests gelten eigene Anforderungen.

Passenden Ausgangsstandort nach Workflow wählen
AnforderungStandortWarum?Vor der Bestellung prüfen
Nutzer in SüdostasienSingapurWenn Entwickler, Code-Dienste oder Empfänger von Build-Artefakten in Südostasien sitzen, ist Singapur ein guter Ausgangspunkt für Tests.Testen Sie die Verbindung über das übliche Teamnetzwerk und prüfen Sie die Wege für Downloads und Uploads von Artefakten.
App-Store-Vorbereitung und Lokalisierungstests für JapanTokioErleichtert die Zusammenarbeit mit Teams in Japan und die zentrale Verwaltung der Build-Umgebung. Der Standort garantiert kein Prüfungsergebnis.Prüfen Sie Sprache, Zeitzone, Simulatoren sowie Tests auf physischen Geräten. Trennen Sie Build-Umgebung und Markt-Netzwerkumgebung.
Korea & SpieleveröffentlichungenSeoulGeeignet für Builds, Asset-Verarbeitung und Lokalisierungstests mit Teammitgliedern in Korea.Testen Sie die Synchronisierung großer Projekte und die Netzwerkverbindung des Clients zu den tatsächlich genutzten Diensten.
Zusammenarbeit in der RegionHongkongEin möglicher gemeinsamer Standort für Builds und Transcodierungen mit Teammitgliedern an mehreren Orten.Lassen Sie alle Beteiligten an ihrem jeweiligen Standort testen. Ein einzelnes Ergebnis ist nicht repräsentativ für das ganze Team.
Verbindung testen

Erst den Arbeitsalltag testen, dann langfristig planen

Bei der Bildschirmfreigabe werden fortlaufend Bildschirminhalte und Eingaben übertragen. Deshalb wirken sich Round-Trip-Latenz, Jitter und Paketverlust besonders stark aus. Builds per SSH benötigen keine kontinuierliche Bildübertragung, doch Downloads von Abhängigkeiten und Uploads von Artefakten hängen weiterhin von der verfügbaren Bandbreite ab.

Bildschirmfreigabe: Reagiert alles direkt?

Testen Sie den möglichen Standort über die Verbindungstest-Funktion im Kundenportal und das Netzwerk, das Sie später regelmäßig nutzen. Sobald Sie Zugriff auf den Rechner haben, prüfen Sie mit Ihrem üblichen Client Eingaben, Fensterbewegungen und das Scrollen im Editor.

Ein scharfes Bild mit gelegentlichen Aussetzern kann auf Jitter hindeuten. Bei durchgehend langsamer Übertragung sollten Sie auch Ihren Up- und Download sowie Hintergrundsynchronisierungen prüfen. Eine geringere Auflösung reduziert das übertragene Datenvolumen, beseitigt aber nicht die Round-Trip-Latenz.

Automatisierte Builds: den gesamten Datenfluss prüfen

Testen Sie nicht nur die Verbindung von Ihrem Rechner zum Server. Ein CI-Lauf umfasst auch das Klonen des Repositorys, das Herunterladen von Abhängigkeiten, den Zugriff auf Caches und das Hochladen von Artefakten. Der Standort dieser Dienste wirkt sich auf die Wartezeit aus.

Protokollieren Sie einen sauberen Build und einen Build mit Cache und vergleichen Sie Download, Kompilierung und Upload. Läuft die Kompilierung stabil, aber der Upload langsam, prüfen Sie zuerst den Datenfluss der Artefakte, statt das Problem unmittelbar dem Arbeitsspeicher zuzuschreiben.

  1. 01

    Im echten Netzwerk testen

    Öffnen Sie den Verbindungstest im Kundenportal über Ihr übliches Büro- oder Heimnetzwerk. Ein kurzfristiger Hotspot ersetzt keinen Test in der festen Arbeitsumgebung. Bei mehreren Nutzern sollte jeder Hauptnutzer separat testen.

  2. 02

    Zu üblichen Arbeitszeiten testen

    Wiederholen Sie den Test während Ihrer normalen Arbeitszeiten und achten Sie auf Latenzschwankungen und Verbindungsstabilität. Ein einzelner Messwert bildet nur den aktuellen Zustand ab, nicht die gesamte Mietdauer.

  3. 03

    Messwerte für Rückfragen notieren

    Halten Sie bei Problemen Standort, Testzeit mit Zeitzone, Client-Typ und beobachtetes Verhalten fest. Bei einer bestehenden Bestellung können Sie nach der Anmeldung im Kundenportal ein Support-Ticket erstellen. Senden Sie keine Passwörter oder privaten Schlüssel per E-Mail.

Verbindung im Kundenportal testen Remote-Zugriff erklärt
Arbeiten über mehrere Standorte

Den Zweck jedes Rechners klar festlegen

Instanzen an verschiedenen Standorten sind eigenständige Rechner. Datenträger, Build-Caches und Projektdateien werden nicht automatisch synchronisiert. Legen Sie vor dem Einsatz mehrerer Rechner Namensregeln, Umgebungen und Rückübertragungswege fest – so müssen Sie später nicht nach dem Rechner mit dem richtigen Paket suchen.

01 / Namen

Standort und Aufgabe im Namen

Verwenden Sie ein Namensschema wie „Standortcode–Projekt–Zweck–Nummer“, zum Beispiel jp-mobile-build-01. Halten Sie in einer eigenen Instanzübersicht zusätzlich die Kennung im Kundenportal, den Verantwortlichen und den Verwendungszweck fest. So müssen Sie Rechner nicht allein anhand ihrer IP-Adresse unterscheiden.

Dies ist eine Empfehlung für die Verwaltung, kein voreingestellter Hostname. Aktualisieren Sie nach Änderungen an Standort oder Aufgabe auch die Labels Ihrer CI-Runner und Ihre interne Dokumentation.

02 / Umgebung

Toolchain festlegen, Zugangsdaten trennen

Dokumentieren Sie die Versionen von macOS, Xcode, Abhängigkeiten und Build-Skripten im Projekt. Prüfen Sie den Ablauf zuerst auf einem Rechner und richten Sie die übrigen Standorte anhand derselben Schritte ein. So vermeiden Sie Abweichungen durch manuelle Änderungen.

Richten Sie für jeden Rechner eigene Zugriffsschlüssel ein und vergeben Sie Berechtigungen für Repositorys und Artefaktverzeichnisse nach Bedarf. Hinterlegen Sie weder Signaturmaterial noch Passwörter oder private Schlüssel im Code-Repository.

03 / Daten

Artefakte übertragen, Mietdauer einzeln prüfen

Übertragen Sie nach dem Build Artefakte, Logs und erforderliche Konfigurationssicherungen in den vom Team verwalteten Speicher. Zusätzliche SSDs sind Teil der Speicherplanung für den jeweiligen Rechner. Sie dienen weder als standortübergreifender gemeinsamer Speicher noch als Backup-Dienst.

Prüfen Sie Laufzeit und Ablaufdatum jeder Bestellung einzeln im Kundenportal. Behandeln Sie einen Standortwechsel wie die Migration auf eine neue Instanz. Exportieren Sie vor der Rückgabe alle Daten, die Sie behalten möchten. Anschließend werden Systemlaufwerk und zusätzliche SSDs gelöscht.

Standort wählen, Konfiguration und Mietdauer prüfen.

Alle vier Standorte haben dieselben Preise. Für kleinere Builds empfiehlt sich die 16GB-Konfiguration. Bei mehreren Simulatoren oder Inferenzaufgaben sollten Sie die 24GB-Konfiguration prüfen. Planen Sie für umfangreiche Assets und Caches zusätzlichen SSD-Speicher ein.

Tarife nach Standort Cloud-Mac mieten