Sie sollen Claude Code für ein Team freigeben, wissen aber nicht, ob die Ausführung in Ihrer Infrastruktur laufen muss? Schnellste Entscheidung: Bleiben Sie bei der Cloud, wenn Netzwerk- und Governance-Vorgaben erfüllt sind. Prüfen Sie Self-Hosting nur bei konkretem Bedarf an internem Netzwerkzugriff, kontrollierter Werkzeugkette oder eigener Ausführungsumgebung. Für Xcode-Aufgaben klären Sie zuerst, ob der Runner die benötigte macOS-Plattform tatsächlich unterstützt.
Dieser Leitfaden ist für IT-Verantwortliche gedacht, die Datenwege, Governance und Betriebsverantwortung bewerten. Plattformteams finden Kriterien für Runner-Betrieb und Wartung. Apple-Plattformteams erhalten Prüfpunkte für Xcode, Signierung und Mac-Builds.
Zuletzt aktualisiert am 25.09.2026. Der Status und die Voraussetzungen wurden anhand der offiziellen Ankündigung zu selbst gehosteten Claude-Code-Sitzungen und der Apple-Dokumentation zu externen Agents in Xcode geprüft. Da es sich um eine öffentliche Testphase handelt, sollten Sie Verfügbarkeit, Teilnahmebedingungen und Plattformangaben unmittelbar vor einer Beschaffung erneut prüfen.
Zuerst die drei Ausführungsmodelle auseinanderhalten
„Cloud“, „selbst gehostet“ und „Remote Control“ beschreiben unterschiedliche Ausführungsorte und Verantwortlichkeiten. Verwechseln Sie insbesondere eine Sitzung auf einem persönlichen Rechner nicht mit einem gemeinsam genutzten Runner für CI/CD.
Bei der Cloud-Ausführung übernimmt der verwaltete Dienst die Ausführungsumgebung. Sie müssen keine eigene Runner-Infrastruktur bereitstellen und pflegen. Bei einer selbst gehosteten Umgebung läuft die Ausführung auf einer von Ihrer Organisation kontrollierten Infrastruktur. Das verschiebt Aufgaben wie Bereitstellung, Aktualisierung und Verfügbarkeit zu Ihrem Team. Remote Control bezeichnet dagegen die Fernsteuerung einer Sitzung, die auf dem eigenen Rechner der nutzenden Person läuft; daraus entsteht nicht automatisch ein geteilter, dauerhaft verfügbarer Build-Runner. Die Dokumentation zur Sitzungszuordnung und zum Ausführungsort erläutert diese Abgrenzung.
Was unterscheidet eine selbst gehostete Umgebung von der Cloud? Entscheidend ist nicht allein, wo die Oberfläche geöffnet wird, sondern wo die Ausführung stattfindet, wer die Umgebung betreibt und welche Daten zur Modellverarbeitung übertragen werden. Self-Hosting kann Netzwerkzugriff und Werkzeugkontrolle verändern, ist aber kein Beleg dafür, dass sämtliche Daten lokal bleiben.
| Prüffeld | Cloud-Ausführung | Selbst gehostete Umgebung | Remote Control |
|---|---|---|---|
| Ort der Sitzung | Verwaltete Umgebung | Infrastruktur Ihrer Organisation | Rechner der nutzenden Person |
| Infrastrukturverantwortung | Beim verwalteten Dienst | Bei Ihrem Plattformteam | Beim Team, das den Rechner bereitstellt |
| Interner Netzwerkzugriff | Abhängig von den verfügbaren Integrationen und Richtlinien | Kann bei geeigneter Netzwerkanbindung möglich sein | Abhängig von Netzwerk und Rechner der Person |
| Geeignet für gemeinsame CI-Aufgaben | Nur, wenn der vorgesehene Ablauf dies unterstützt | Nur, wenn Runner, Orchestrierung und Plattform dafür bestätigt sind | Nicht automatisch; eine persönliche Sitzung ist kein gemeinsam verwalteter Runner |
| Hauptrisiko | Vorgaben passen eventuell nicht zu Daten- oder Netzwerkregeln | Zusätzlicher Wartungs- und Bereitschaftsaufwand | Abhängigkeit von persönlichem Gerät und Sitzung |
Wann benötigt ein Unternehmen eine selbst gehostete Umgebung? Dann, wenn eine dokumentierte interne Anforderung durch die verwaltete Ausführung nicht erfüllt wird, etwa ein notwendiger Zugriff auf ein internes System oder eine kontrollierte Ausführungsumgebung. Ein pauschaler Wunsch nach „mehr Kontrolle“ reicht als Beschaffungsgrund nicht: Benennen Sie die konkrete Richtlinie, den betroffenen Datenfluss und die technische Abhilfe, die Self-Hosting liefern soll.
Plattformteam: Runner-Support vor dem Aufbau belegen
Die Ankündigung einer selbst gehosteten Funktion bestätigt nicht automatisch, dass jeder Runner-Typ oder jedes Betriebssystem unterstützt wird. Behandeln Sie die Plattformliste, den Betriebsmodus und die Wartungsvorgaben als Beschaffungsvoraussetzungen. Insbesondere dürfen Sie aus der Ankündigung allein keine Unterstützung für macOS oder Xcode ableiten.
Unterstützt ein selbst gehosteter Claude-Code-Runner macOS? Verlassen Sie sich nur auf eine ausdrücklich dokumentierte Plattformfreigabe für den konkreten Betriebsmodus. Die hier referenzierten offiziellen Informationen belegen keine pauschale macOS- oder Xcode-Unterstützung für selbst gehostete Runner. Wenn Ihre aktuelle Dokumentation diese Plattform nicht eindeutig nennt, lautet die Antwort für die Architekturplanung zunächst: nicht bestätigt.
Prüfen Sie vor einem Pilotversuch folgende Punkte in der Dokumentation zu selbst gehosteten Umgebungen und in der Produktionsanleitung:
- Betriebssystem und Betriebsart: Welche Systeme sind ausdrücklich aufgeführt? Welche Laufzeit, Netzwerkverbindung und Berechtigungen setzt der dokumentierte Modus voraus?
- Aktualisierung: Wer installiert Runner-Updates, wann werden Änderungen freigegeben und wie verhindern Sie, dass eine veraltete Umgebung produktive Sitzungen übernimmt?
- Image-Verantwortung: Wer erstellt, prüft und versioniert das Basis-Image? Wie werden Abhängigkeiten und Werkzeuge auf einen bekannten Stand zurückgeführt?
- Kapazität: Wird ein dauerhaft verfügbarer Runner benötigt oder kann Kapazität bei Bedarf bereitgestellt werden? Wer verantwortet Planung, Warteschlange und Orchestrierung?
- Fehlerbehandlung: Welche Stelle überwacht Erreichbarkeit, Laufzeitfehler und fehlgeschlagene Sitzungen? Gibt es einen dokumentierten Rückfall auf die Cloud?
- Zugriffsmodell: Welche Identitäten dürfen Runner starten, und wie wird verhindert, dass ein Job unkontrolliert auf interne Systeme oder Geheimnisse zugreift?
**Achtung:** „Der Runner startet“ ist kein Freigabekriterium. Damit ist weder die Unterstützung Ihres Betriebssystems bestätigt noch nachgewiesen, dass Updates, Neustarts, parallele Aufträge und Fehlerwiederherstellung für den Team-Betrieb funktionieren.
Sicherheitsteam: Datenwege statt Standortetikett prüfen
„Selbst gehostet“ beantwortet nicht die gesamte Datenschutzfrage. Trennen Sie mindestens die Daten, die auf Ihrer Infrastruktur verarbeitet oder gespeichert werden, von den Inhalten, die zur Modellverarbeitung übertragen werden. Laut Aufgabenmodell der offiziellen Dokumentation können sich Repository-Kopien, Build-Artefakte und lokal bereitgestellte Geheimnisse auf der selbst verwalteten Infrastruktur befinden. Prompts, Antworten und Werkzeugergebnisse, die für die Inferenz erforderlich sind, müssen dagegen anhand der dokumentierten Datenflüsse und Richtlinien geprüft werden. Die Dokumentation zu selbst gehosteten Umgebungen ist dafür die maßgebliche technische Referenz.
Erstellen Sie vor dem Pilotversuch ein Datenflussdiagramm mit diesen Stationen:
- Entwicklergerät oder CI-Auftrag startet die Sitzung.
- Der Runner bezieht erforderliche Repository-Inhalte und Werkzeuge aus den vorgesehenen Quellen.
- Die Sitzung verarbeitet Eingaben und Werkzeugergebnisse; markieren Sie dabei, welche Inhalte die eigene Infrastruktur verlassen.
- Modellanfragen und Antworten werden gemäß dem dokumentierten Dienst- und Organisationsmodell verarbeitet.
- Protokolle, Sitzungsdaten, Artefakte und Geheimnisse werden den jeweils zuständigen Speicherorten und Aufbewahrungsregeln zugeordnet.
Halten Sie für die Datenschutzprüfung fest, welche Datenkategorien zulässig sind, wer die Freigabe erteilt und wie Sie den Zugriff bei einem Vorfall entziehen. Wenn Sie nicht belegen können, ob ein bestimmter Inhalt an einen externen Inferenzdienst gelangt, behandeln Sie ihn bis zur Klärung nicht als lokal begrenzt.
Apple-Team: Claude Code und Xcode-Aufgaben getrennt bewerten
Claude Code kann bei Analyse, Bearbeitung und allgemeinen Entwicklungsabläufen unterstützen. Ein Xcode-Build ist jedoch zusätzlich von macOS, Xcode, gegebenenfalls Simulatoren und Signierungsressourcen abhängig. Stellen Sie deshalb keine Gleichung „Agent kann mit Xcode arbeiten = selbst gehosteter Runner unterstützt Mac“ auf.
Kann die selbst gehostete Umgebung Xcode-Builds ausführen? Nur wenn die unterstützte Runner-Plattform die erforderliche macOS-Ausführung bestätigt und Ihr Team einen durchgängigen Build auf dieser Plattform erfolgreich geprüft hat. Apple beschreibt, wie externe Agents Zugriff auf Xcode-Werkzeuge erhalten können; diese Dokumentation belegt jedoch nicht eigenständig, dass ein bestimmter Claude-Code-Runner macOS unterstützt.
Teilen Sie Aufgaben deshalb in zwei Klassen:
- Allgemeine Agent-Aufgaben: Code lesen, Änderungen vorschlagen, Tests vorbereiten oder nicht plattformgebundene Prüfungen ausführen. Prüfen Sie hierbei Berechtigungen und Datenzugriff unabhängig vom Betriebssystem.
- Apple-Plattform-Aufgaben: Xcode-Builds, Simulatorläufe, Signierung und Paketierung. Diese gehören nur dann in den Runner-Plan, wenn Betriebssystem, Xcode-Version, Zertifikatszugriff und Bereitstellung der Artefakte ausdrücklich geklärt sind.
Wenn ein realer Mac für die Ausführung erforderlich ist, planen Sie dessen Bereitstellung als separate Infrastrukturentscheidung. Ein Mac kann die benötigte Apple-Plattform bereitstellen, bestätigt aber für sich genommen weder die Kompatibilität mit dem selbst gehosteten Runner noch die Freigabe durch Ihren CI- oder Sicherheitsprozess.
FinOps: Gesamtkosten und Kapazitätsverantwortung vergleichen
Ein belastbarer Vergleich braucht die tatsächliche Nutzung, aktuelle offizielle Preise und interne Personalkosten. Da hier keine verifizierten Preisdaten für Ihre Organisation vorliegen, wäre eine konkrete Ersparnisprognose irreführend. Füllen Sie die Felder mit gültigen Angeboten und Ihrer internen Kostenbasis, bevor Sie eine Kaufentscheidung treffen.
| Kosten- oder Betriebsfeld | Verwaltete Cloud | Selbst gehostete Ausführung |
|---|---|---|
| Dienstnutzung | Abrechnung gemäß dem für Ihre Organisation gültigen Angebot | Dienstkosten und mögliche Nutzungskosten gemäß Vertrag und Dokumentation prüfen |
| Rechnerkapazität | Keine eigene Runner-Hardware für die verwaltete Ausführung einplanen | Hosts oder andere bestätigte Infrastruktur, einschließlich Reservekapazität, kalkulieren |
| Images und Werkzeuge | Weniger eigene Verantwortung für die Runner-Basis, abhängig vom Dienstumfang | Image-Erstellung, Sicherheitsprüfung, Versionierung und Wiederherstellung einplanen |
| Betrieb | Nutzungs- und Richtlinienverwaltung bleiben intern | Zusätzlich Monitoring, Updates, Orchestrierung, Fehlerbehebung und Bereitschaft bewerten |
| Leerlauf | Eigene Runner-Leerlaufkosten entfallen, sofern keine separate Infrastruktur bereitgestellt wird | Nicht ausgelastete oder dauerhaft bereitgehaltene Kapazität kann Kosten verursachen |
| Apple-Builds | Nur bei ausdrücklich bestätigtem Plattformangebot | Mac-Kapazität, Xcode-Pflege und sichere Signierungsabläufe separat kalkulieren |
Cloud-Gesamtkosten = tatsächliche Dienstkosten + interne Governance- und Integrationsarbeit.
Self-Hosting-Gesamtkosten = Dienstkosten + Host- und Reservekapazität + Image-Pflege + Updates + Orchestrierung + Monitoring + Fehlerbehebung + Leerlauf + interne Sicherheitsarbeit.
Ersetzen Sie jeden Posten durch den gültigen Preis oder eine interne Aufwandsschätzung. Wenn Kapazitätsauslastung oder Wartungsaufwand noch unbekannt sind, führen Sie sie als offene Annahmen und setzen Sie einen Prüftermin, statt einen pauschalen Rabatt gegenüber der Cloud zu behaupten. Für Apple-Builds gehören außerdem die Kosten des tatsächlichen Mac-Betriebs und die Pflege der Signierungsumgebung in die Rechnung.
Einkauf und Pilotteam: Mit klaren Abbruchbedingungen entscheiden
Nutzen Sie die folgenden Bedingungen als Entscheidungswerkzeug. Dokumentieren Sie jeweils Nachweis, verantwortliche Rolle und Rückfalloption.
- Wenn die Cloud Netzwerk-, Daten- und Governance-Vorgaben erfüllt, dann wählen Sie zunächst die verwaltete Ausführung. Andernfalls dokumentieren Sie genau, welche Anforderung offenbleibt.
- Wenn der Bedarf nach internem Netzwerkzugriff oder kontrollierter Werkzeugkette konkret belegt ist, dann prüfen Sie Self-Hosting. Andernfalls vermeiden Sie den zusätzlichen Betrieb einer eigenen Runner-Flotte.
- Wenn die offizielle Dokumentation die Zielplattform und den Betriebsmodus ausdrücklich bestätigt, dann starten Sie einen begrenzten Pilot. Andernfalls stoppen Sie die Beschaffung und fordern eine belastbare Plattformauskunft an.
- Wenn der Anwendungsfall Xcode oder andere macOS-native Aufgaben umfasst, dann verlangen Sie zusätzlich einen erfolgreichen End-to-End-Build auf einer bestätigten Mac-Plattform. Andernfalls behandeln Sie diese Aufgaben als nicht abgedeckt.
- Wenn Signierungsidentitäten, Geheimnisse und Build-Artefakte getrennt und nachvollziehbar verwaltet werden, dann lassen Sie die Sicherheitsfreigabe fortsetzen. Andernfalls bleibt die Pipeline außerhalb der Produktionsfreigabe.
- Wenn Wartung, Updates, Überwachung und Fehlerbehebung intern mit klarer Zuständigkeit abgedeckt sind, dann bewerten Sie die Gesamtkosten. Andernfalls rechnen Sie den fehlenden Betriebsaufwand nicht mit null an.
Wer trägt die Verantwortung für die Aktualisierung und den Betrieb des Runners? Bei einer selbst gehosteten Architektur muss diese Zuständigkeit in Ihrer Organisation benannt sein. Lassen Sie offen, wer Images aktualisiert, Ausfälle überwacht oder veraltete Umgebungen sperrt, ist die vermeintlich bessere Kontrolle in der Praxis eine nicht zugewiesene Betriebsaufgabe. Die Produktionsanleitung für den Deployment-Betrieb sollte deshalb Teil der technischen Abnahme sein.
Wiederholen Sie die Bewertung, wenn sich die Runner-Plattform, die Teilnahmebedingungen, Ihre ZDR-Vereinbarung, interne Datenschutzanforderungen oder die Xcode-Pipeline ändern. Die öffentliche Testphase ist kein dauerhaftes Kompatibilitätsversprechen. Halten Sie deshalb den geprüften Dokumentationsstand im Entscheidungsprotokoll fest.
Für den Mac-Bedarf eine separate Beschaffungsentscheidung treffen
Ein selbst gehosteter Claude-Code-Runner bedeutet nicht automatisch, dass Sie einen Mac kaufen müssen. Umgekehrt ersetzt ein Mac nicht die notwendige Bestätigung, dass Claude Code und der gewählte Runner-Modus darauf unterstützt werden. Trennen Sie also die Entscheidung „Wo läuft der Agent?“ von der Entscheidung „Welche Infrastruktur braucht der Xcode-Build?“.
Wenn Ihre Apple-Pipeline einen realen Mac erfordert, vergleichen Sie den Kauf mit einer bedarfsgerechten Bereitstellung anhand von Auslastung, Wartungszuständigkeit und Laufzeit. Ein eigener Rechner bindet Kapital, benötigt Pflege und kann bei schwankender Nutzung ungenutzte Kapazität hinterlassen. Für einen kurzfristigen Pilot oder eine begrenzte Testphase kann die Miete eines Mac diese Bindung vermeiden; für langfristige, gleichmäßig hohe Auslastung oder Anforderungen an lokale Anschlüsse kann eigene Hardware sinnvoller sein. Prüfen Sie für einen Hardwarekauf die verfügbaren Mac-Bestelloptionen; wenn Sie zunächst unterschiedliche Remote-Mac-Einsatzszenarien vergleichen, finden Sie bei MACGPU weitere Informationen zur Mac-Nutzung auf Zeit.
Der nächste Schritt ist nicht die sofortige Beschaffung, sondern die Prüfung der offiziellen Runner-Plattformliste und Ihrer konkreten Xcode-Pipeline. Ist macOS bestätigt und der End-to-End-Test bestanden, können Sie Mac-Kapazität gezielt für den Build-Pfad planen. Ist die Plattform nicht bestätigt, bleibt die Cloud für Claude Code die belastbarere Wahl, während Sie Mac-Builds getrennt und mit klaren Sicherheits- und Betriebskriterien evaluieren.