Infrastrukturteam für Entwickler

Für kontinuierliche Builds: ein klar zugeordneter Cloud-Mac

RunnerVM bietet dedizierte physische Mac-mini-Knoten für iOS, macOS, CI/CD und KI-Experimente. Wir geben Modell, Standort, Preis, Bereitstellungsstatus und Vorgehen bei Problemen transparent an, statt gemeinsam genutzte virtuelle Ressourcen als dedizierte Geräte auszugeben.

1 verfügbare Konfiguration

5 Knoten oder Rechenzentren

365 Tage normaler Knotenbetrieb

Runner M4 jetzt mieten Konfiguration und Preise ansehen

RUNNERVM Build-Auftrag

Physischer Knoten

Code-Commit Dedizierter Mac Build-Artefakt

Verfügbares Modell: Runner M4
Hardware: M4 / 16GB / 256GB
Geräteeigenschaft: Dediziertes physisches Gerät, keine virtuelle Maschine
Verfügbare Standorte: Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, US-Ostküste

Nachvollziehbare Konfiguration Nachverfolgbare Bestellung Nachvollziehbare Problembearbeitung

Die Idee hinter der Marke

RunnerVM entstand aus einer Build-Pipeline, die immer wieder läuft

Das Erstellen mobiler Apps ist kein einmaliger Remote-Vorgang. Checkout, Wiederherstellung von Abhängigkeiten, Einbindung von Signaturmaterial, Archivierung, Export und Protokollaufbewahrung wiederholen sich laufend. Teams brauchen dafür eine wiederverwendbare Umgebung mit klarer Zuordnung.

Zuerst klären wir, wo Builds ausgeführt werden

Lokale Entwicklungsgeräte eignen sich für interaktive Arbeit, aber nicht immer für lang laufende, wiederholbare Automatisierungsaufgaben. RunnerVM stellt einen dedizierten physischen Mac mini als zeitweise mietbare Entwicklungsinfrastruktur bereit, damit Build-Skripte, Cache-Verzeichnisse, Toolchains und Artefaktpfade dauerhaft vom Team verwaltet werden können.

Im Mittelpunkt steht nicht, den Desktop in den Browser zu verlagern, sondern einen Cloud-Mac bereitzustellen, der per grafischer Oberfläche oder Kommandozeile genutzt werden kann. Entwickler können je nach Projekt Xcode, xcodebuild, fastlane, Testwerkzeuge und gängige Abhängigkeitsverwaltung ausführen.

Wiederkehrende Aufgaben erkennen

Häufige Signatur-, Archivierungs-, Export- und Protokollsammelaufgaben vom persönlichen Gerät auslagern.

Laufzeitumgebung festlegen

Mit einem dedizierten physischen Knoten bleiben Toolchain, Cache und Build-Verzeichnisse verwaltbar.

Nachvollziehbaren Pfad schaffen

Konfiguration, Bestellung, Knoten, Ticket und Betriebsprotokoll entlang derselben Kette verfolgen können.

Leistungsumfang

Welche Aufgaben zu RunnerVM passen und welche Entscheidungen beim Team bleiben

Klare Grenzen sind wichtiger, als jedes Problem als „Cloud-Service-Funktion“ zu behandeln. Wir stellen Laufzeitumgebung und Knotenverwaltung bereit; Projektarchitektur, Signaturstrategie, Abhängigkeitsversionen und Veröffentlichungsentscheidungen bleiben beim nutzenden Team.

Für kontinuierliche Builds und Remote-Entwicklung geeignet

Geeignet für iOS- und macOS-Kompilierung, CI/CD-Runner, React-Native-iOS-Builds, automatisierte Xcode-Archivierung, Kommandozeilenaufgaben, die Vorbereitung von Remote-Debugging sowie KI-Experimente mit konkretem Bedarf an einer Apple-Silicon-Umgebung.

Sie benötigen eine dedizierte Rechenumgebung und stabile Verzeichnisstrukturen
Sie möchten Geräte tage-, wochen-, monats- oder quartalsweise nutzen
Sie möchten aus fünf verfügbaren Standorten einen Zugriffsstandort wählen

Gemeinsam genutzte Ressourcen nicht als dedizierte Geräte darstellen

RunnerVM bietet dedizierte physische Mac-mini-Geräte, die als keine virtuelle Maschine bereitgestellt werden. Die Seite ersetzt echte Modelle nicht durch vage Angaben wie „Hochleistungsinstanz“ und nennt keine Speicher-, Massenspeicher- oder Chipkombinationen außerhalb des Katalogs.

Wir entscheiden nicht anstelle des Teams über Projektabhängigkeiten und Veröffentlichungsabläufe
Wir versprechen keine nicht am Projekt validierte Build-Dauer
Gemeinsam genutzte virtuelle Ressourcen werden nicht als dedizierte physische Knoten ausgegeben

Betriebsgrundsätze

Produktfakten sind einheitlich, die Darstellung darf sich unterscheiden

Mehrsprachige Seiten, Angebotsbeschreibungen, Bestellkonfigurationen und Supportantworten von RunnerVM beziehen sich auf dieselben Produktfakten. Beim Sprachwechsel dürfen sich Konfiguration, Preise, Standorte und Zahlungsoptionen nicht ändern.

Konfigurationen wahrheitsgemäß angeben

Für jedes verfügbare Gerät werden Chip, Arbeitsspeicher, Speicher und physische Eigenschaften genannt. Der aktuelle Runner M4 entspricht M4, 16GB und 256GB. Nicht verfügbare Modelle werden nicht ergänzt und zusätzlicher Speicher nicht als Basiskonfiguration dargestellt.

Einheitliche Preise

Die Preise für Tag, Woche, Monat und Quartal bleiben auf Angebots-, Bestell- und Informationsseiten identisch. Alle Bestellungen werden in US-Dollar abgerechnet; Zusatzoptionen werden separat ausgewiesen, ohne vollständige Laufzeitkosten durch unklare Einstiegspreise zu verschleiern.

Knoten überprüfbar machen

Der Katalog führt fünf verfügbare Standorte eindeutig auf. Bei der Standortwahl werden nur vom aktuellen Modell unterstützte Kombinationen angezeigt; bei Netzwerkprüfungen werden Quellknoten, Zielknoten, Zeitpunkt und vollständige Ausgabe protokolliert.

Probleme nachverfolgbar machen

Technische Probleme werden auf Grundlage von Bestellung, Knoten, Zeitpunkt, Reproduktionsschritten und bereinigten Protokollen in einem Ticket bearbeitet. Status, Zusatzinformationen und Ergebnis werden im selben Ticket aktualisiert, damit Informationen nicht verstreut sind.

Konfigurationskatalog 1 Angebot

Standortkatalog 5 Knoten

Abrechnungszeitraum Tag / Woche / Monat / Quartal

Zahlungsoptionen USDT-TRC20 oder Karte

Kartenzahlungen erfolgen ausschließlich mit Visa, Mastercard oder Amex über Stripe; welche Zahlungs-Gateways tatsächlich verfügbar sind, liefert die Backend-Schnittstelle zurück. Alle Bestellungen werden einheitlich in US-Dollar (USD) abgerechnet.

Knotenstandorte

Fünf Knoten für die wichtigsten asiatischen Zugriffsrichtungen und die US-Ostküste

Bei der Standortwahl zählt nicht nur die Entfernung auf der Karte. Teams sollten auch Mitgliederstandorte, Code- und Abhängigkeitsquellen, Remote-Zugriffswege, Upload-Richtung der Artefakte und Unternehmensnetzwerk-Ausgänge testen, bevor sie den Bestellstandort festlegen.

Singapur

Geeignet für Entwicklungsteams mit Ausrichtung auf Südostasien und als asiatischer Zugriffspunkt für die regionale Zusammenarbeit. Vor der Bestellung werden Latenz und Routing aus dem tatsächlichen Büronetz empfohlen.

Japan (Tokio)

Geeignet für Teams in Japan und für Standorte mit günstiger Netzwerkanbindung an Tokio. Bei häufigen Remote-Desktop-Sitzungen sollten p50-, p95- und Spitzenzeitwerte gemeinsam beobachtet werden.

Südkorea (Seoul)

Bietet einen Standort für Entwicklungs- und Build-Aufgaben mit Ausrichtung auf Südkorea. Bei großen Abhängigkeiten oder Artefakten müssen Downloadquellen und Uploadziele gemeinsam getestet werden.

Hongkong

Geeignet für Teams, die einen grenzüberschreitenden asiatischen Zugriffsweg benötigen. Das tatsächliche Routing kann je nach Anbieter abweichen; der Standortname ersetzt daher keine Messung im Projektnetzwerk.

US-E

US-Ostküste

Geeignet für Aufgaben, deren Teammitglieder, Codeservices oder Bereitstellungskette hauptsächlich an der US-Ostküste liegen. Für interkontinentale Remote-Abläufe sollten bevorzugt Automatisierungen eingesetzt und vollständige Protokolle aufbewahrt werden.

Zuerst die Remote-Interaktion, dann die Build-Kette testen

Prüfen Sie aus dem tatsächlichen Netzwerk zunächst ping, traceroute, DNS und den Zielport und führen Sie anschließend eine realitätsnahe Abhängigkeitsübertragung sowie einen Artefakt-Upload durch. Öffentliche Latenzdaten dienen dem Vergleich und ersetzen keine eigenen Netzwerktests.

Leitfaden zur Netzwerkprüfung ansehen

Verantwortung für Gerät und Daten

Von der Prüfung vor der Bereitstellung bis zum Bestellende ist jeder Verantwortungsbereich klar definiert

Ein dediziertes Gerät macht Zugriffskontrolle nicht überflüssig. RunnerVM verantwortet Knotenbereitstellung, serverseitige Anmeldeinformationen und die Verarbeitung nach Bestellende; der Nutzer verantwortet die ersten Sicherheitseinstellungen, Projektberechtigungen, Build-Materialien und Backups geschäftlicher Daten.

01

Gerät vor der Bereitstellung prüfen

Prüfen Sie verfügbares Modell, Arbeitsspeicher, Basisspeicher, Netzwerkverbindung und Erreichbarkeit des Geräts und verknüpfen Sie die Bestellung mit dem gewählten Standort. Maßgeblich sind die Bestellinformationen und die Rückgabe der Konsole.
Verantwortung von RunnerVM: Übereinstimmung von Konfiguration und Knoten
02

Sicherheitseinstellungen nach der ersten Verbindung aktualisieren

Nach Erhalt der Zugangsdaten sollte der Nutzer den Host-Fingerabdruck prüfen, das erste Passwort ändern, unnötige Zugriffsquellen beschränken und kontrollieren, ob Remote-Desktop- und Kommandozeilenverbindungen den Teamrichtlinien entsprechen.
Verantwortung des Nutzers: Zugangsdaten verwahren und Berechtigungen vergeben
03

Projektdaten während der Mietdauer kontrollieren

Zertifikate, Provisioning-Profile, Quellcode, Caches, Protokolle und Build-Artefakte sollten in projektbezogenen Verzeichnissen verwaltet werden. Bei der Freigabe für Teammitglieder gilt das Prinzip der geringsten Berechtigung; wichtige Artefakte sollten separat gesichert werden.
Gemeinsames Ziel: Berechtigungsstreuung und Datenvermischung reduzieren
04

Zugriff nach Bestellende widerrufen

Der Service widerruft die mit der Bestellung verknüpften Zugangsdaten und leitet die Geräteverarbeitung ein. Der Nutzer sollte benötigte Artefakte vorher exportieren, Projektschlüssel entfernen und bestätigen, dass Automatisierungsaufgaben keine Daten mehr an den Knoten senden.
Abschlussbedingungen: Zugriff widerrufen, Aufgaben gestoppt, Daten verarbeitet

Inhalte, die der Nutzer selbst sichern muss

Build-Artefakte außerhalb des Quellcode-Repositorys, Exportdateien, Projektprotokolle, eigene Skripte, nur im Cache vorhandene Dateien sowie Konfigurationsaufzeichnungen, die das Team später noch benötigt.

Supportinformationen vor dem Übermitteln bereinigen

Protokolle sollten Zeitpunkt, Befehl, Fehlercode und Kontext enthalten, aber Passwörter, Tokens, private Schlüssel, Zertifikatspasswörter und andere direkt zugriffsbegründende Inhalte entfernen.

Öffentlicher Status und Verbesserungen

Statusprotokolle beantworten, was passiert ist; Auswertungen zeigen, was als Nächstes verbessert wird

Das Verfügbarkeitsziel von RunnerVM beträgt 99,9 %. Die Knoten laufen 365 Tage im Jahr normal; unerwartete Geräte-, externe Netzwerk- oder Nutzerkonfigurationsprobleme werden nach ihrem tatsächlichen Auswirkungsbereich dokumentiert und bearbeitet.

Verfügbarkeitsziel 99,9%

Die Feststellung, Prüfung und der Umfang der Bearbeitung tatsächlicher Ereignisse richten sich nach den anwendbaren Servicebedingungen.

Vor 90 Tagen 3 Tage pro Feld Neuester Eintrag

Die Statusleiste zeigt den Zeitraum der Aufzeichnungen der letzten 90 Tage. Die tatsächliche Verfügbarkeit eines Knotens bei der Bestellung wird in Echtzeit von der Konsole zurückgegeben.

Protokoll

Ereignisinformationen sind lokalisierbar

Erfasst werden Beginn und Ende, betroffene Knoten, für Nutzer sichtbare Symptome, Bestätigungsmethode und Wiederherstellungsergebnis, statt nur eine unbegrenzte Statusaussage zu veröffentlichen.

Bearbeitung

Zuerst wiederherstellen, dann den Umfang prüfen

Zunächst werden Geräte- oder Verbindungsfunktionen wiederhergestellt. Anschließend wird der Auswirkungsbereich anhand von Bestellung, Knoten, Zeitpunkt und Protokollen geprüft und der Bearbeitungsstatus im Ticket aktualisiert.

Auswertung

Verbesserungen müssen umsetzbar sein

Die Zusammenfassung unterscheidet Geräte-, Netzwerk-, Bereitstellungs- und Prozessprobleme und nennt konkrete Prüfpunkte, Verantwortliche und Validierungsmethoden, statt nicht überprüfbare absolute Zusagen zu machen.

Tägliche Aufzeichnung Knotenverbindung und Service-Status

Ereignisprotokoll Zeit, Umfang, Symptome und Wiederherstellungsergebnis

Zusammenfassung der Auswertung Ursachenkategorien, Verbesserungen und Validierungspfad

Unterscheiden sich Konfiguration und Preise je nach Seitensprache?

Nein. Die Seitensprache ändert nur die Formulierung, nicht verfügbare Modelle, Laufzeitpreise, Zusatzoptionen, Standortkatalog oder Zahlungsoptionen. Bei Abweichungen können Sie die konkrete Seite und einen Screenshot über support@runnervm.com oder ein Konsolenticket einreichen.

Legt RunnerVM einen Knoten für das Team fest?

Nein, wir entscheiden nicht direkt für das Projekt. Wir veröffentlichen die fünf Standorte Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und US-Ostküste und stellen Methoden zur Netzwerkprüfung bereit. Das Team sollte anhand seines Büronetzwerks, der Abhängigkeitsquellen und des Bereitstellungsziels testen und auswählen.

Wie kann ich bei Build- oder Verbindungsproblemen schneller mit der Prüfung beginnen?

Notieren Sie zunächst Bestellkennung, Knotenstandort, Zeitpunkt, Reproduktionsschritte und die vollständige Fehlerausgabe und prüfen Sie anschließend den Supportleitfaden. Wenn das Problem bestehen bleibt, melden Sie sich in der Konsole an und erstellen Sie ein Ticket. Zugangsdaten und sensible Materialien müssen vor dem Übermitteln aus den Protokollen entfernt werden.

Nächster Build

Übergeben Sie wiederholbare Build-Aufgaben an einen dedizierten Cloud-Mac

Prüfen Sie zunächst Konfiguration, Laufzeit und die fünf verfügbaren Standorte des Runner M4 und starten Sie anschließend die Bestellung. Für Projektanforderungen erreichen Sie das Team über die Support-E-Mail oder ein Konsolenticket.

Cloud-Mac jetzt mieten Supportteam kontaktieren