How do you configure self-hosted agents vs Microsoft-hosted, and when do you use each?
Quick Answer
Microsoft-hosted agents are managed VMs that spin up fresh for each job — zero maintenance but limited customization. Self-hosted agents run on your own infrastructure with persistent state, custom tools, and network access to private resources. Use self-hosted when you need VPN access, GPU, specific software, or faster builds with caching.
Detailed Answer
Think of renting a car vs owning one. A rental (Microsoft-hosted) is ready when you need it, always clean, and you do not worry about maintenance — but you cannot customize it or leave your tools in the trunk. Your own car (self-hosted) has your tools, your GPS settings, and can go to places rentals cannot — but you handle oil changes and insurance.
Microsoft-hosted agents are virtual machines managed by Azure DevOps. Each pipeline job gets a fresh VM (Ubuntu, Windows, or macOS), runs the job, and the VM is destroyed afterward. They come pre-installed with common tools (Node.js, .NET, Docker, kubectl) and have internet access. The advantage is zero maintenance. The disadvantage is no persistent state — every build starts cold, downloading dependencies from scratch.
Self-hosted agents run on machines you control — physical servers, VMs, or Kubernetes pods. You install the Azure Pipelines agent software, register it with your organization, and assign it to an agent pool. The agent persists between jobs, so build caches (npm cache, Docker layers, Maven repository) survive across runs, making builds significantly faster. Self-hosted agents can access private networks (databases, internal APIs, on-premises resources) that Microsoft-hosted agents cannot reach.
At production scale, teams use both types strategically. Microsoft-hosted for open-source projects and simple CI builds. Self-hosted for production deployments that need VPN access, builds requiring licensed software or GPUs, and performance-critical pipelines where caching matters. Self-hosted agents on Kubernetes use KEDA to auto-scale — zero agents when idle, scaling up to 20 during peak CI hours. Agent capabilities (user-defined labels like has-docker, has-gpu) let pipelines demand specific agent features.
The non-obvious gotcha is security. Self-hosted agents run pipeline code on your infrastructure — a malicious pipeline could access the host filesystem, network, or credentials cached from previous jobs. Use separate agent pools for different trust levels (one pool for internal teams, another for external contributors), run agents in containers for isolation, and never run self-hosted agents on machines with production access. Regularly rotate agent registration tokens and audit which pipelines use which pools.