Build-Ressourcen fürs Team planen

Den passenden Mac-Server für Ihre Pipeline finden

Zwei Modelle für alles – von der täglichen CI für eine App bis zu Unity-Builds.

Klären Sie zuerst, ob Ihre Aufgaben täglich anfallen oder sich auf die Release-Phase konzentrieren. Berücksichtigen Sie anschließend Arbeitsspeicher, Cache und Parallelität. VMFly stellt dedizierte physische Apple-Silicon-Mac-mini-Server bereit, keine virtuellen Maschinen. Jeder Server ist einem Kunden vorbehalten – ohne Konkurrenz durch andere Mieter um Build-Ressourcen auf demselben Host.

Dedizierten Build-Server mieten Zwei Mietmodelle vergleichen

Mietpreis ab $20.1/Tag
Chip-Auswahl Apple Silicon M4 / M4 Pro
Abrechnungszeiträume Tag / Woche / Monat / Quartal

Tägliche Builds · Langzeitserver

Die gemeinsame Warteschlange durch einen eigenen Runner ersetzen

Für eine Pipeline mit täglichen Builds für eine einzelne App ist der monatlich buchbare Glide M4 ein guter Einstieg: Apple Silicon M4, 16 GB Arbeitsspeicher, 256 GB SSD und $100.7/Monat. Leiten Sie die macOS-Aufgaben von GitHub Actions an Ihren eigenen Runner weiter, statt darauf zu warten, dass Aufgaben anderer Mieter auf einem gemeinsam genutzten Host abgeschlossen werden.

Zuerst einen reproduzierbaren Workflow migrieren

Wählen Sie eine Build-Kette mit stabilen Ergebnissen und halten Sie Commit, Xcode-Version, Dependency-Lockfile und Signaturverfahren fest. Führen Sie zuerst einen sauberen Build aus und aktivieren Sie danach den Cache – andernfalls können alte Cache-Daten Unterschiede in der Umgebung verdecken.

Installieren und registrieren Sie den self-hosted Runner Ihres Teams auf dem Server.
Weisen Sie dem Runner ein projektspezifisches Label zu, zum Beispiel vmfly-iosund beschränken Sie, auf welche Repositories er zugreifen darf.
Führen Sie für denselben Commit den bisherigen Workflow und den neuen Server aus. Vergleichen Sie Testergebnisse, Archivierungskonfiguration und Artefakte.

Geeignet für Prüfungen fester Branches, nächtliche Builds und täglich wiederkehrende Regressionstests.

Exklusive Ressourcen bedeuten nicht unbegrenzte Parallelität

Ein exklusiver Server verhindert Ressourcenkonflikte mit anderen Mietern. Die Aufgaben Ihres Teams müssen Sie trotzdem in eine Warteschlange einordnen. Starten Sie nicht gleich am ersten Migrationstag alle Jobs gleichzeitig auf einem Rechner.

Beginnen Sie mit einem Runner-Job und beobachten Sie den maximalen Arbeitsspeicherverbrauch, den freien Speicherplatz und das Cache-Wachstum.
Verwenden Sie separate Labels für Archivierungsaufgaben und UI-Tests, damit nicht gleichzeitig in dasselbe Arbeitsverzeichnis geschrieben wird.
Prüfen Sie mit Ihrem realen Projekt, ob 16 GB Arbeitsspeicher ausreichen, bevor Sie weitere Server hinzufügen oder ein anderes Modell wählen.

Glide M4 mieten

Zur Abnahme gehört mehr als ein grüner Status: Prüfen Sie auch, ob Ihr Team die Artefakte herunterladen kann, Logs erhalten bleiben und der Runner nach einem Neustart wieder läuft. Die Monatsmiete eignet sich für die kontinuierliche Nutzung – aber nicht jedes Projekt muss dafür einen ganzen Monat laufen.

Zusätzliche Kapazität für Releases · tageweise

Archivierung und UI-Tests auf getrennten Servern ausführen

In Release-Wochen konzentriert sich der Engpass oft auf wenige Arbeitstage. Buchen Sie für diese Zeit einen zusätzlichen Cruise M4 Pro für $61.5/Tag mit Apple Silicon M4 Pro, 64 GB Arbeitsspeicher und 2 TB SSD – etwa für UI-Tests oder Archivierung. Der bestehende Server übernimmt weiterhin die täglichen Prüfungen, ohne dass Sie für kurzfristige Spitzen dauerhaft Hardware anschaffen müssen.

Aufgaben vor der Erweiterung klar aufteilen

Ein Server für die Archivierung, ein anderer für die Tests – so sind die Ressourcen klar verteilt. Einfach mehr Runner hinzuzufügen, während alle Aufgaben weiterhin auf dieselbe serielle Phase warten, verkürzt die Release-Pipeline nicht automatisch.

Verwenden Sie denselben Commit und erstellen Sie getrennte Aufgaben für Archivierung und Tests.
Legen Sie Artefaktnamen und Upload-Ziele fest, damit sich unterschiedliche Branches nicht gegenseitig überschreiben.
Dokumentieren Sie die Schritte zur Einrichtung der Umgebung, damit sich auch temporäre Server anhand einer Konfigurationsdatei wiederherstellen lassen.

Testen Sie zuerst den kritischen Pfad und erhöhen Sie dann die Parallelität. Ungetestete Build-Beschleunigungen werden nicht zugesichert.

Vor Release-Abschluss die Übergabe erledigen

Legen Sie die Endbedingungen für temporäre Server in der Release-Checkliste fest: letzte Prüfung abgeschlossen, Artefakte zurückübertragen und Diagnose-Logs gespeichert – erst dann endet die Mietzeit. Wenn Sie den Runner nicht mehr verwenden, wird dadurch die Abrechnung nicht automatisch beendet. Prüfen Sie im Control Panel den Abonnementstatus und das Ablaufdatum.

Exportieren Sie die aufzubewahrenden Archive, Testberichte und Fehler-Logs.
Entfernen Sie die Registrierung des temporären Runners bei Ihrer Code-Hosting-Plattform.
Widerrufen Sie temporäre Tokens und sichern Sie Ihre Daten vor Ablauf der Mietzeit.

Cruise M4 Pro mieten

Unity für iOS · Export und Archivierung

Den Export des Projekts bis zur IPA-Datei durchgängig abbilden

Der Xcode-Projektexport aus Unity, die Installation von Abhängigkeiten, die Signierung und die IPA-Archivierung sollten in einer nachvollziehbaren Umgebung ablaufen. Die 64 GB Arbeitsspeicher und 2 TB SSD des Cruise M4 Pro bieten Platz für große Projekte, den Import von Ressourcen und Build-Caches. Die tatsächlich benötigte Kapazität und Parallelität müssen Sie für jedes Projekt prüfen.

01
Exportumgebung festlegen

Halten Sie Unity-Editor-Version, Projektabhängigkeiten und iOS-Exporteinstellungen fest. Erzeugen Sie das Xcode-Projekt mit einem festen Commit, damit sich die Editor-Version lokal und auf dem Server nicht unterscheidet.
02
Signierung und Archivierung prüfen

Prüfen Sie Ziel, Build-Konfiguration, Provisioning Profile und Exportverfahren. Stellen Sie Signaturmaterialien über den vom Team freigegebenen Zugangsdatenprozess bereit – nicht im Code-Repository oder in öffentlichen Logs.
03
Cache und Auslieferungsartefakte trennen

Caches lassen sich neu erstellen, Release-Artefakte müssen aufbewahrt werden. Verwenden Sie für Unity-Zwischendateien, DerivedData und ältere Archive separate Verzeichnisse und Bereinigungsregeln, damit sich auf Dauer nicht die Systemplatte füllt.

Interaktive Aufgaben · erst testen, dann langfristig nutzen

Fürs Debugging braucht es einen Desktop, für Experimente eine reproduzierbare Umgebung

Die Server eignen sich nicht nur für unbeaufsichtigte Builds. Melden Sie sich im Control Panel an, öffnen Sie den macOS-Remotedesktop des Servers im Browser und debuggen Sie direkt in Xcode. Alternativ führen Sie Skripte per SSH aus und testen Inferenz-Workflows lokaler Modelle auf Apple Silicon.

Bei der Remote-Entwicklung zuerst die Interaktionslatenz prüfen

Beim häufigen Bedienen des Simulators, Prüfen der Benutzeroberfläche oder schrittweisen Debuggen fällt die Netzwerklatenz stärker ins Gewicht als bei Builds im Hintergrund. Verfügbare Standorte: Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong. Testen Sie zuerst einen Server in der Nähe Ihres Teams, bevor Sie sich für einen langfristigen Standort entscheiden.

Prüfen Sie in Ihrem Büronetzwerk die Lesbarkeit von Texten, die Reaktionszeit und die Dateiübertragung.
Planen Sie tägliche Bearbeitung und lang laufende Archivierungen zeitversetzt, um interne Ressourcenkonflikte im Team zu reduzieren.
Wenn mehrere Personen denselben Server nutzen, legen Sie zuerst Regeln für Desktop-Sitzungen und den Umgang mit Zugangsdaten fest.

Der Desktop im Browser ist für interaktive Aufgaben gedacht, SSH für Automatisierung – beides kann für dasselbe Projekt genutzt werden.

Bei KI-Experimenten zuerst den Arbeitsspeicherbedarf prüfen

Wählen Sie anhand der Modelldateien, Inferenzgenauigkeit, Kontextlänge und gleichzeitig eingesetzten Tools – nicht allein nach dem Modellnamen. Installieren Sie die Umgebung und testen Sie ein Beispiel zunächst mit einer kurzen Laufzeit. Entscheiden Sie danach zwischen Glide M4 und Cruise M4 Pro.

Prüfen Sie, ob die Abhängigkeiten Apple Silicon unterstützen, und halten Sie installierte Versionen und Startparameter fest.
Beobachten Sie den Arbeitsspeicherverbrauch im tatsächlichen Betrieb. SSD-Speicherplatz ist kein Ersatz für Arbeitsspeicher.
Speichern Sie Eingaben, Parameter und Ausgaben, damit sich das Experiment auf einem neuen Server reproduzieren lässt.

64 GB Arbeitsspeicher garantieren nicht, dass jedes Modell läuft. Kompatibilität und Kapazität müssen mit den tatsächlichen Aufgaben geprüft werden.

Pipeline-Prüfung · von der Signierung bis zur Verteilung

Jeder Build-Schritt sollte ein nachvollziehbares Ergebnis liefern

Der folgende Ausschnitt veranschaulicht einen fastlane-Workflow und ist kein Messprotokoll des Servers. Ihr Team muss selbst den Zugriff auf das Signierungs-Repository, das Projektscheme, die Bundle-ID und die Zugangsdaten für die Verteilung konfigurieren. Lassen Sie zuerst jeden Schritt einzeln erfolgreich durchlaufen und verbinden Sie sie anschließend zu einem unbeaufsichtigten Workflow.

cruise-m4pro — fastlane

$ bundle exec fastlane match appstore --readonly
[match] Fetching signing certificates and profiles
[match] Installing signing assets into the build keychain
[match] Signing assets are ready

$ bundle exec fastlane gym --scheme "$SCHEME" --export_method app-store
[gym] Archiving the selected scheme
[gym] Exporting the archive
[gym] IPA export completed

$ bundle exec fastlane pilot upload --ipa "$IPA_PATH"
[pilot] Uploading the selected IPA
[pilot] Upload completed; processing continues on TestFlight

match: Nur benötigte Zugangsdaten abrufen

CI ruft vorhandenes Signaturmaterial im Nur-Lese-Modus ab. Wenn Sie nicht auf das Signierungs-Repository zugreifen können, prüfen Sie zuerst die Berechtigungen. Geben Sie niemals private Schlüssel, Tokens oder Entschlüsselungspasswörter in Logs aus.

gym: Archivierung und Export getrennt betrachten

Eine erfolgreiche Archivierung bedeutet nicht, dass auch der IPA-Export gelungen ist. Bewahren Sie die Archivierungs-Logs auf und prüfen Sie Scheme, Signierungskonfiguration und Exportparameter getrennt, statt beide Schritte als denselben Fehler zu behandeln.

pilot: Der Upload ist nicht gleich Verarbeitung

Nach dem Upload muss die Verteilungsplattform die Datei noch verarbeiten. Speichern Sie das Upload-Ergebnis und prüfen Sie den Verarbeitungsstatus. Ein erfolgreicher Netzwerk-Upload allein bedeutet noch nicht, dass das Team die Abnahme erteilt hat.

20 Builds pro Tag · Bereitstellungsmodelle im Vergleich

Vergleichen Sie Ressourcenverteilung und Betriebsaufwand

Angenommen, ein kleines oder mittleres Team startet täglich 20 Builds. Diese Zahl veranschaulicht die Häufigkeit der Aufgaben, ist aber kein Leistungstest und reicht nicht aus, um die benötigte Anzahl an Rechnern zu bestimmen. Erfassen Sie auch die Dauer einzelner Builds, die Zahl gleichzeitiger Starts, die Cache-Trefferquote und die Spitzen in Release-Wochen. Vergleichen Sie anschließend die drei Bereitstellungsmodelle.

Bereitstellungsoptionen für dieselbe iOS-Pipeline. Prüfen Sie die tatsächlichen Funktionen und Bereitstellungsbedingungen beim jeweiligen Anbieter.
Entscheidungskriterium	VMFly-Server mieten	Mac-Hardware kaufen	Gemeinsam genutzte virtuelle Maschine
Kostenmodell	Miete pro Tag, Woche, Monat oder Quartal. Glide M4 kostet $100.7/Monat, Zusatzoptionen kommen hinzu.	Einmaliger Kaufpreis sowie Kosten für Unterbringung, Netzwerk, Strom und laufende Verwaltung.	Abrechnung nach Laufzeit oder Nutzung der Plattform. Prüfen Sie auch Warteschlangenregeln und Parallelitätslimits.
Bereitstellung	Nach bestätigter Zahlung wird ein physischer Rechner zugewiesen. Der aktuelle Verfügbarkeitsstatus ist im Control Panel einsehbar.	Beschaffung, Lieferung, Netzwerkanschluss und Einrichtung des Fernzugriffs sind erforderlich.	Die Ressourcen werden von der Plattform zugewiesen. Ob Warteschlangen anfallen und wie beständig die Umgebung ist, hängt vom jeweiligen Dienst ab.
Exklusivität	Der Mac mini ist einem Kunden vorbehalten und keine virtuelle Maschine.	Das Team nutzt die Hardware exklusiv und übernimmt die Verwaltung vor Ort und des Systems.	Host-Ressourcen werden üblicherweise mit anderen Instanzen geteilt. Die Plattform sorgt für Isolation und Ressourcenzuweisung.
Skalierbarkeit	Sie können ein anderes Modell wählen oder weitere Server hinzufügen. Die Migration von Umgebung und Daten müssen Sie selbst planen.	Eine Erweiterung erfordert in der Regel zusätzliche Hardware und Bereitstellung; bestehende Rechner bleiben im Investitionsbudget gebunden.	Verfügbare Modelle und Erweiterungsoptionen hängen vom Angebot und den Zuweisungsregeln der Plattform ab.

Modelle mit demselben Commit in der Praxis vergleichen

20 kurze Builds pro Tag profitieren möglicherweise eher von einem stabilen Cache. Bei wenigen, aber lang laufenden UI-Tests kann es wichtiger sein, die Aufgaben auf mehrere Server aufzuteilen. Wählen Sie kein Modell allein aufgrund der Build-Anzahl. Prüfen Sie mit demselben Projekt Laufzeit, Arbeitsspeicher- und Speicherplatzbedarf. Entscheiden Sie danach, ob Sie dauerhaft einen Glide M4 nutzen oder für Releases einen Cruise M4 Pro hinzufügen.

VMFly stellt den exklusiven physischen Server bereit. Ihr Team verwaltet weiterhin Projektabhängigkeiten, Runner-Berechtigungen, Signaturmaterial und Artefaktsicherungen. Wenn Sie eine vollständig verwaltete Pipeline-Orchestrierung benötigen, prüfen Sie zuerst, ob diese Aufgaben bereits von den vorhandenen Tools Ihres Teams übernommen werden.

Das passende Modell für Ihren Einsatz wählen

Bei täglichen Builds zählt die dauerhafte Auslastung, bei kurzfristigen Spitzen die Nutzungsdauer. Vergleichen Sie die beiden Modelle und vier Mietzeiträume und planen Sie dann den passenden Server für Ihre Pipeline.

Zwei Mietmodelle ansehen Dedizierten Build-Server mieten