2026 Mac Mini M6 für GitHub Actions: temporärer oder dauerhafter Runner

Der Runner meldet sich nach dem Auftrag automatisch ab, aber der Mac ist deshalb noch nicht sauber zurückgesetzt. Für öffentliche Repositorys, nicht vertrauenswürdigen Code oder harte Isolation wählen Sie einen temporären Runner; für stabile Signierung, externe Geräte oder besonders wertvolle Caches einen kontrollierten dauerhaften Runner. Für die meisten Produktionsteams ist ein zweigleisiger Aufbau aus temporären Ausführungsknoten und wenigen eingeschränkten dauerhaften Knoten die belastbarste Lösung.

Dieser Leitfaden richtet sich an Plattformteams, die Pull Requests und gewöhnliche Tests in einer sauberen Umgebung ausführen müssen. Er ist ebenso für mobile Entwicklungsteams mit Signaturmaterial, Testgeräten oder festen Netzabhängigkeiten gedacht. Wenn Sie die Zahl der Mac Mini M6 GitHub Actions Runner und deren Skalierung planen, erhalten Sie hier eine Entscheidung nach Teamtyp statt eine weitere Installationsanleitung.

Vertrauensgrenzen als Ausgangspunkt

Die zentrale Frage lautet nicht, ob der Mac Mini M6 genügend Rechenleistung für einen Build besitzt. Entscheidend ist, welchen Code der Runner ausführt und welche Informationen währenddessen erreichbar sind. Ein Pull Request kann Skripte, Abhängigkeiten und Build-Schritte verändern. Bei einem selbst gehosteten Runner geschieht diese Ausführung innerhalb der Berechtigungs- und Netzwerkgrenzen, die Sie dem Mac gegeben haben.

GitHub weist in seiner Dokumentation zur sicheren Nutzung von Actions darauf hin, dass Workflows aus weniger vertrauenswürdigen Quellen besondere Risiken für selbst gehostete Runner erzeugen. Die offiziellen Sicherheitshinweise für GitHub Actions sollten deshalb Grundlage für Ihr Berechtigungsmodell sein, nicht nur die Repository-Einstellung „privat“.

Drei häufig unterschätzte Grenzen bestimmen die Architektur:

• Arbeitsbereich und Prozesse: Ein Auftrag kann Dateien außerhalb des erwarteten Verzeichnisses erzeugen, Hintergrundprozesse starten oder lokale Caches verändern. Das Abmelden des Runner-Dienstes entfernt diese Rückstände nicht automatisch.
• Geheimnisse und Schlüsselbunde: Ein macOS-Schlüsselbund, Zertifikate oder Cloud-Zugangsdaten können nach einem Auftrag auf dem Gerät verbleiben. Eine spätere Aufgabe könnte davon profitieren, wenn die Bereinigung unvollständig ist.
• Netzwerk und Identität: Ein Runner kann interne Endpunkte, Paketquellen oder Artefaktspeicher erreichen. Eine kurze Lebensdauer des Runner-Eintrags ersetzt keine Netzwerksegmentierung und keine Einschränkung der Repository- und Workflow-Zuordnung.

Hinzu kommen versteckte Betriebskosten. Ein dauerhafter Knoten braucht Pflege für macOS, Xcode, SDKs, Runner-Anwendung und Abhängigkeiten. Ein temporärer Knoten benötigt dagegen eine belastbare Bereitstellung, Registrierung, Protokollablage und Rücksetzung. Sie tauschen also nicht einfach „Wartung“ gegen „keine Wartung“, sondern verschieben die Wartung von der laufenden Maschine in die Plattformautomatisierung.

Wichtiger Prüfpunkt: Bezeichnen Sie einen Runner nur dann als temporär, wenn Sie den gesamten Lebenszyklus kontrollieren: Zuweisung, Auftrag, Protokollübertragung, Abmeldung, Bereinigung, Neuaufnahme und Fehlerbehandlung. Die physische Hardware bleibt sonst ein dauerhafter Zustandsträger.

Temporäre und dauerhafte Runner im Vergleich

Für die Entscheidung können Sie die beiden Modelle anhand von sechs Fragen prüfen. Die folgende Gegenüberstellung ist als Auswahlwerkzeug gedacht:

• Isolation: Der temporäre Runner ist die bessere Wahl, wenn Aufträge aus Pull Requests oder öffentlichen Repositorys nicht auf Spuren vorheriger Aufgaben treffen dürfen. Der dauerhafte Runner ist nur vertretbar, wenn Sie den Code, die Arbeitsabläufe und die erreichbaren Systeme eng kontrollieren.
• Cache-Nutzung: Ein dauerhafter Runner kann abgeleitete Daten und installierte Werkzeuge behalten. Das kann die Laufzeit verkürzen, erzeugt aber auch Altlasten und schwer erkennbare Versionsabhängigkeiten. Beim temporären Modell müssen Sie Caches bewusst als externe, überprüfbare Artefakte behandeln.
• Signierung: Ein dauerhafter Knoten mit eingeschränktem Zugriff kann für Release-Aufträge leichter auditierbar sein. Ein temporärer Runner ist nur dann geeignet, wenn Geheimnisse kurzlebig injiziert und nachweisbar gelöscht werden.
• Wiederherstellung: Bei einem dauerhaften Runner genügt oft ein Dienstneustart nicht. Sie benötigen eine definierte Reparatur- oder Neuinstallationsprozedur. Beim temporären Modell ist die Wiederherstellung Teil jedes Auftrags, darf aber nicht nur aus einer erneuten Registrierung bestehen.
• Skalierung: GitHub beschreibt temporäre selbst gehostete Runner als passende Option für automatische Skalierung. Die Dokumentation zu selbst gehosteten Runnern erklärt dabei die Runner-Lebensdauer und organisatorische Einbindung. Die physische Bereitstellung und Rücksetzung eines macOS-Geräts müssen Sie jedoch selbst orchestrieren.
• Fehlerfolgen: Ein fehlerhafter dauerhafter Knoten kann wiederholt falsche Ergebnisse liefern. Ein temporärer Knoten kann nach einem Fehler verworfen werden, sofern Ihre Plattform Registrierung, Protokolle und Rückgabe des Geräts sauber behandelt.

Damit lässt sich die häufige Fehlannahme vermeiden, dass „ephemer“ automatisch „gelöscht“ bedeutet. GitHub kann einen temporären Runner aus dem Pool entfernen. Das Betriebssystem, der Benutzerkontext, lokale Dateien und der Schlüsselbund auf dem Mac verschwinden dadurch nicht zwangsläufig.

Entscheidungs-Checkliste für Ihre Runner-Architektur

Markieren Sie jede zutreffende Aussage. Die Auswertung erfolgt nicht nach der Anzahl allein, sondern nach der strengsten Sicherheitsbedingung:

• [ ] Externe Beiträge oder nicht vollständig vertrauenswürdige Pull Requests führen den Workflow aus.
  Folge: Diese Aufträge gehören in einen temporären Runner-Pool. Ein dauerhafter Knoten ist nur vertretbar, wenn er vollständig von sensiblen Systemen getrennt ist und nach jedem Auftrag nachweisbar zurückgesetzt wird.

• [ ] Der Auftrag benötigt Zertifikate, Provisioning-Profile, einen Schlüsselbund oder Veröffentlichungsrechte.
  Folge: Verwenden Sie zunächst einen eingeschränkten dauerhaften Veröffentlichungs-Runner. Ein temporärer Runner kommt erst infrage, wenn Injektion, Protokollierung und Löschung der Geheimnisse unabhängig geprüft wurden.

• [ ] Externe Geräte, ein fester USB-Aufbau oder eine dauerhaft gebundene physische Umgebung sind erforderlich.
  Folge: Planen Sie einen kontrollierten dauerhaften Knoten ein. Ein temporärer Auftrag kann darauf zwar kurzlebig sein, die physische Gerätezuordnung bleibt aber bestehen und muss separat abgesichert werden.

• [ ] Arbeitsbereich, Prozesse, temporäre Dateien und Zugangsdaten werden nach jedem Auftrag automatisiert entfernt.
  Folge: Wenn diese Bedingung nicht erfüllt ist, darf der Knoten nicht als sauberer temporärer Runner für sensible Aufgaben gelten.

• [ ] Die Bereinigung wird unabhängig geprüft und blockiert die erneute Freigabe bei einem Fehler.
  Folge: Wenn nein, reduzieren Sie zuerst die Rechte des dauerhaften Knotens und bauen Sie einen überprüfbaren Rücksetzungsprozess auf.

• [ ] Der Cache spart bei kontrollierten Repositorys deutlich Zeit, während die Toolchain selten geändert wird.
  Folge: Ein dauerhafter Build-Runner kann sinnvoll sein. Aktualisieren und leeren Sie den Cache trotzdem nach definierten Änderungen an Xcode, SDKs oder Abhängigkeiten.

• [ ] Die Warteschlange wächst regelmäßig, während die Aufträge voneinander unabhängig sind.
  Folge: Messen Sie Bereitstellungs- und Rücksetzungsdauer und ergänzen Sie gegebenenfalls temporäre Knoten. Erhöhen Sie nicht automatisch die Zahl der dauerhaften Runner.

• [ ] Registrierung, Routing, Protokollübertragung und Fehlerersatz lassen sich gemeinsam automatisieren.
  Folge: Dann kann ein Pilot für temporäre Runner sinnvoll sein. Wenn nein, beginnen Sie mit einer begrenzten Test-Workflow-Klasse und nicht mit der gesamten CI-Plattform.

Direkte Auswahlregel: Sobald die erste, zweite oder vierte Bedingung zutrifft, wählen Sie für gewöhnliche Prüfaufträge den temporären Pool. Sobald die dritte Bedingung zutrifft, reservieren Sie einen kontrollierten dauerhaften Pool. Wenn sowohl Sicherheits- als auch Stabilitätsanforderungen bestehen, verwenden Sie beide Pools und trennen Sie sie über Runner-Gruppen, Labels, Netzwerkregeln und Geheimnisse.

Private Projekte mit kontrollierten Abhängigkeiten

Bei persönlichen Projekten und vertrauenswürdigen privaten Repositorys ist ein dauerhafter Runner oft organisatorisch einfacher. Das gilt besonders, wenn die Auftragszahl überschaubar ist und Sie eine feste Toolchain mit Xcode, SDKs, Simulatoren oder privaten Abhängigkeiten pflegen müssen.

„Privat“ ist jedoch keine ausreichende Sicherheitsklassifizierung. Auch ein privates Repository kann externe Abhängigkeiten, veränderbare Build-Skripte oder mehrere Beitragende enthalten. Prüfen Sie deshalb, ob jeder Workflow-Schritt und jede verwendete Action tatsächlich vertrauenswürdig ist. Die GitHub-Anleitung zur Verwendung selbst gehosteter Runner in Workflows hilft bei der Zuordnung von Labels und Runner-Gruppen.

Für diesen Teamtyp passt ein dauerhafter Runner, wenn Sie:

• den Arbeitsbereich vor jedem Auftrag löschen;
• Prozesse und Dienste aus vorherigen Aufträgen erkennen und beenden;
• temporäre Dateien und Zugangsdaten nach dem Auftrag entfernen;
• Runner-Gruppen auf ausgewählte Repositorys beschränken;
• Änderungen an Toolchain und macOS-Version protokollieren;
• einen beschädigten Knoten aus dem Routing nehmen können.

Der Vorteil liegt in reproduzierbaren Werkzeugständen und lokal verfügbaren Caches. Der Preis ist eine wachsende Betriebsverantwortung: Ein Cache kann veraltet sein, ein SDK kann unbemerkt wechseln und ein fehlgeschlagener Bereinigungsschritt kann den nächsten Build beeinflussen.

Offene Beiträge und nicht vertrauenswürdige Ausführung

Für Open-Source-Teams mit externen Pull Requests sollte die erste Wahl ein temporärer Runner sein. Der Grund ist nicht die Sichtbarkeit des Quellcodes, sondern die Herkunft der auszuführenden Änderungen. Ein Beitrag kann die CI-Konfiguration oder ein Skript so verändern, dass es im Kontext des Runners ausgeführt wird.

In diesem Szenario sollte jeder Auftrag eine eigene Runner-Identität und einen klaren Endpunkt im Lebenszyklus erhalten. Nach dem Auftrag müssen Sie den Runner abmelden, die Arbeitsdaten entfernen und den Knoten entweder verifizieren oder aus dem Pool nehmen. Die REST-Schnittstelle für selbst gehostete Runner kann dabei für Registrierung, Statusprüfung und Entfernung in die Plattformautomation eingebunden werden.

Eine wichtige Einschränkung bleibt: Eine API-Aktion löscht nicht automatisch den Inhalt des Mac. Sie brauchen zusätzlich eine macOS-spezifische Bereinigung. Dazu gehören Benutzerverzeichnisse, Schlüsselbundzustände, gestartete Prozesse, temporäre Launch-Dienste, Paketmanager-Caches und lokale Artefakte. Wenn diese Prüfung fehlschlägt, darf der Knoten nicht einfach erneut als sauber markiert werden.

Der Mac Mini M6 kann konzeptionell als einmaliger macOS Runner dienen. Ob die Bereitstellung, Bereinigung und Rücksetzung nach Verfügbarkeit schnell genug für Ihre Warteschlange sind, ist jedoch noch eine Messfrage. Nach dem bestätigten Apple-Produktstart sind die ersten Geräte laut der vorgegebenen Faktenlage am 07.09.2026 noch nicht ausgeliefert; reale Werte für Rücksetzungsdauer, Cache-Nutzen und parallele Kapazität liegen daher noch nicht belastbar vor. Apples offizielle Mitteilung zum Mac mini mit M6 und die technischen Angaben zum Mac mini sind für die Gerätebasis maßgeblich, nicht für Ihre künftige Runner-Kapazität.

Mobile Teams mit hoher Build-Frequenz

Bei einem kleinen mobilen Entwicklungsteam liegt die Entscheidung meist zwischen Cache-Nutzen und Auftragsvermischung. Viele iOS- und macOS-Builds profitieren von einer konstanten Werkzeugumgebung. Gleichzeitig können häufige Aufgaben in einem dauerhaften Arbeitsbereich voneinander abhängen, wenn ein Skript Dateien, Simulatorzustände oder Build-Produkte nicht vollständig entfernt.

Beginnen Sie mit einer getrennten Routing-Logik:

1. Normale Kompilierungs- und Unit-Test-Aufträge laufen auf einem temporären oder streng zurücksetzbaren Pool.
2. Tests mit sensiblen Zugangsdaten erhalten keinen Zugriff auf den allgemeinen Build-Pool.
3. Release- und Signierungsaufträge werden auf eine eigene Runner-Gruppe gelenkt.
4. Fehlerhafte oder ungewöhnlich lange Aufträge markieren den Knoten zur Prüfung.
5. Caches werden nicht als Beweis für eine saubere Umgebung behandelt.

Messen Sie anschließend pro Auftragstyp die Wartezeit, die reine Laufzeit, die Wiederholungsrate, die Bereinigungsdauer und die Zeit bis zur erneuten Registrierung. Eine zusätzliche Maschine ist nicht automatisch sinnvoll, wenn die eigentliche Verzögerung durch Signierung, Artefaktübertragung oder eine fehlerhafte Abhängigkeit entsteht.

Bei der Auswahl von Mac Mini M6 GitHub Actions Runnern sollten Sie daher nicht nur die theoretische Hardwareleistung betrachten. Apple beschreibt die Plattform und die Unterstützung für Apple-Silicon-Anwendungen in den offiziellen Dokumenten; die Apple-Silicon-Migrationshinweise sind für Kompatibilitätsfragen relevant. Ob Ihre konkrete Xcode-, Simulator- oder Testgerätekombination die erwartete Leistung erreicht, muss mit Ihrem Workflow geprüft werden.

Signierung und Veröffentlichung

Signaturmaterial gehört nicht auf jeden allgemeinen Runner. Zertifikate, Provisioning-Profile, Schlüsselbunde und Veröffentlichungszugänge erweitern den Schaden, den ein kompromittierter oder falsch bereinigter Auftrag verursachen kann.

Für kontrollierte Teams ist ein kleiner, dauerhafter Veröffentlichungs-Pool häufig nachvollziehbarer als eine große Zahl temporärer Signierungsmaschinen. Das ist kein Freibrief für einen gemeinsam genutzten Mac. Begrenzen Sie den Pool auf bestimmte Repositorys, geschützte Branches und ausdrücklich zugelassene Workflow-Quellen. Der Knoten sollte keine gewöhnlichen Pull-Request-Aufträge ausführen.

Ein temporärer Runner für Signierung ist möglich, aber nur nach einem belastbaren Test der Geheimnisbehandlung:

• Geheimnisse werden erst nach erfolgreicher Auftragszuweisung injiziert.
• Der Workflow protokolliert keine privaten Schlüssel oder vollständigen Zugangsdaten.
• Der Schlüsselbund wird mit einem definierten Status geöffnet und danach geschlossen oder entfernt.
• Zertifikate und Profile werden nach dem Auftrag gelöscht.
• Der Knoten wird bei jedem Fehler aus dem Pool genommen.
• Die Löschung wird nicht nur durch einen Shell-Befehl behauptet, sondern durch einen unabhängigen Prüfschritt kontrolliert.

Wenn Sie diese Kette nicht auditieren können, verwenden Sie keinen temporären Signierungs-Runner als Sicherheitsbehauptung. Reduzieren Sie stattdessen die Rechte eines dauerhaften Knotens und isolieren Sie ihn technisch.

Plattformteams mit mehreren Projekten

Bei vielen Projekten wird die Architektur komplexer, weil nicht nur neue Runner gestartet werden müssen. Registrierung, Label-Zuordnung, Protokollübertragung, Image- oder Systempflege, Fehlerbehandlung und Rückgabe des Geräts müssen zusammenpassen.

Die automatische Skalierung von Linux-Containern ist kein direktes Modell für physische macOS-Geräte. Ein Mac muss möglicherweise aus einem definierten Systemzustand kommen, Netzwerkkonfigurationen übernehmen, Runner-Software registrieren und nach einem Auftrag wieder aus dem Routing entfernt werden. Ob die Hardware tatsächlich sauber ist, lässt sich nicht allein aus dem Status „offline“ oder „removed“ ableiten.

Planen Sie deshalb fünf getrennte Automationsschritte:

1. Zuweisung: Ein freier Mac erhält einen klaren Auftragstyp und eine begrenzte Runner-Gruppe.
2. Registrierung: Die Registrierung wird zeitlich begrenzt und nicht in Skripten oder Protokollen dauerhaft gespeichert.
3. Ausführung: Der Auftrag erhält nur die notwendigen Netzwerk- und Repository-Berechtigungen.
4. Rückgabe: Logs und relevante Statusdaten werden extern gespeichert, bevor der Knoten entfernt wird.
5. Wiederherstellung: Der Mac wird bereinigt, geprüft und entweder erneut freigegeben oder ersetzt.

GitHub nennt für automatisch skalierende Runner auch die externe Speicherung von Logs als wichtigen Betriebsaspekt. Prüfen Sie dafür die offizielle Runner-Dokumentation, und definieren Sie zusätzlich, wie Sie macOS-spezifische Systemfehler von einem fehlerhaften Workflow unterscheiden.

Zweigleisige Architektur

Die meisten Produktionsteams müssen nicht zwischen „alles temporär“ und „alles dauerhaft“ wählen. Eine zweigleisige Architektur trennt Aufgaben nach Risiko und technischem Bedarf:

• Temporärer Pool: Pull Requests, gewöhnliche Validierung, nicht vertrauenswürdige Beiträge und kurzlebige Testaufträge. Dieser Pool benötigt saubere Registrierung, Bereinigung, externe Protokollierung und einen sicheren Ausfallpfad.
• Kontrollierter dauerhafter Pool: Signierung, Veröffentlichungen, fest angeschlossene Testgeräte und Aufgaben mit schwer reproduzierbaren Umgebungsanforderungen. Dieser Pool braucht besonders enge Repository-, Branch- und Workflow-Grenzen.
• Gemeinsame Plattformregeln: Beide Pools müssen mit Labels, Runner-Gruppen, Netzwerkregeln, Updatefenstern und einem dokumentierten Rücksetzungsstandard betrieben werden.

Wenn Ihre Umgebung noch keine stabile automatische Rücksetzung bietet, verringern Sie zuerst die Rechte der dauerhaften Runner. Behaupten Sie nicht, einen temporären Runner zu betreiben, wenn der Mac nach dem Auftrag unverändert weiterläuft und sensible Daten behalten kann.

Für einen ersten Pilot wählen Sie eine gewöhnliche Test-Workflow-Klasse ohne Signaturmaterial. Vergleichen Sie dort temporäre und dauerhafte Ausführung unter gleicher Toolchain. Erst wenn Bereinigung, Protokolle und Fehlerübernahme funktionieren, erweitern Sie den temporären Pool. Release-Aufträge bleiben bis dahin auf einem eingeschränkten dauerhaften Knoten.

Umsetzung in sechs Prüfschritten

1. Auftragstypen inventarisieren: Trennen Sie Pull-Request-Tests, reguläre Builds, Simulatorläufe, Signierung, Veröffentlichungen und externe Geräte. Jeder Typ erhält eine eigene Vertrauens- und Verfügbarkeitsbewertung.

2. Berechtigungen begrenzen: Erstellen Sie getrennte Runner-Gruppen und Labels. Ein allgemeiner Build-Runner darf weder auf Signaturmaterial noch auf interne Veröffentlichungsdienste zugreifen.

3. Bereinigung reproduzieren: Führen Sie absichtlich einen Testauftrag aus, der Dateien, Prozesse und temporäre Zugangsdaten erzeugt. Prüfen Sie danach, was auf dem Mac tatsächlich noch vorhanden ist. Ein erfolgreicher Shell-Schritt ist kein ausreichender Nachweis.

4. Fehlerpfade testen: Unterbrechen Sie Registrierung, Build, Protokollübertragung und Bereinigung. Der Knoten muss in jedem Fall aus dem Routing genommen werden können. Legen Sie fest, wer ihn manuell prüft oder ersetzt.

5. Warteschlange messen: Erfassen Sie Startwartezeit, Laufzeit, Wiederholungen, Rücksetzungsdauer und Belegung getrennt nach Auftragstyp. Ergänzen Sie erst dann weitere Knoten. Für eine eigene Kapazitätsplanung können Sie die Informationen zur Runner-Verwaltung über die GitHub-API als Integrationsgrundlage verwenden.

6. Toolchain und Hardware validieren: Sobald Mac Mini M6 Geräte verfügbar sind, führen Sie denselben Workflow im temporären und dauerhaften Modus aus. Messen Sie nicht nur Build-Zeit, sondern auch Registrierung, Cache-Wiederherstellung, Bereinigung und Fehlerübernahme. Bis dahin bleiben Aussagen zur realen Runner-Kapazität vorläufig.

Wenn Sie zuerst eine einzelne gewöhnliche Test-Workflow-Klasse auslagern möchten, können Sie die deutschen Mac-Angebote von kvmsync als möglichen temporären Ausführungspfad prüfen. Für eine dauerhafte Beschaffung sollten Sie dagegen die eigenen Hardware-, Netzwerk- und Wartungskosten vollständig gegenrechnen.

FAQ für die Architekturentscheidung

Die Begriffe „temporärer Runner“ und „dauerhafter Runner“ beschreiben bei GitHub Actions den Ausführungslebenszyklus, nicht automatisch den Zustand der physischen Mac-Hardware. Für den Mac Mini M6 ist deshalb eine nachweisbare Rücksetzung wichtiger als das Etikett in der Runner-Konfiguration.

Wenn Ihre aktuelle Lösung aus gemeinsam genutzten Windows- oder Linux-Systemen besteht, bleiben dort typische Nachteile: macOS-spezifische Tests benötigen einen zusätzlichen Übergabepunkt, Signierungsdaten werden leichter über mehrere Aufgaben verteilt, und eine scheinbar günstige Container-Skalierung bildet die Lebensdauer physischer Macs nicht ab. Ein Mac Mini M6 kann diese Lücke schließen, aber nicht die Betriebsregeln ersetzen.

Für einen kurzfristigen Testaufwand oder einen Lastanstieg ist das Mieten eines Mac bei kvmsync oft flexibler als der sofortige Kauf mehrerer Geräte: Sie vermeiden gebundene Hardware, können einen getrennten temporären Pool erproben und bei sinkender Nachfrage wieder reduzieren. Nutzen Sie dafür zunächst einen klar abgegrenzten Workflow, nicht Ihre gesamte Signierungsumgebung. Details zu verfügbaren Optionen finden Sie auf der kvmsync-Übersichtsseite.

Wenn die Ausführung dauerhaft hohe Last trägt, feste externe Geräte benötigt oder langfristig unveränderliche Signaturprozesse verlangt, bleibt eigene Hardware unter Ihrer Kontrolle möglicherweise die bessere Lösung. Wenn Sie hingegen nur für Veröffentlichungsphasen, Tests oder eine Übergangszeit zusätzliche Mac-Kapazität benötigen, können gemietete Mac-Knoten die schnellere und risikoärmere Ergänzung sein. Entscheidend ist, dass Sie dieselben Rechte-, Bereinigungs- und Wiederherstellungsstandards anwenden wie bei eigenen Geräten.