Für Nutzerinnen und Nutzer in Ostasien: ein Cloud-Mac mit kurzer Verbindung. Remote-Entwicklung, Xcode-Builds und App-Releases laufen auf Ihrem dedizierten physischen Rechner.
Keine VM. Zwei M4-Konfigurationen, vier Laufzeiten: pro Tag, Woche, Monat oder Quartal. Ab $20.8/Tag – noch am selben Tag startklar. Ohne Verlängerung endet der Dienst zum Laufzeitende.
Wählen Sie bei der Bestellung den gewünschten Standort und das Enddatum. Den aktuellen Verfügbarkeitsstatus sehen Sie in Echtzeit im Portal.
Beide Optionen sind dedizierte Mac mini M4. Wählen Sie Arbeitsspeicher und SSD passend zu Ihrem Projekt und anschließend die Laufzeit. Zusätzlich gebuchte Rechner für arbeitsintensive Phasen können ein eigenes Enddatum erhalten.
Angezeigt wird der Tagespreis. Alle Laufzeitpreise finden Sie auf der jeweiligen Karte.
Mac mini M4 / 16GB RAM / 256GB SSD
$20.8 /Tag
Ideal für die Remote-Entwicklung durch eine Person, einen Build-Job zur Zeit und gelegentliche Paket-Builds. Prüfen Sie zunächst die Projektabhängigkeiten und den benötigten Platz für lokale Caches.
Mac mini M4 / 24GB RAM / 512GB SSD
$41.2 /Tag
Mehr Platz für Entwickler-Tools, Projektabhängigkeiten und Build-Caches. Bei gemeinsamer Nutzung im Team sollten Sie Build-Jobs in eine Warteschlange einreihen, damit ressourcenintensive Aufgaben nicht gleichzeitig um Ressourcen konkurrieren.
Für Verbindungen aus Ostasien liegt der Richtwert für die Round-Trip-Latenz bei 30~60ms. Er dient als Orientierung bei der Standortwahl – er entspricht weder der gemessenen Durchschnittslatenz Ihres Netzwerks noch einer Garantie für jede Verbindung.
| Angabe | Richtwert und Einordnung |
|---|---|
| Standort und Zielgruppe | Tokio, für Nutzerinnen und Nutzer in Ostasien. |
| Round-Trip-Richtwert | 30~60ms |
| Verbindungsqualität | Maßgeblich ist Ihre tatsächliche Verbindung. Routing des Internetanbieters, standortübergreifende Verbindungen, Paketverlust und lokales WLAN können die Nutzung beeinflussen. |
| Betrieb | Der physische Rechner ist an 365 Tagen im Jahr in Betrieb. Bei Problemen können Sie nach der Anmeldung im Portal ein Support-Ticket erstellen. |
Interaktive Remote-Desktops reagieren besonders empfindlich auf Latenz und Jitter. Bei Builds spielen außerdem Projektgröße und Toolchain eine Rolle, bei Dateiübertragungen auch die Bandbreite. Testen Sie mit dem tatsächlichen Büronetzwerk Ihres Teams Bearbeitung, Build und Übertragung von Artefakten, bevor Sie sich für eine längere Laufzeit entscheiden.
Die Inbetriebnahme erfolgt am selben Tag und dauert voraussichtlich insgesamt etwa 4 Minuten. Die Angaben sind Richtwerte für die Schritte und die Bereitstellung – keine Zusage zur Zahlungsbuchung oder ein Countdown für einzelne Bestellungen. Den Fortschritt sehen Sie im Portal.
Legen Sie Arbeitsspeicher, SSD, Mietdauer und Enddatum fest. Für zusätzlichen Bedarf können Sie einen weiteren Rechner buchen, ohne den bereits genutzten zu ändern.
Bezahlen Sie mit USDT-TRC20 oder per Karte über Stripe. Prüfen Sie den Betrag in US-Dollar und die Zahlungsart und bewahren Sie die Bestellnummer auf. Bei einer Zahlung auf der Blockchain sollten Sie zusätzlich den Transaktions-Hash speichern.
Prüfen Sie Bestell- und Instanzstatus im Portal. Erstellen Sie während der Bereitstellung nicht wiederholt dieselbe Bestellung. Bei Problemen können Sie über die bestehende Bestellung ein Support-Ticket eröffnen.
Sobald der Rechner bereit ist, finden Sie die Verbindungsdaten in den Instanzdetails im Portal. Melden Sie sich mit Ihrem SSH-Public-Key an, prüfen Sie Speicherplatz und Entwicklertools und klonen Sie anschließend Ihr Projekt.
Voraussichtliche Gesamtdauer ≈ 4 Minuten
Halten Sie vor der ersten Nutzung Ihren SSH-Public-Key bereit. Sichern Sie vor dem Laufzeitende Ihren Code, Build-Artefakte und alle Einstellungen, die Sie behalten möchten. Ohne Verlängerung endet der Dienst zum Laufzeitende und der Rechner wird zurückgegeben. Es fällt keine zusätzliche Gebühr für die Beendigung an.
Berücksichtigen Sie das Netzwerk Ihres Teams, länger laufende Aufgaben und die Übergabe zum Laufzeitende, bevor Sie die Mietdauer festlegen.
Der Standort ist ein guter Kandidat für Ihre erste Prüfung, aber die geografische Entfernung ist nicht der einzige Faktor. 30~60ms ist ein Richtwert für die Round-Trip-Latenz; das tatsächliche Erlebnis hängt von der Verbindung jeder einzelnen Person ab. Mieten Sie zunächst tageweise, testen Sie typische Entwicklungsaufgaben und prüfen Sie dabei Reaktionszeit, Dateiübertragung und Build-Dauer. Entscheiden Sie anschließend, ob sich eine längere Laufzeit lohnt.
Installieren Sie Abhängigkeiten aus Ihrem tatsächlichen Repository, führen Sie einen vollständigen Archive-Build aus und laden Sie die Artefakte herunter. Protokollieren Sie Arbeitsspeicherbedarf, verfügbaren Speicherplatz und Build-Dauer. Prüfen Sie außerdem die benötigten Tool-Versionen und den Umgang mit Signaturmaterial. Beide Konfigurationen nutzen den M4; sie unterscheiden sich vor allem bei Arbeitsspeicher und SSD. Mehr Speicherplatz bedeutet nicht automatisch schnellere Builds.
Nutzen Sie den zusätzlichen Rechner nur für eine separate Warteschlange. Sichern Sie nach Abschluss Artefakte, benötigte Logs und Konfigurationen in einem von Ihnen verwalteten Speicher. Vergewissern Sie sich, dass keine Aufgaben mehr an den Rechner übermittelt werden, bevor er zum Laufzeitende heruntergefahren wird. Behandeln Sie einen neu gebuchten Rechner als neue Instanz und verlassen Sie sich nicht darauf, dass Adresse, Zugangsdaten oder lokale Dateien des alten Rechners übernommen werden.
Für den Test tageweise mieten, bei dauerhaftem Bedarf eine längere Laufzeit wählen. Prüfen Sie Konfiguration, Standort und Enddatum vor der Zahlung.