Xcode-Arbeitsplatz × physischer Server

Unser Fokus: echte Macs
im Rechenzentrum

XcodeNode Cloud-Mac vermietet dedizierte Apple-Silicon-Macs. Keine virtuellen Maschinen und keine gemeinsam genutzte Build-Queue: Sie erhalten einen ganzen physischen Server für Xcode, Simulatoren, Kommandozeilenaufgaben und Ihre eigenen CI-Pipelines.

Cloud-Mac mieten Konfigurationen & Preise

Zwei Konfigurationen, vier Standorte, Mietzeiträume von Tag, Woche, Monat oder Quartal. Die Verfügbarkeit wird in Echtzeit im Portal angezeigt.

Der Name beschreibt genau, was Sie bekommen

Xcode steht für einen vertrauten, nativen Entwicklungsplatz: Die grafische macOS-Oberfläche und die Kommandozeile stehen vollständig zur Verfügung. Sie verwalten Ihre Projekte, Toolchains und Build-Skripte selbst. Node bezeichnet einen eigenständig bereitgestellten physischen Server mit klar definierter Konfiguration und Mietdauer – die Rechenleistung wird nicht mit anderen Mietkonten geteilt.

Bereitstellung: Ein eigener physischer Server
Konfigurationen: Node Core M4 / Node Pro M4
Mietzeiträume: Tag / Woche / Monat / Quartal
Abrechnung: USD

Klarheit vor der Bereitstellung

Drei Prinzipien für jeden Auftrag

Ob ein Angebot zu einem Projekt passt, zeigt sich nicht an großen Versprechen. Entscheidend sind die Ressourcenzuweisung, die konkreten Konfigurationen und überprüfbare Zusagen.

Ein Server, ein Mietkonto

Jeder Auftrag umfasst einen eigenen Apple-Silicon-Server. CPU, GPU, Unified Memory und lokaler Speicher werden nicht mit anderen Mietkonten geteilt. Ihre Projekte laufen nicht in virtuellen Umgebungen auf einem gemeinsam genutzten Host.

Dediziert bedeutet, dass der Server einem Mietkonto zugeordnet ist – nicht, dass ihn nur eine Person nutzen darf. Ihr Team kann den Zugriff nach den eigenen Berechtigungsregeln organisieren. Aufgaben auf demselben Server teilen sich jedoch dessen Ressourcen.

Was das für die Entwicklung bedeutet

Sie nutzen macOS, Xcode, Simulatoren und Metal nativ – ohne Ihren Workflow an eine Virtualisierungsschicht anpassen zu müssen.
Wie viele CI-Aufgaben parallel laufen, bestimmen Sie selbst. Bei mehreren gleichzeitigen Builds sollten Sie Speicherbedarf und Festplattenbelegung im Blick behalten.
Projekte, Abhängigkeiten und Automatisierungsskripte auf dem Server verwalten Sie selbst. Ein bereitgestellter Server bedeutet nicht, dass wir Ihre Pipelines betreiben.

Klare Konfigurationen und Preise

Im Katalog stehen genau zwei Konfigurationen: Node Core M4 mit M4 / 16GB / 256GB SSD und Node Pro M4 mit M4 Pro / 64GB / 2TB SSD. Chip, Arbeitsspeicher und Speicherplatz sind einzeln ausgewiesen – statt vager Angaben wie „High-End“.

Für die vier Mietzeiträume gelten jeweils eigene Preise. Speichererweiterungen und Thunderbolt-5-Verbindungen werden separat aufgeführt. Prüfen Sie zuerst die Basiskonfiguration, dann die Zusatzoptionen und schließlich den Gesamtbetrag an der Kasse.

Das können Sie vor der Buchung prüfen

Node Core M4 ab $21.3 pro Tag; Node Pro M4 ab $59.1 pro Tag. Alle Preise für die Mietzeiträume finden Sie auf der Planseite.
Beide Konfigurationen sind in Singapur, Tokio, Seoul und Hongkong verfügbar. Die aktuelle Verfügbarkeit wird im Portal angezeigt.
Alle Beträge werden in US-Dollar abgerechnet. Als Zahlungsmethoden stehen ausschließlich USDT-TRC20 und Visa / Mastercard / Amex über Stripe zur Verfügung.

Leistung und Verfügbarkeit mit realistischen Maßstäben

Die Build-Zeit auf einem Server hängt unter anderem von Projektumfang, Xcode-Version, Cache, heruntergeladenen Abhängigkeiten und Parallelität ab. Ohne einheitliche Testbedingungen lässt sich ein einzelner Messwert nicht auf alle Projekte übertragen.

Alle vier Standorte sind an 365 Tagen im Jahr regulär in Betrieb. Liegt die monatliche Verfügbarkeit unter 99.9%, wird die Mietdauer anteilig entsprechend der Ausfallzeit verlängert. Die genauen Bedingungen und Grenzen erläutern wir auf der Sicherheitsseite.

So prüfen Sie, ob es passt

Messen Sie mit demselben Projekt und derselben Toolchain die Build-Zeit beim ersten Build und mit bereits gefülltem Cache.
Behalten Sie Speicherdruck, wachsenden Speicherbedarf und die Aufgabenwarteschlange im Blick, statt nur Chipnamen zu vergleichen.
Testen Sie die Verbindung von Ihrem eigenen Netzwerk aus. Der Standort hilft bei der Auswahl, ist aber keine Garantie für eine bestimmte Latenz.

Vier Standorte in Asien-Pazifik

Der Arbeitsplatz sollte zum Team passen

Singapur, Tokio, Seoul und Hongkong decken unterschiedliche Zeitzonen und Netzwerkpfade ab. Berücksichtigen Sie bei der Wahl nicht nur die Entfernung auf der Karte, sondern auch die Desktop-Reaktionszeit, Git-Zugriffe, Downloads von Abhängigkeiten und Uploads für die Verteilung.

SG · UTC+8

Singapur

Geeignet für Arbeitszeiten in Südostasien. Wenn Ihr Team tagsüber interaktiv debuggt und nachts Automatisierungen laufen lässt, können alle dieselbe Toolchain auf dem Server nutzen – mit weniger Wechseln zwischen lokalem Gerät und CI-Umgebung.

Arbeiten Teammitglieder aus verschiedenen Regionen zusammen, testen Sie Desktop-Reaktionszeit und Repository-Downloads getrennt. Diese Netzwerkpfade können sich unterschiedlich verhalten.

Beide Konfigurationensg

JP · UTC+9

Tokio

Passend zu den Arbeitszeiten von Teams in Japan und Ostasien. Ideal, wenn Sie regelmäßig die grafische Oberfläche öffnen müssen, um Simulatoren, Archivdateien und Release-Artefakte zu prüfen.

Für die Verteilung sollten Sie sowohl den Abruf von Abhängigkeiten als auch den Upload von Artefakten testen. Der Standort allein sagt nichts über die Upload-Geschwindigkeit aus.

Beide Konfigurationenjp

KR · UTC+9

Seoul

In Reichweite von Teams in Korea und Nordostasien. Tagsüber debuggen und nachts bauen – auf demselben physischen Server bleiben Projektpfade, Cache und Toolversionen konsistent.

Bei einem dauerhaft laufenden Runner sollten Sie zuerst Parallelität und Speicherbedarf einschätzen. Der Standort beeinflusst den Netzwerkpfad, ersetzt aber keine Ressourcenplanung.

Beide Konfigurationenkr

HK · UTC+8

Hongkong

Für die Zusammenarbeit mit Teams in Südchina und Südostasien. Wenn Sie Projekte per SSH verwalten und Ergebnisse gelegentlich am Desktop prüfen, sollten Sie Kommandozeilenverbindung und grafische Oberfläche getrennt testen.

Bei großen Repositories und Artefakten empfiehlt sich ein eigener Durchsatztest. Ein einzelner Ping zeigt nur die Round-Trip-Zeit, nicht die Leistung des gesamten Workflows.

Beide Konfigurationenhk

Die Standorte sind auf Entwicklerteams in Asien-Pazifik und App-Store-Workflows ausgerichtet. Netzwerkwerte hängen vom Standort des Clients, dem Anbieter und dem jeweiligen Ziel ab. Testen Sie am besten mit Ihrem eigenen Projekt.

Klare Zuständigkeiten – vor und nach der Übergabe

Wir betreiben den Server, Sie steuern die Entwicklung

Der Betrieb im Rechenzentrum und die Fernverwaltung der Stromversorgung ermöglichen den Zugriff auf die Geräte aus der Ferne. Festplattenlöschung und Neuinstallation bereiten den Wechsel des Mietkontos vor. Für Projekt-Backups sind Sie selbst verantwortlich.

01
Betrieb im Rechenzentrum

Die physischen Server laufen in einer Rechenzentrumsumgebung. Sie brauchen keinen dauerhaft eingeschalteten Entwicklungsrechner im Büro, verwalten Abhängigkeiten, Aufgaben und Daten auf dem System aber weiterhin selbst.
02
Fernverwaltung der Stromversorgung

Die Stromversorgung aus der Ferne zu verwalten, gehört zum Serverbetrieb. Ist ein Server nicht erreichbar, notieren Sie zunächst Zeitpunkt und Verbindungsart und erstellen Sie anschließend ein Ticket im angemeldeten Portal. So lassen sich Anwendungsfehler besser von Geräteproblemen unterscheiden.
03
Löschen und Neuinstallation vor der Übergabe

Vor der Übergabe an das nächste Mietkonto werden die Festplatten gelöscht und das System neu installiert. Es werden also nicht lediglich Projektordner entfernt und anschließend Zugangsdaten für eine Umgebung des vorherigen Mietkontos ausgegeben.
04
Daten während der Mietzeit

Planen Sie Backups für Code, Zertifikate, Build-Artefakte und aufzubewahrende Caches ein. Die Datenlöschung nach Ende der Mietzeit ersetzt kein Backup. Exportieren Sie Ihre Daten vor der Rückgabe und prüfen Sie, ob sie sich wiederherstellen lassen.

Bei einer Störungsmeldung helfen konkrete Angaben

Wenn Sie bereits mieten, nennen Sie im Portal-Ticket Ihre Bestellnummer, den Standort, Zeitpunkt und Zeitzone, die Verbindungsart sowie eine kurze Fehlerbeschreibung. Anfragen vor dem Kauf, zu mehreren Servern und Sicherheitsmeldungen senden Sie bitte an support@xcodenode.com. Senden Sie niemals Passwörter, private Schlüssel oder vollständige Zugangsdaten.

Im Portal anmelden und Ticket erstellen

Aus Sicht des Arbeitsalltags

Ein fester Arbeitsplatz, zwei Arten der Zusammenarbeit

Die folgenden Ich-Perspektiven veranschaulichen zwei typische Anforderungen. Sie sind weder Kundenbewertungen noch dokumentierte Leistungstests.

„Ich brauche einen Arbeitsplatz mit festgelegten Toolversionen. Kolleginnen und Kollegen aus verschiedenen Regionen greifen im Wechsel darauf zu und hinterlassen beim Übergang Build-Ergebnisse und Aufgabenprotokolle. So muss nicht jede Person die Umgebung neu einrichten. Vor Paralleltests prüfe ich zuerst den Speicherbedarf des Servers.“

Technische Leitung eines verteilten TeamsBeispiel für Zusammenarbeit · Toolchain und Aufgabenübergabe

„Ich möchte die Builds für Kundenprojekte auf einem eigenen Server ausführen. Die Mietdauer richte ich nach dem Projekt aus. Vor dem Ende exportiere ich Code und Artefakte und prüfe das Backup. Bei der Wahl der Konfiguration teste ich mit einem echten Projekt, statt mit dem Schlagwort ‚High Performance‘ zu kalkulieren.“

Leitung eines EntwicklungsstudiosBeispiel für Zusammenarbeit · Projektlaufzeit und Datenexport

Erst die Bedingungen prüfen, dann den passenden Server wählen

Auf der Sicherheitsseite erfahren Sie mehr über Isolation, Zugriffskontrolle und den Umgang mit Daten. Die Planseite zeigt beide Konfigurationen, alle vier Mietzeiträume und die Zusatzoptionen. Lesen Sie beides durch und testen Sie anschließend mit Ihrem eigenen Projekt, ob der Server zu Ihren Anforderungen passt.

Sicherheit & Datenverarbeitung Beide Pläne ansehen