Preise für macOS-CI-Macs mit M4

Eine Pipeline, ein kompletter Mac

RAM für Builds statt für Nachbarn

Beide Konfigurationen bieten einen dedizierten Apple Silicon M4 Mac mini – keinen virtuellen Mac. Sie unterscheiden sich bei RAM und lokalem SSD-Speicher; die Maschine wird nicht zwischen Kunden aufgeteilt. Wie viele Aufgaben parallel laufen oder in der Warteschlange stehen, hängt weiterhin von der Runner-Konfiguration deines Teams ab.

Angezeigt wird der Tagespreis in USD; die Preise für alle Laufzeiten stehen ebenfalls in der jeweiligen Karte.

Merge M4 S

Der Einstieg für CI mit einem Projekt

$20/Tag

Chip: Apple Silicon M4
Arbeitsspeicher: 16 GB RAM
Speicher: 256 GB SSD

Geeignet für Builds eines einzelnen Projekts, Unit-Tests und kleinere SwiftUI-Apps. Führe zunächst einen Build mit deinem echten Repository aus und prüfe Spitzenauslastung, Cache-Größe und Archivdateien. Danach kannst du entscheiden, ob du mehr Speicher brauchst.

Tag: $20/Tag
Woche: $54.1/Woche
Monat: $100.1/Monat
Quartal: $272.3/Quartal

Dedizierter physischer Mac · keine VM Sofort verfügbar

Merge M4 S mieten

Merge M4 L

Mehr Spielraum für mehrere Targets und Grafikentwicklung

$39.5/Tag

Chip: Apple Silicon M4
Arbeitsspeicher: 24 GB RAM
Speicher: 512 GB SSD

Ideal für die tägliche Xcode-Nutzung aus der Ferne, Projekte mit mehreren Targets und parallele UI-Tests. Mehr RAM und SSD-Speicher bieten Platz für Simulatoren, Abhängigkeiten und Build-Caches. Wie viele Aufgaben parallel laufen, solltest du anhand deines Projekts testen.

Tag: $39.5/Tag
Woche: $106.7/Woche
Monat: $197.6/Monat
Quartal: $537.5/Quartal

Dedizierter physischer Mac · keine VM Sofort verfügbar

Merge M4 L mieten

Beide Konfigurationen sind an allen 5 Standorten im Katalog verfügbar. Den aktuellen Status zeigt das Control Panel. Die Laufzeitpreise gelten für die jeweilige Mietdauer – abgerechnet wird nicht nach Build-Minuten.

Basis-Konfigurationen und Preise für die gesamte Mietdauer im Vergleich, alle Beträge in USD
Modell	Chip / RAM / SSD	Tag	Woche	Monat	Quartal
Merge M4 S	Apple Silicon M4 16 GB RAM / 256 GB SSD	$20	$54.1	$100.1	$272.3
Merge M4 L	Apple Silicon M4 24 GB RAM / 512 GB SSD	$39.5	$106.7	$197.6	$537.5

Nach Projektprofil auswählen

Erst den RAM-Spitzenbedarf prüfen, dann den Cache

Die Anzahl der Projekte ist nicht das einzige Kriterium. Parallel laufende Simulatoren, das Auflösen von Abhängigkeiten, Archivierung und das Laden von Modellen können gleichzeitig Ressourcen beanspruchen. Mehr SSD-Speicher schafft Platz für Dateien, erhöht aber nicht den RAM und beschleunigt nicht automatisch jede Aufgabe.

Wähle passend zur Arbeitsweise deines Teams. Die Empfehlungen dienen zur ersten Orientierung und garantieren weder eine bestimmte Build-Dauer noch eine feste Parallelität.
Aufgabentyp	Einstiegskonfiguration	Warum diese Konfiguration?	Nach dem Start prüfen
Leichte Builds	Merge M4 S 16 GB RAM / 256 GB SSD	Richte für CI mit einem Projekt oder kleinere SwiftUI-Apps zunächst eine eigene Build-Umgebung ein. So musst du keine Ressourcen vorhalten, die du noch gar nicht brauchst.	Erfasse die Ressourcennutzung bei einem sauberen Build und einem Build mit Cache. Prüfe nach der Archivierung, wie viel Speicher übrig ist.
Tägliche Entwicklung	Merge M4 L 24 GB RAM / 512 GB SSD	Projekte mit mehreren Targets, parallele UI-Tests und Xcode aus der Ferne beanspruchen oft gleichzeitig RAM. Diese Konfiguration bietet mehr Reserven für Toolchain und Simulatoren.	Führe die tatsächlich benötigten Tests parallel aus, beobachte die RAM-Auslastung und lege danach die maximale Zahl paralleler Runner-Aufgaben fest.
Inference mit großen Modellen	Merge M4 L Mit zusätzlicher 2-TB-SSD	Für lokale Inference mit MLX kannst du Apple Silicon nutzen. Größere Modelldateien benötigen zusätzlichen Speicherplatz; ob ein Modell geladen werden kann, hängt aber weiterhin vom RAM-Bedarf ab.	Prüfe zuerst Modellpräzision, Kontextlänge und benötigten Arbeitsspeicher. Plane danach den Speicherort für Gewichte und Datensätze.

Teste dein Repository zunächst tageweise: Verwende dieselbe Xcode-Version, gesperrte Abhängigkeiten und denselben Testsatz und vergleiche anschließend die Build-Logs. Build-Zeiten unterschiedlicher Projekte lassen sich nicht direkt als Leistungsmaßstab für die Hardware heranziehen.

Speicher nach Bedarf erweitern

Platz für Projekte, Caches und Modelle

Die folgenden Preise gelten für Extras zusätzlich zur Basiskonfiguration und richten sich nach der jeweiligen Laufzeit. Prüfe zuerst, wie viel Speicherplatz du brauchst und ob eine Verbindung zwischen mehreren Macs erforderlich ist. Kontrolliere dann die Kombination und den Gesamtbetrag auf der Bestellseite.

+1 TB SSD

Mehr Platz für Abhängigkeits-Caches und Build-Archive

Geeignet, wenn das Projekt selbst klein ist, DerivedData, Build-Caches und ältere Build-Artefakte aber stetig wachsen. Plane Bereinigung und Backups ein – zusätzlicher Speicher ist kein Backup.

Tag: $2.8/Tag
Woche: $7.5/Woche
Monat: $13.9/Monat
Quartal: $37.8/Quartal

Erweitert den Speicher, nicht den RAM der Basiskonfiguration.

+2 TB SSD

Mehr Platz für Modelldateien und große Datensätze

Geeignet zum Speichern von MLX-Modellgewichten, mehreren Simulator-Runtimes oder umfangreichen Ressourcen. Berücksichtige bei der Speicherplanung auch Downloads, entpackte Kopien und generierte Dateien – nicht nur die Größe des Repositorys.

Tag: $5.6/Tag
Woche: $15/Woche
Monat: $27.8/Monat
Quartal: $75.6/Quartal

Der Umfang der Modellinferenz ist weiterhin durch RAM und Aufgabenkonfiguration begrenzt.

Thunderbolt 5: Verbindung mehrerer Macs

Zusatzoption für mehrere Macs, Preis pro Gerät

Für Workflows mit tatsächlichem Verbindungsbedarf zwischen mehreren Macs. Dadurch wird der Arbeitsspeicher mehrerer Macs nicht zusammengelegt, und Xcode verteilt Builds nicht automatisch. Prüfe zuerst, ob deine Anwendung die Verbindung nutzen kann.

Tag / pro Gerät: $1.5/Tag
Woche / pro Gerät: $3.9/Woche
Monat / pro Gerät: $7.3/Monat
Quartal / pro Gerät: $19.9/Quartal

Die Bestellseite zeigt die konkreten Verbindungskonfigurationen und verfügbaren Kombinationen.

Bestätige Speichererweiterungen und Verbindungsoptionen zusammen mit deiner Bestellung. Wenn du eine bestehende Instanz ändern möchtest, reiche zuerst ein Support-Ticket ein. Beschreibe den Verwendungszweck, den Bedarf für die Datenmigration und den gewünschten Zeitpunkt für die Umstellung.

5 Standorte, dieselben Mac-Konfigurationen

Interaktive Latenz und Übertragungswege getrennt betrachten

Bei der Fernsteuerung per VNC ist vor allem die Round-Trip-Latenz entscheidend. Automatische Builds hängen zusätzlich davon ab, über welche Netzwerkwege Code, Abhängigkeiten und Build-Artefakte übertragen werden. Die folgenden Richtwerte beziehen sich auf die jeweilige Versorgungsregion. Sie wurden weder von deinem Standort aus noch für jede einzelne Stadt gemessen.

Standort → Region → Round-Trip-Richtwert → Einsatzbereich
Standort	Region	Round-Trip-Richtwert	Geeigneter Einsatz
Singapur	Südostasien	20–50 ms	Remote-Desktop und Builds für Teams in Südostasien. Berücksichtige bei Dateiübertragungen auch den Speicherort von Repository und Build-Artefakten.
Japan (Tokio)	Ostasien	30–60 ms	Xcode-Interaktion und automatische Builds für Teams in Ostasien. Nutze bei häufigen Ressourcentransfers möglichst vorhandene lokale Caches.
Südkorea (Seoul)	Nordostasien	30–50 ms	Remote-Desktop und Tests für Teams in Nordostasien. Prüfe Durchsatz und Stabilität separat, wenn Build-Artefakte zurückübertragen werden.
Hongkong	Südchina und Südostasien	20–40 ms	Grafikentwicklung und SSH-Builds in den jeweiligen Regionen. Synchronisiere kleine Dateien möglichst nur einmal.
US-Ostküste	Ost-Nordamerika und Westeuropa	25–35 ms	Builds und Zusammenarbeit für Teams in den jeweiligen Regionen. Beziehe bei der Standortwahl auch Paketquellen, Code und Build-Artefakte ein.

Die Werte sind Richtwerte; entscheidend ist dein tatsächlicher Netzwerkzugang. Latenz ist nicht gleich Downloadgeschwindigkeit. Teste das erstmalige Herunterladen von Abhängigkeiten, das Hochladen von Archiven und die VNC-Steuerung jeweils separat. Beide Konfigurationen sind an allen genannten Standorten verfügbar. Den aktuellen Status zeigt das Control Panel.

Ein fester Standort für Nightly Builds

Verfügbarkeitsgarantie

99,9 %

Bei einer Berechnung auf Basis von 30 Tagen entspricht das einer monatlichen Ausfallzeit von etwa 43 Minuten.

Gutschrift anhand der Dauer des Ausfalls prüfen

Alle Standorte laufen 365 Tage im Jahr. Die Verfügbarkeitsgarantie bedeutet nicht, dass jede Pipeline erfolgreich läuft: Fehler im Projekt, Probleme mit Abhängigkeiten und Bedienfehler müssen jeweils anhand der Build-Logs untersucht werden.

Über die vereinbarte Ausfallzeit hinaus wird eine Gutschrift entsprechend der Dauer der Beeinträchtigung berechnet. Höhere Gewalt und Auswirkungen durch eigene Handlungen sind von der Garantie ausgenommen. Bewahre den Instanzstatus und relevante Logs auf, damit sich die Ursache prüfen lässt.

Melde dich an und reiche zur Prüfung ein Support-Ticket mit Instanz-ID, Beginn und Ende der Beeinträchtigung samt Zeitzone sowie Protokollen zu Verbindungs- oder Aufgabenausfällen ein. Gib niemals Passwörter, private Schlüssel oder Signaturzertifikate in einem Ticket an.

Anmelden und Ticket einreichen

Vier Laufzeiten, einheitlich in USD

Mietdauer prüfen, dann bezahlen

Nutze Tagesmieten zum Testen eines Projekts, Wochenmieten für Build-Phasen und Monats- oder Quartalsmieten für dauerhaft laufende Runner. Alle Preise auf dieser Seite sind in US-Dollar (USD) angegeben. Prüfe vor der Bestellung die Basiskonfiguration, Extras und Laufzeit.

USDT-TRC20

Überweise den Betrag anhand der Zahlungsdaten aus deiner Bestellung

Prüfe Netzwerk, Empfängerdaten und Bestellbetrag und bewahre den Transaktions-Hash auf. Ob die Zahlung erfolgreich war, siehst du am Bestellstatus im Control Panel. Wenn die Überweisung noch nicht bestätigt ist, reiche die Transaktionsdetails über ein Support-Ticket zur Prüfung ein, damit du nicht doppelt zahlst.

Abrechnung in USD

Visa / Mastercard / Amex

Kartenzahlung über Stripe

Schließe im Zahlungsvorgang die von deiner Bank geforderte Verifizierung ab. Bei einem Fehler prüfe zunächst den angezeigten Hinweis sowie die Kartenfreigabe und den Verifizierungsstatus. Sende niemals die vollständige Kartennummer oder den Sicherheitscode per E-Mail oder Support-Ticket.

Über Stripe · Abrechnung in USD

Es werden ausschließlich die beiden genannten Zahlungsmethoden unterstützt. Welche Zahlungswege tatsächlich verfügbar sind, zeigt die Backend-Schnittstelle. Zahlungsbestätigung und Bereitstellung der Instanz sind getrennte Schritte. Prüfe daher Bestell- und Instanzstatus separat im Control Panel.

Änderungen im Voraus einplanen

Vor dem Start diese vier Punkte prüfen

Änderungen an bestehenden Instanzen betreffen Umgebung und Daten. Prüfe vor der Umsetzung, welche Optionen verfügbar sind. Lösche keinen Runner, der gerade für Releases eingesetzt wird, nur um die Konfiguration anzupassen.

Vor einem Upgrade die Migration klären

Wenn du von Merge M4 S auf Merge M4 L wechseln möchtest, prüfe zuerst die verfügbaren Optionen im Control Panel. Gibt es dort keine passende Funktion, reiche ein Support-Ticket mit Instanz-ID, Zielkonfiguration und gewünschtem Umstellungszeitpunkt ein. Da es sich um zwei unterschiedliche physische Konfigurationen handelt, lässt sich beim Wechsel nicht einfach der RAM im laufenden Betrieb erweitern.

Sichere Dateien außerhalb des Repositorys, Runner-Konfigurationen, Zertifikate und Build-Skripte, bevor du den vorgeschlagenen Ablauf bestätigst. Die konkrete Änderung, mögliche Kosten und die Frage, ob eine neue Instanz nötig ist, richten sich nach der Rückmeldung im Control Panel oder der Bestätigung per Support-Ticket.

Verlängerung vor Ablauf in Instanzen und Rechnungen prüfen

Melde dich im Control Panel an und prüfe das Ablaufdatum der Instanz, die zugehörige Rechnung und die verfügbaren Verlängerungsoptionen. Bezahle anschließend den angezeigten Betrag. Verlasse dich nicht allein auf eine Weiterleitung der Zahlungsseite, sondern prüfe danach Rechnung und Gültigkeitszeitraum der Instanz im Control Panel.

Kümmere dich rechtzeitig um Standorte, die weiterlaufen sollen. Sichere bei auslaufenden Mietverhältnissen zuerst Projekte, Archive und benötigte Konfigurationen. Nach Ablauf wird der Speicher gelöscht; das Instanzlaufwerk ersetzt kein eigenes Team-Backup.

Vor dem Entfernen einer SSD-Erweiterung erst Daten sichern

Die zusätzliche SSD ist eine separat berechnete Speichererweiterung. Ob sie sich einzeln aus einer bestehenden Bestellung entfernen lässt, erfährst du über die verfügbaren Optionen im Control Panel oder per Support-Ticket. Das Löschen von Dateien beendet nicht automatisch die Abrechnung der Erweiterung.

Übertrage Modelle, Caches und Build-Artefakte zuerst von der zusätzlichen SSD. Prüfe, ob Build-Skripte, Mount-Pfade und Runner-Arbeitsverzeichnisse noch davon abhängen. Kläre anschließend, wann die Änderung wirksam wird und wie sie sich auf die nächste Rechnung auswirkt.

Mehrere Macs im Konto, Runner-Pool vom Team verwaltet

Du kannst mehrere Instanzen unter demselben Konto einrichten; jede wird separat berechnet und nutzt einen eigenen dedizierten physischen Mac. Vergib für unterschiedliche Standorte oder Einsatzzwecke passende Runner-Tags, registriere jeden Runner separat bei der CI-Plattform deines Teams und richte Aufgabenrouting und Parallelitätslimits ein.

Mehrere Macs teilen nicht automatisch Arbeitsverzeichnisse, Caches oder Signaturmaterial. Verwende für jede Instanz eine eigene Runner-Identität und verwalte Zugangsdaten sowie Build-Artefakte zentral. Auch eine Thunderbolt-5-Verbindung bildet nicht automatisch einen verteilten Build-Cluster.

Konfiguration wählen und Mac im Control Panel starten

Starte mit einem dedizierten M4 Mac und teste Toolchain und Build-Abläufe anhand eines echten Projekts. Modell, Standort, Mietdauer und Extras kannst du auf der Bestellseite einzeln prüfen.

macOS-CI-Mac mieten Anmelden, um Instanzen zu verwalten

Zwei M4-Konfigurationen, ab einem Tag