Ein Build läuft nur so zuverlässig wie die Umgebung, in der er ausgeführt wird. Mit einem eigenen Azure DevOps Agent holen Sie die Pipeline-Ausführung ins eigene Rechenzentrum, in eine Azure-VM oder in ein internes Netzwerk. Ich zeige, wie der Agent arbeitet, wann sich Self-Hosting lohnt, wie die Einrichtung abläuft und welche Sicherheits- und Betriebsfragen in der Praxis entscheidend sind.
Die wichtigsten Entscheidungen auf einen Blick
- Self-hosted Agents nutzen Ihre eigene Hardware oder VM und haben direkten Zugriff auf interne Systeme.
- Ein Agent führt immer nur so viele Jobs parallel aus, wie seine Konfiguration und die verfügbaren Parallel Jobs erlauben.
- Für die Registrierung genügt ein eng begrenztes PAT mit der Berechtigung „Agent Pools: Read & manage“.
- Der Agent sollte unter einem nicht privilegierten Dienstkonto laufen und pro Projekt oder Vertrauensbereich getrennt werden.
- 2026 sollten neue Installationen die unterstützte Agent-Version 5.x und ein kompatibles Betriebssystem einplanen.
Was ein eigener Azure-DevOps-Agent tatsächlich macht
Azure Pipelines verteilt einen Build- oder Release-Job an einen freien Agent in einem Agent Pool. Der Agent fragt Azure DevOps regelmäßig nach Arbeit ab, lädt Repository, Artefakte und Aufgaben herunter, führt die Befehle lokal aus und übermittelt Logs sowie Ergebnisse zurück. Die Kommunikation funktioniert dabei normalerweise ausgehend, weshalb kein direkter eingehender Zugriff aus dem Internet auf die Maschine erforderlich ist.
Der entscheidende Unterschied zu einem Microsoft-hosted Agent liegt in der Umgebung. Bei Microsoft verwaltet jede Pipeline-Ausführung eine frische virtuelle Maschine. Beim selbst gehosteten Modell bleiben Betriebssystem, installierte SDKs, Caches und Netzwerkzugänge unter Ihrer Kontrolle. Genau das macht die Variante leistungsfähig, aber auch zu einer eigenen Betriebsverantwortung.
Capabilities und Demands richtig verstehen
Ein Agent meldet seine Capabilities, also Eigenschaften wie Betriebssystem, Architektur oder installierte Software. Eine Pipeline kann mit sogenannten Demands verlangen, dass beispielsweise das .NET SDK, Docker oder ein bestimmtes internes Tool vorhanden ist. So landet ein iOS-Build nicht versehentlich auf einer Linux-Maschine.
Ich empfehle, eigene Benutzer-Capabilities sparsam zu vergeben. Ein aussagekräftiges Merkmal wie workload=android ist nützlich, eine lange Liste individueller Sonderregeln macht die Pool-Auswahl dagegen schnell unübersichtlich.
pool:
name: "Interne Linux Agents"
demands:
- Agent.OS -equals Linux
- workload -equals dotnetWann Self-Hosting besser passt als ein Microsoft-hosted Agent
Ein eigener Agent ist besonders sinnvoll, wenn der Build auf Ressourcen zugreifen muss, die außerhalb des öffentlichen Internets liegen. Dazu gehören interne NuGet- oder npm-Registries, Datenbanken im Unternehmensnetz, Hardware im Labor, Lizenzserver oder ein Deployment-Ziel hinter einer deutschen Unternehmensfirewall.
Für gewöhnliche Webprojekte ist der Microsoft-hosted Pool oft der schnellere Start. Die Maschine wird automatisch gepflegt, die Software ist vorinstalliert und der Build hinterlässt keine Arbeitsdaten auf Ihrem Server. Laut Microsoft Learn sind Microsoft-hosted Agents außerdem mit einer frischen Umgebung pro Ausführung ausgelegt, während Self-Hosting eigene Wartung und Absicherung verlangt.
| Kriterium | Microsoft-hosted | Self-hosted |
|---|---|---|
| Infrastruktur | Microsoft stellt sie bereit | Ihre VM, Ihr Server oder Ihr Rechenzentrum |
| Software | Vorgegebene Images, automatische Aktualisierung | Individuell installierbar und selbst zu patchen |
| Interne Netzwerke | Meist kein direkter Zugriff | Direkter Zugriff möglich |
| Reproduzierbarkeit | Saubere Umgebung pro Job | Abhängig von Pflege und Bereinigung |
| Kosten | Über Parallel Jobs oder gebuchte Kapazität | Eigene Compute-, Speicher- und Betriebskosten |
| Wartungsaufwand | Niedrig | Updates, Monitoring und Fehlerbehebung liegen bei Ihnen |
Meine Faustregel ist einfach. Braucht die Pipeline nur Standardsoftware, starte ich mit einem Microsoft-hosted Agent. Braucht sie Netzwerkzugriff, spezielle Hardware oder reproduzierbare Tool-Versionen, rechtfertigt ein eigener Pool den zusätzlichen Aufwand.
So richten Sie den Agenten sauber ein
Die Einrichtung besteht nicht nur aus dem Download einer Datei. Vorher sollten Sie klären, in welchem Pool die Maschine landet, welche Projekte ihn verwenden dürfen und welche Identität die Jobs ausführen soll. Gerade diese Entscheidungen bestimmen später, ob der Agent kontrollierbar oder ein dauerhaftes Sicherheitsrisiko wird.
1. Maschine und Betriebssystem vorbereiten
Unterstützt werden Windows, Linux und macOS, jeweils abhängig von Architektur und Agent-Version. Für 2026 ist wichtig, die aktuelle Kompatibilitätsliste zu prüfen, weil die Agent-Version 5.x auf .NET 10 basiert. Typische Ausgangspunkte sind Ubuntu 22.04 oder 24.04, Windows Server 2019 oder neuer sowie aktuelle macOS-Versionen. Veraltete Systeme können den automatischen Agent-Upgrade blockieren.
Als praktische Startgröße reichen für viele normale Builds 2 bis 4 vCPUs und 8 bis 16 GB RAM. Große Container-Images, Android-Builds oder parallele Testläufe brauchen deutlich mehr. Entscheidend ist nicht die Zahl auf dem Datenblatt, sondern ob CPU, Arbeitsspeicher, temporärer Speicher und Netzwerk während der Spitzenlast ausreichen.
2. Agent Pool anlegen und Berechtigungen begrenzen
Legen Sie für produktive Umgebungen einen eigenen Pool an, statt alle Projekte im Standardpool zusammenzuführen. Ein gemeinsamer Pool spart zunächst Verwaltungsaufwand, erhöht aber das Risiko, dass ein kompromittiertes Build-Skript auf Artefakte oder Werkzeuge eines anderen Projekts zugreifen kann.
Für die Registrierung kann ein Personal Access Token verwendet werden. Microsoft Learn nennt dafür die Berechtigung „Agent Pools: Read & manage“. Der Token dient primär der Registrierung und sollte danach sicher verwahrt, mit einem kurzen Ablaufdatum versehen und nicht in YAML-Dateien oder Umgebungsvariablen von Builds hinterlegt werden.
3. Agent herunterladen und konfigurieren
Im Bereich „Project settings“ oder „Organization settings“ öffnen Sie „Agent pools“, wählen den Zielpool und laden das passende Paket für Windows, Linux oder macOS herunter. Anschließend entpacken Sie es in ein eigenes Verzeichnis und starten je nach Plattform config.cmd oder config.sh.
mkdir azdo-agent
cd azdo-agent
tar xzf vsts-agent-linux-x64-*.tar.gz
./config.shDas Konfigurationsprogramm fragt unter anderem nach Azure-DevOps-URL, Authentifizierung, Pool und Agent-Namen. Verwenden Sie einen Namen, der Standort und Zweck erkennen lässt, zum Beispiel de-berlin-linux-dotnet-01. Das erleichtert die Fehlersuche und spätere Skalierung.
4. Als Dienst statt im Terminal ausführen
Für einen dauerhaft verfügbaren Agenten ist ein Systemdienst die bessere Wahl. Unter Linux wird dafür typischerweise systemd verwendet, unter Windows der Windows-Service. Der Agent startet damit nach einem Neustart automatisch und kann zentral überwacht werden.
Für Tests ist der interaktive Betrieb praktisch, im produktiven Betrieb aber unzuverlässig. Ein geschlossenes Terminal, eine abgelaufene SSH-Sitzung oder ein Neustart würde sonst den gesamten Pool aus dem Takt bringen.
Sicherheit entscheidet über den Erfolg
Ein selbst gehosteter Agent führt letztlich Befehle aus, die aus Quellcode, YAML-Dateien, Pull Requests oder Erweiterungen stammen können. Er ist deshalb nicht bloß ein harmloser Runner, sondern ein Rechner mit Zugriff auf Netzwerk, Dateisystem und möglicherweise Cloud-Ressourcen. Ich behandle ihn immer wie eine kritische Build-Infrastruktur.
Das Dienstkonto muss möglichst wenig dürfen
Unter Windows eignen sich beispielsweise Network Service, Local Service oder ein eingeschränktes Group Managed Service Account. Unter Linux und macOS sollte ein eigener Benutzer wie svc_azuredevops verwendet werden, der kein sudo und keinen direkten administrativen Zugriff besitzt.
Ein häufiger Fehler besteht darin, den Agenten unter einem persönlichen Administratorenkonto zu betreiben, damit „alles funktioniert“. Das löst kurzfristig Berechtigungsprobleme, vergrößert aber bei einem kompromittierten Pipeline-Schritt den möglichen Schaden erheblich.
Secrets und Service Connections getrennt halten
Cloud-Zugänge sollten über Azure DevOps Service Connections oder eine vergleichbare Secret-Verwaltung bereitgestellt werden. Vergeben Sie nur die Rechte, die das Deployment braucht. Für Azure-Ressourcen ist Workload Identity Federation häufig die bessere Wahl als dauerhaft gespeicherte Client-Geheimnisse.
Auch die Pipeline selbst verdient Aufmerksamkeit. Pull Requests aus nicht vertrauenswürdigen Quellen sollten nicht automatisch auf einem Agenten laufen, der Zugriff auf Produktionsnetzwerke oder langlebige Zugangsdaten hat. Für solche Fälle sind getrennte Pools, Genehmigungen und kurzlebige Umgebungen sinnvoll.
Lesen Sie auch: Service Mesh in Kubernetes richtig einführen und betreiben
Netzwerk und Isolation planen
Der Agent benötigt ausgehenden Zugriff auf Azure DevOps und auf die Registries oder Dienste, die der Build nutzt. Eine restriktive Firewall mit erlaubten Zielen ist besser als uneingeschränkter Internetzugriff. Prüfen Sie außerdem Proxy, DNS, TLS-Inspection und Zertifikatsketten, weil diese Punkte in Unternehmensnetzen häufiger Probleme verursachen als die Agent-Installation selbst.
Für Projekte mit unterschiedlichem Vertrauensniveau sollte ein eigener Pool oder sogar eine eigene VM verwendet werden. Ein gemeinsamer Agent kann zwar mehrere Projekte bedienen, erzeugt aber Risiken durch Arbeitsverzeichnisse, Caches und lokal installierte Tools. Nach jedem Job sollten sensible temporäre Daten zuverlässig entfernt werden.
Skalierung, Parallelität und laufende Kosten
Ein registrierter Agent kostet in Azure DevOps nicht automatisch eine zusätzliche Lizenzgebühr. Die eigentlichen Kosten entstehen durch die zugrunde liegende VM oder Hardware, Speicher, Backups, Monitoring, Patch-Management und die Arbeitszeit des Teams. Zusätzlich begrenzt die Zahl der verfügbaren Parallel Jobs, wie viele Pipeline-Jobs gleichzeitig laufen können.
Ein Beispiel macht die Logik klar. Haben Sie vier Agenten, aber nur zwei parallele Jobs gebucht oder freigeschaltet, laufen höchstens zwei Jobs gleichzeitig. Haben Sie dagegen einen Parallel Job, warten weitere Ausführungen in der Warteschlange, selbst wenn mehrere Maschinen frei sind.
| Situation | Sinnvolle Lösung | Worauf Sie achten sollten |
|---|---|---|
| Ein kleines Team mit wenigen Builds | Ein einzelner Agent | Kein Single Point of Failure bei wichtigen Releases |
| Regelmäßige Builds und Tests | Zwei oder mehr identische Agents | Gleiche Tool-Versionen und gleiche Capabilities |
| Stark schwankende Last | Autoskalierung oder Managed DevOps Pools | Startzeit, Image-Pflege und Kosten beobachten |
| Strenge Trennung von Entwicklungs- und Produktionszugriff | Getrennte Pools und Netzwerke | Keine gemeinsame Identität für beide Bereiche |
Für eine hohe Verfügbarkeit plane ich mindestens zwei Agents pro kritischem Pool. Fällt eine VM aus, bleiben Builds möglich. Bei sehr ungleichmäßiger Auslastung können Managed DevOps Pools oder VM-Scale-Set-Agents sinnvoller sein als dauerhaft laufende Einzelmaschinen.
Typische Fehler im täglichen Betrieb
- Veraltetes Betriebssystem: Der Agent kann nicht auf eine neue Hauptversion aktualisieren. Prüfen Sie die Support-Matrix vor dem Upgrade.
- Unterschiedliche Tool-Versionen: Ein Build funktioniert auf Agent 1, scheitert aber auf Agent 2. Pinning und wiederholbare Images schaffen Abhilfe.
- Zu wenig Speicher: Container-Layer, Paket-Caches und Testartefakte füllen die Systemplatte. Überwachen Sie den freien Speicher und bereinigen Sie regelmäßig.
- Falsche Pool-Zuordnung: Ein Pipeline-Job wartet endlos, weil keine Maschine die verlangten Demands erfüllt. Prüfen Sie Pool, Capabilities und Schreibweise.
- Agent läuft interaktiv: Nach Logout oder Neustart ist die Pipeline nicht mehr erreichbar. Verwenden Sie für Produktion einen Dienst.
- Überprivilegiertes Konto: Der Agent kann auf mehr Systeme zugreifen als für den Build nötig. Reduzieren Sie Rechte und trennen Sie sensible Workloads.
Besonders tückisch sind nicht sofort sichtbare Drift-Probleme. Wenn jemand manuell ein SDK auf der Maschine installiert, bleibt der Build zunächst erfolgreich, wird aber später schwer reproduzierbar. Ich bevorzuge deshalb ein dokumentiertes Maschinen-Image oder ein Konfigurationsmanagement, das die Installation jederzeit neu herstellen kann.
Die richtige Entscheidung für Ihre DevOps-Umgebung
Ein selbst gehosteter Agent lohnt sich, wenn interne Systeme, Spezialhardware, feste Toolchains oder Compliance-Vorgaben wichtiger sind als minimaler Verwaltungsaufwand. Für Standard-Builds ohne privaten Netzwerkzugriff bleibt ein Microsoft-hosted Agent meist die schlankere Lösung.
Starten Sie mit einem klar abgegrenzten Pool, einem nicht privilegierten Dienstkonto, einer dokumentierten Toolchain und mindestens einem getesteten Wiederherstellungsweg. Wer diese vier Punkte von Anfang an berücksichtigt, bekommt nicht nur mehr Kontrolle über seine Pipelines, sondern auch eine belastbare Grundlage für Hosting und DevOps im deutschen Unternehmensumfeld.
