Jeder physische Apple-Silicon-Knoten ist einem einzigen Kunden vorbehalten. Es handelt sich nicht um eine virtuelle Maschine; CPU, GPU und Unified Memory werden nicht mit anderen Kunden geteilt.
Prüfen Sie zuerst Isolation, Zugriff und Datenverarbeitung – und verlagern Sie dann Entwicklungs- und Build-Aufgaben.
Knoten bei bestehender Bestellung nicht erreichbar? Melden Sie sich im Kundenportal an und erstellen Sie ein Support-Ticket mit Bestellnummer und Zeitpunkt des Ausfalls.
Verfügbarkeitsziel und tatsächlich gemessene Werte sind nicht dasselbe. Hier finden Sie das Serviceziel und die Berechnungsgrundlage – nicht vermeintliche Messwerte.
Monatliches Verfügbarkeitsziel
99,9%
Alle Knoten sind 365 Tage im Jahr in Betrieb. Liegt die monatliche Verfügbarkeit unter 99,9 %, verlängern wir die Mietdauer anteilig entsprechend der bestätigten Ausfallzeit.
Die türkisfarbene Skala zeigt das Serviceziel, keine täglichen Messergebnisse.
Wir prüfen die Erreichbarkeit der Knoten, Beginn und Ende von Ausfällen sowie die zugehörigen Bestellungen. Da hier keine überprüfbaren täglichen Messdaten veröffentlicht sind, zeigen wir weder eine durchgehend grüne Tagesübersicht noch behaupten wir, dass in den letzten 90 Tagen alles störungsfrei lief.
Die monatliche Verfügbarkeit berechnet sich aus der gesamten Servicezeit des Monats abzüglich der bestätigten Ausfallzeit, geteilt durch die gesamte Servicezeit des Monats. Geben Sie bei Ihrem Antrag den Zeitpunkt und die verwendete Zeitzone an; eine eigene Ursachenanalyse ist nicht nötig. Bewahren Sie die ursprüngliche Fehlermeldung auf – sie hilft mehr als die pauschale Angabe „Verbindung fehlgeschlagen“.
Unterbrechungen durch eigene Handlungen sowie Fälle höherer Gewalt richten sich nach den Servicebedingungen. Ein einzelner SSH-Timeout belegt nicht automatisch, dass der gesamte Knoten ausgefallen ist. Für die Prüfung zählen auch Verbindungsart, Netzwerkpfad und Knotenprotokolle. Einzelheiten zum Geltungsbereich finden Sie in den Servicebedingungen.
Die exklusive Nutzung verhindert Ressourcenkonflikte zwischen Kunden. Berechtigungen für Entwicklungsprojekte, Teamzugriff und parallele Aufgaben müssen Sie weiterhin auf dem Rechner selbst verwalten.
Jede Bestellung umfasst einen exklusiven physischen Rechner; es wird keine virtuelle Instanz auf einem gemeinsam genutzten Host eingerichtet. Andere Kunden nutzen weder CPU, GPU noch Unified Memory dieses Rechners und teilen auch nicht Ihre macOS-Arbeitsumgebung.
Die macOS-Oberfläche und die Kommandozeile stehen vollständig zur Verfügung. Xcode, Simulatoren und Metal laufen in einer nativen Umgebung. Mehrere Builds, Tests oder Inferenzaufgaben, die Sie gleichzeitig starten, teilen sich weiterhin die Ressourcen dieses Rechners.
Wenn Ihr Team den Knoten im Wechsel nutzt, verwalten Sie Systemkonten, SSH-Schlüssel und Zugriffsrechte für Projektverzeichnisse pro Mitglied. Exklusive Nutzung bedeutet nicht, dass jedes Teammitglied Adminrechte braucht oder dass ein privater Schlüssel gemeinsam verwendet werden sollte.
Halten Sie bei Leistungstests auch Projektumfang, Xcode-Version, Zahl paralleler Aufgaben und Cache-Status fest. Exklusive Nutzung verhindert Konkurrenz mit anderen Kunden, garantiert aber keine feste Build-Dauer für beliebige Workloads.
Nach Ende der Mietdauer werden die Festplatten gelöscht und das System neu installiert, bevor der Rechner an den nächsten Kunden geht. Der Knoten ist kein dauerhaftes Archiv; sichern Sie Ihre Daten unabhängig vom Mietgerät.
Sichern Sie nicht eingecheckten Code, Build-Artefakte sowie benötigte Konfigurationen und Schlüsselmaterial auf einem von Ihnen verwalteten Speicher. Prüfen Sie, ob sich die Sicherung öffnen lässt und das Projekt erneut abrufen lässt – nicht nur, ob der Kopierbefehl erfolgreich beendet wurde.
Entfernen Sie nicht mehr benötigte Runner-Registrierungen und widerrufen Sie Deployment-Tokens sowie Repository-Zugriffsrechte. Das Löschen der Festplatte beseitigt lokale Datenreste, ersetzt aber nicht den Widerruf von Zugangsdaten in externen Systemen.
Nach Mietende werden die Festplatten gelöscht und das System neu installiert, bevor der Rechner an den nächsten Kunden übergeben wird. Betrachten Sie das Mietgerät nach Ablauf nicht als wiederherstellbare Sicherung Ihrer Projektdateien.
Erstens: Code und große Dateien. Prüfen Sie, ob Git-Commits und Git-LFS-Objekte synchronisiert sind. Zweitens: Arbeitsergebnisse wie Archive, Testberichte, Protokolle und noch nicht hochgeladene Builds. Drittens: wiederherstellbare Umgebungen wie Lockfiles, Tool-Versionen und CI-Konfigurationen. Wiederherstellbare Caches müssen Sie nicht vollständig aufbewahren; nicht rekonstruierbare Daten sollten Sie zuerst exportieren.
Wir lesen keine Dateien oder Projektdaten auf den Knoten unserer Kunden aus. Konten, Bestellungen und Zahlungskennungen sind Service-Verwaltungsdaten und werden anders behandelt als Projektdateien auf dem Knoten. Informationen zu Erhebungszwecken und Ihren Rechten finden Sie in unseren Datenschutzhinweisen.
Standardmäßig erfolgt die Anmeldung ausschließlich per SSH-Schlüssel. Verbindungsdaten und auftragsbezogene Vorgänge finden Sie nach der Anmeldung im Kundenportal; Zugangsdaten können Sie bei Bedarf zurücksetzen.
Erstellen Sie den Schlüssel auf Ihrem eigenen Client und bewahren Sie den privaten Schlüssel dort auf. Übermitteln Sie nur den öffentlichen Schlüssel. Prüfen Sie beim ersten Verbindungsaufbau die Knoteninformationen und den Host-Key-Fingerabdruck. Ändert sich der Fingerabdruck, klären Sie zuerst, ob das System neu installiert wurde – ignorieren Sie die Warnung nicht einfach.
Schützen Sie lokale Schlüssel am besten mit einer Passphrase. Speichern Sie private Schlüssel weder in Repositories noch in Build-Protokollen oder Support-Tickets und geben Sie nicht denselben privaten Schlüssel an mehrere Teammitglieder weiter.
Scheidet ein Mitglied aus dem Projekt aus, entfernen Sie dessen öffentlichen Schlüssel und nicht mehr benötigte Kontoberechtigungen. Nutzen Sie für CI ein separates Dienstkonto und eigene Tokens; verwalten Sie Repository-Zugriff, Builds und Deployments getrennt.
Öffnen Sie nur tatsächlich benötigte Ports. Prüfen Sie nach dem Zurücksetzen von Zugangsdaten, ob alte Clients, Automatisierungsskripte und Runner noch die bisherige Konfiguration verwenden. So überdecken wiederholte Verbindungsfehler nicht die eigentliche Störung.
Im Support-Ticket können Sie den Fingerabdruck des öffentlichen Schlüssels, die Client-Version, den Fehlertext und bereinigte Konfigurationsausschnitte angeben. Senden Sie niemals Passwörter, private SSH-Schlüssel, vollständige Zugriffstokens oder Umgebungsvariablen mit geheimen Werten. Wenn für die Fehlersuche vorübergehend Zugriff nötig ist, vereinbaren Sie Umfang und Widerruf vorher im Ticket.
Alle Bestellungen werden in US-Dollar (USD) abgerechnet. Es stehen ausschließlich die folgenden zwei Zahlungsmethoden zur Verfügung. Welche Zahlungsoptionen tatsächlich verfügbar sind, richtet sich nach der Rückmeldung des Zahlungs-Gateways.
Kartenzahlungen werden über Stripe abgewickelt; Kartennummern speichern wir nicht. Für den Abgleich einer Bestellung verwenden wir die zugehörige Transaktionskennung und den Zahlungsstatus. Senden Sie niemals vollständige Kartennummern oder Kartenprüfnummern per E-Mail oder Support-Ticket.
Bei einer fehlgeschlagenen Abbuchung oder einem abweichenden Status genügen Bestellnummer, Zeitpunkt, Betrag und Fehlermeldung der Seite. Schwärzen Sie persönliche Daten auf Screenshots und lösen Sie nicht wiederholt Zahlungen aus, um den Status zu testen.
Wir gleichen Zahlungen anhand der Blockchain-Daten ab. Prüfen Sie vor der Zahlung, ob Netzwerk, Empfängeradresse und Bestellbetrag mit der Checkout-Seite übereinstimmen. Für die Prüfung genügt der Transaktions-Hash; geben Sie niemals Ihren privaten Wallet-Schlüssel oder Ihre Seed-Phrase weiter.
Wurde der Bestellstatus nach einer Überweisung noch nicht aktualisiert, halten Sie zunächst Transaktions-Hash und Bestellnummer bereit und erstellen Sie dann ein Support-Ticket. Wir garantieren keine feste Dauer bis zum Zahlungseingang; ein Screenshot ersetzt keinen Transaktionsnachweis.
Dateien auf dem Knoten, Kontodaten und Zahlungskennungen sind unterschiedliche Datenkategorien. Fügen Sie bei einer Zahlungsanfrage nur bestellungsbezogene Angaben bei – keine Projektarchive oder Signaturdateien.
Sicherheitsmeldungen bitte an support@xcodenode.com senden. Bei einem Knotenproblem zu einer bestehenden Bestellung können Sie auch im Kundenportal ein Support-Ticket erstellen.
Beschreiben Sie, welche Seite, Bestellung oder welcher Knoten betroffen ist und was Sie beobachtet haben. Stellen Sie Vermutungen ohne Belege nicht als bestätigten Datenabfluss dar.
Dokumentieren Sie Eingaben, erwartetes Ergebnis und tatsächliches Ergebnis in der Reihenfolge der durchgeführten Schritte. Prüfen Sie nur Bereiche, auf die Sie zugreifen dürfen, und lesen Sie keine Daten anderer Kunden aus.
Geben Sie Zeitpunkt und Zeitzone an und fügen Sie bereinigte Fehlermeldungen oder Screenshots bei. Entfernen Sie Tokens, Passwörter, private Schlüssel und personenbezogene Daten; lassen Sie den für den Vorfall relevanten Kontext stehen.
Ergänzen Sie Angaben per E-Mail oder Support-Ticket und verfolgen Sie den Vorgang im selben Verlauf. Störungen, die die Nutzung beeinträchtigen – etwa ein nicht erreichbarer Knoten – prüfen wir vorrangig. Über den Fortschritt informieren wir Sie per Antwort.
Fügen Sie Ihrer Meldung keine Geheimnisse bei, mit denen sich direkt auf den Knoten zugreifen lässt. Wenn Sie einen offengelegten Zugang vermuten, widerrufen Sie zuerst die betroffenen Tokens, entfernen Sie unbekannte öffentliche Schlüssel oder setzen Sie die Zugangsdaten zurück. Sichern Sie danach die erforderlichen Nachweise und melden Sie den Vorfall.
Wählen Sie einen exklusiven physischen Knoten und planen Sie Schlüssel, Backups und Teamrechte gleich mit ein. Konfigurationen, Laufzeiten und Zusatzoptionen sind auf der Tarifseite transparent aufgeführt.