Eine Cloud-Mac-Workstation für Entwickler in Ostasien. Kompilieren, Simulator-Tests und CI-Jobs laufen auf einem dedizierten physischen Server, während Sie lokal weiterprogrammieren.
Base M4 ab $20.3/Tag. Keine VM, Abrechnung in US-Dollar.
Für Builds einer einzelnen App genügt meist der Base M4. Bei großen Swift-Projekten, CI mit vielen Targets und MLX-Experimenten empfiehlt sich der Trunk M4 Pro. Die Preise unten gelten für die vollständige Hardware; optionale Extras wählen Sie separat. Umgerechnete Vergleichspreise sind keine tatsächlichen Rechnungsbeträge.
Abrechnungszeitraum auswählen
Der Einstieg für eine zuverlässige Build-Pipeline. Geeignet für leichte Builds, das Paketieren einer einzelnen App und die tägliche Remote-Entwicklung.
$20.3/Tag
Planen Sie Speicherplatz für Dependency-Caches, Build-Artefakte und Simulator-Daten ein. Wenn Ihr Projekt wächst, können Sie bei der Bestellung zusätzlichen SSD-Speicher auswählen.
Base M4 mietenMehr Arbeitsspeicher und Speicherplatz für anspruchsvolle Projekte. Geeignet für CI mit vielen Targets, große Swift-Projekte und Experimente mit lokaler Modellinferenz.
$60/Tag
Die 64GB Unified Memory werden von CPU und GPU gemeinsam genutzt. Prüfen Sie die Zahl paralleler Jobs zunächst mit einem realen Projekt und passen Sie anschließend die Runner-Parallelität an.
Trunk M4 Pro mietenDer Wechsel hier dient nur dem Preisvergleich und löst keine Bestellung aus. Prüfen Sie bei der Konfiguration vor der Bestellung Modell, Standort, Abrechnungszeitraum und Extras und kontrollieren Sie anschließend den Gesamtbetrag. Die Verfügbarkeit wird live im Portal angezeigt.
Für Nutzer in Ostasien liegt der Richtwert für die durchschnittliche Latenz bei 30~60 ms. Er hilft bei der ersten Standortwahl, ist aber keine Messung Ihres individuellen Netzwerks und keine Zusage für die Ende-zu-Ende-Latenz.
Die Reaktionszeit bei SSH-Eingaben und das Ziehen von Fenstern in VNC hängen von Laufzeit und Jitter ab. Beim Kompilieren zählen vor allem CPU, Arbeitsspeicher und Speicherplatz auf dem Remote-Server. Schnelle Builds bedeuten nicht automatisch, dass sich jede Desktop-Interaktion ebenso flüssig anfühlt.
Starten Sie den Build zunächst per SSH und öffnen Sie die grafische Oberfläche nur bei Bedarf.
Routing des Internetanbieters, WLAN, Unternehmens-Proxy und lokaler Upload beeinflussen das Ergebnis. Aussagekräftiger als ein einzelner Latenzwert ist ein Test mit einem echten Repository: Klonen, Dependencies herunterladen und Artefakte zurückübertragen.
Notieren Sie den verwendeten Internetzugang und die Verbindungsmethode, damit Sie den Test wiederholen können.
Der physische Server verfügt über eine eigene öffentliche IP-Adresse. Lassen Sie längere Jobs von einem Runner ausführen, damit eine unterbrochene lokale Verbindung nicht den gesamten Vorgang beendet. Verbindungsadresse und Zugangsdaten finden Sie in den Instanzdetails.
Caches lassen sich neu erstellen; Quellcode und wichtige Artefakte sollten zusätzlich gesichert sein.
Bei reibungslosem Ablauf dauert der gesamte Vorgang voraussichtlich etwa 4 Minuten. Das ist ein Richtwert für die Bedienzeit, kein Countdown für die Bereitstellung. Zahlungsbestätigung und Fortschritt des System-Resets sehen Sie im Portal.
Wählen Sie Modell, Standort und Abrechnungszeitraum. Entscheiden Sie anhand des Speicherbedarfs Ihres Projekts, ob zusätzlicher Speicher nötig ist. Prüfen Sie den Hardwarepreis, Extras und den Gesamtbetrag.
Ca. 30 Sekunden
Unterstützt werden ausschließlich USDT-TRC20 und Visa / Mastercard / Amex (über Stripe). Abgerechnet wird in US-Dollar. Welche Zahlungsanbieter verfügbar sind, hängt von der Rückmeldung der Backend-Schnittstelle ab.
Ca. 40 Sekunden; Zahlungsbestätigung zusätzlich
Nach bestätigter Zahlung beginnt die Bereitstellung des physischen Servers. Warten Sie, bis der System-Reset abgeschlossen ist, und prüfen Sie den Instanzstatus. Verwenden Sie vorher nicht wiederholt alte Adressen oder Zugangsdaten.
Ca. 2 Minuten
Die SSH- und VNC-Zugangsdaten finden Sie in den Instanzdetails. Testen Sie zuerst den Kommandozeilenzugriff und die Projekt-Dependencies, bevor Sie Zertifikate, Runner und echte Build-Jobs einrichten.
Ca. 50 Sekunden
Klären Sie Standort, Verbindung und Umzugsmöglichkeiten, bevor Sie Standortwahl und Hardwarekonfiguration miteinander verwechseln.
Nein. Über die Schaltflächen auf dieser Seite wird das passende Modell vorausgewählt, der Standort ist damit aber noch nicht reserviert. Wählen Sie Tokio in der Bestellkonfiguration aus und prüfen Sie Abrechnungszeitraum und Extras vor der Zahlung. Die aktuelle Verfügbarkeit wird live im Portal angezeigt; diese Seite zeigt keine Echtzeit-Zuweisung.
Nein. 30~60 ms ist ein regionaler Richtwert und keine feste Latenz für einzelne Teammitglieder. Auch innerhalb derselben Region können Anbieter, Unternehmenszugänge und Proxy-Routen deutliche Unterschiede verursachen. Lassen Sie die Personen, die hauptsächlich mit dem Server arbeiten, die Verbindung jeweils selbst testen. Bei automatisierten Builds sind vor allem die Übertragungswege für Repository, Dependencies und Artefakte relevant.
Für einen Wechsel des Standorts ist eine neue Bestellung erforderlich. Der Standort lässt sich nicht einfach an der bestehenden Instanz ändern. Sichern Sie Quellcode, Dependency-Liste und wichtige Daten so, dass sie wiederhergestellt werden können. Prüfen Sie Builds und Verbindungen auf der neuen Instanz, bevor Sie den bisherigen Mietzeitraum beenden. Die öffentliche IP-Adresse und Zugangsdaten der alten Instanz funktionieren nicht für die neue.
Base M4 ab $20.3/Tag. Testen Sie Ihr echtes Projekt, bevor Sie den nächsten Mietzeitraum festlegen.