Microsoft-hosted agents work brilliantly for most pipelines. But eventually you hit a wall: you need private network access, specific tooling that takes 20 minutes to install, or a compliance requirement that rules out shared infrastructure. That is when self-hosted agents enter the picture.
The question is not whether to go self-hosted. It is how. And the answer has changed significantly over the past couple of years.
Why Self-Hosted?
Before diving into the options, it is worth being honest about when you actually need self-hosted agents. We see teams reach for them too early, taking on operational burden they did not need.
Legitimate reasons:
- Pipelines need to reach resources inside a private VNet (databases, storage accounts behind firewalls)
- You need specific software pre-installed that is not on Microsoft-hosted images
- Compliance or data sovereignty requirements prevent using shared infrastructure
- Build times are too long because of large dependency installations
Not great reasons:
- "We've always done it this way"
- "Microsoft-hosted agents are slow" (they have got much faster)
- "We want more control" (you are about to find out how much work "control" actually is)
If none of the legitimate reasons apply, stick with Microsoft-hosted. Seriously. The operational overhead of self-hosted agents is real.
Option 1: VM Scale Set Agents
This is the most established approach. Azure DevOps natively supports VMSS-backed agent pools, where the platform scales your scale set up and down based on pipeline demand.
How It Works
You create a Virtual Machine Scale Set with a custom image containing your agent software, tooling, and configuration. Azure DevOps manages the scaling: when a job is queued, it provisions a new instance from the scale set. When the job completes, the instance is torn down or recycled.
What You Manage
This is where the complexity lives:
- Custom images. You need an image pipeline. Packer or Azure Image Builder to create a golden image with your tooling, agent software, and configuration. Every time you need a new tool version, you rebuild the image.
- OS patching. Your custom images need regular updates. Windows Updates, security patches, dependency updates. That image pipeline needs to run frequently.
- Networking. The VMSS needs to sit in the right VNet/subnet, with the right NSG rules, and potentially a NAT gateway for outbound connectivity.
- Scale settings. Maximum and minimum instance counts, scale-in policies, idle timeout configuration.
- Agent updates. The Azure DevOps agent itself gets updated regularly. Your image pipeline needs to track these updates.
- Diagnostics. When a build fails because of an infrastructure issue, you are the one debugging it.
Cost Profile
VMs cost money whether they are running builds or not. You can configure scale-to-zero, but then you pay a cold start penalty: provisioning a new VM from an image takes 3-8 minutes depending on the image size and tooling installation. Teams that cannot tolerate that delay end up keeping at least one or two instances warm around the clock.
For a typical setup with 4-6 warm agents running D4s_v5 instances, you are looking at roughly £800-1,200/month before you factor in the image storage, networking, and the engineering time to maintain it all.
Verdict
VMSS agents are the most mature option and give you the most control. But "most control" is another way of saying "most responsibility." If your team has the capacity to maintain an image pipeline, manage networking, and troubleshoot VM-level issues, this works well. If your platform team is already stretched, this is a significant ongoing commitment.
Option 2: Containerised Agents
The alternative to VMs is to package your agent into a Docker container and run it on one of Azure's container platforms. The agent image is the same regardless of where you run it: a Dockerfile with the DevOps agent, your tooling, and a startup script. What changes is the hosting platform, and Azure gives you four choices.
The Container Image
Whichever platform you choose, you are managing the same things:
- Dockerfile. Agent software, build tooling, startup configuration. Needs rebuilding when tooling or agent versions change.
- Container registry. ACR for image storage, scanning, and retention policies.
- Docker-in-Docker. If your pipelines build container images, you need DinD or Kaniko. DinD requires privileged containers (security concern). Kaniko works but has compatibility limitations.
Where to Run It
| Platform | Scaling | VNet Support | Cost Model | Best For |
|---|---|---|---|---|
| ACI | Manual (script/Function) | VNet injection | Pay-per-second | Simple workloads, burst capacity |
| Container Apps | Built-in (KEDA) | Supported | Pay-per-use or dedicated | Event-driven scaling without Kubernetes |
| AKS | KEDA, HPA | Full control | Node pool pricing | Already running AKS for other workloads |
ACI is the simplest. No cluster, no orchestrator. You run a container group, it registers as an agent, picks up a job. For scaling, you need a lightweight script or Azure Function to spin up containers when jobs queue. Pay-per-second with no minimum. Typical cost: £50-200/month.
Azure Container Apps sits between ACI and AKS. Managed Kubernetes under the hood but you never touch it. Microsoft has an official tutorial for running Azure Pipelines agents as Container Apps jobs, with KEDA scaling based on pending pipeline runs. Scale-to-zero on the consumption plan, VNet support. The main limitation: Container Apps does not support Docker-in-Docker (no privileged containers), so pipelines that build container images will not work here. Linux only.
AKS is the most powerful and the most complex. If you already have AKS for application workloads and your team knows Kubernetes, adding agent pods is sensible. If you are standing up AKS purely for CI/CD, you have taken a wrong turn. Node pools run 24/7: £400-800/month minimum before monitoring and engineering time.
The Bottom Line on Containers
All four platforms achieve the same outcome: your agent container runs, picks up jobs, and has network access to private resources. The complexity and cost vary, but the Docker image is identical. Pick the platform you already have, or the cheapest one that meets your networking requirements. Do not over-engineer this.
Option 3: Managed DevOps Pools
This is the newer option, and for most teams, it is the one we recommend. Managed DevOps Pools (MDP) is a Microsoft-managed service that handles the infrastructure behind your self-hosted agent pools.
How It Works
You create a Managed DevOps Pool resource in Azure, point it at your Azure DevOps organisation, and configure your pool settings. Microsoft manages the underlying compute: provisioning, patching, scaling, and agent updates. You get the benefits of self-hosted agents (VNet access, custom images) without the operational burden.
What You Manage
Comparatively little:
- Pool configuration. Maximum agents, standby count, image selection.
- Networking. VNet delegation for private network access. You delegate a subnet to the Managed DevOps Pool, and agents get injected into your network.
- Image selection. Choose from Microsoft-provided images or bring your own custom image if needed.
That is essentially it. No image pipeline to maintain, no OS patching schedule, no scale-in policy debugging, no agent update tracking.
Cost Profile
This is where MDP really shines. The pricing model is pay-per-minute: you pay for compute only when agents are running builds. Scale-to-zero is the default behaviour, not an optimisation you need to configure. Spot instance support brings compute costs down further for non-critical pipelines.
We recently migrated a client from 15 self-hosted VMs running as DevOps agents to Managed DevOps Pools. Their previous setup cost roughly £1,000/month in VM compute alone, plus engineering time for maintenance. After migration, their agent compute costs dropped to £100-300/month depending on build volume, a 70-90% reduction. The engineering time savings were even more significant.
Limitations
MDP is not perfect for every scenario:
- Less customisation. You have fewer options for customising the agent environment compared to VMSS or containers. If you need very specific tooling, you may need a custom image.
- Image build times. Custom images take longer to provision than pre-built Microsoft images.
- Feature maturity. As a newer service, it does not yet have feature parity with VMSS agents in every area.
Verdict
For the vast majority of teams that need self-hosted agents, Managed DevOps Pools is the obvious winner. The operational overhead is a fraction of the alternatives, the cost model is better, and the scaling behaviour is what you actually want (scale-to-zero by default, fast provisioning when needed).
Decision Framework
Here is how we guide clients through the decision:
- Do you actually need self-hosted agents? If not, use Microsoft-hosted. Full stop.
- Do you need private VNet access but standard tooling? Managed DevOps Pools. VNet delegation gives you network access without the operational burden.
- Do you need heavily customised agent environments? VMSS is the most mature option. Accept the operational cost and invest in a solid image pipeline.
- Do you want containers? Pick the platform you already have. ACI for simplicity, Container Apps for event-driven scaling, AKS only if you already run it.
- Are you cost-sensitive? Managed DevOps Pools with spot instances. Pay-per-minute pricing with scale-to-zero beats always-on VMs every time.
The industry is clearly moving towards managed agent infrastructure. If you are currently running self-hosted VMs and feeling the maintenance burden, Managed DevOps Pools is worth evaluating. The migration is straightforward, and the cost savings usually justify the effort within the first month.
Running self-hosted DevOps agents and feeling the pain? Get in touch. We help teams right-size their CI/CD infrastructure and cut unnecessary operational overhead.