Agents & pools

Hosted vs self-hosted, securing agents.

Intermediate25 min · lesson 3 of 15

Pipelines run on agents — the machines that execute your jobs. Choosing between Microsoft-hosted and self-hosted agents, and understanding pools, is a practical DevOps decision that affects speed, cost, and access.

Hosted vs self-hosted agents

A Microsoft-hosted agent is a fresh, fully-managed virtual machine provided for each job — you get a clean environment every run with common tools preinstalled, and no infrastructure to patch or maintain. It is the simplest choice and right for most workloads. A self-hosted agent is a machine you provide and maintain (a VM, a container, or on-prem server), which you choose when you need custom software or specific tool versions, access to private network resources (an internal artifact feed or database), faster builds through persistent caching, or more control over the environment. The trade-off is that you own patching, scaling, and security of self-hosted agents, so use them deliberately where hosted agents cannot meet the requirement.

choosing an agent
# NEED AGENT
# clean managed environment, no maintenance → Microsoft-hosted
# reach internal/private network resources → self-hosted (in your network)
# custom tools / specific versions → self-hosted (preinstalled)
# persistent caching / faster builds → self-hosted
# isolation + control → self-hosted (you own patching)
pool:
vmImage: 'ubuntu-latest' # Microsoft-hosted
# pool: { name: 'self-hosted-linux' } # self-hosted pool

Agent pools and security

Agents are organized into pools that pipelines target, letting you route jobs to the right environment (a Linux pool, a Windows pool, a private-network pool). For self-hosted agents, security matters: the agent runs your pipeline code with whatever access it has, so run it with least privilege, keep it patched, isolate it (ideally ephemeral, per-job containers so nothing persists between builds — the same isolation principle as secure CI everywhere), and never let untrusted pull requests run on an agent with access to secrets or production. Scaling self-hosted agents (via VM scale sets) handles load. The engineer balances the convenience of hosted agents against the control of self-hosted ones, securing whichever they run so the build infrastructure is not itself a weak link in the supply chain.

Agents and pools
1pipeline targets a pool
Linux / Windows / private
2hosted or self-hosted
managed vs your machines
3agent runs the job
steps execute here
4secure self-hosted
least privilege, ephemeral, patched
Hosted agents for simplicity, self-hosted for custom/private needs — and secure self-hosted agents like production build infrastructure.
A self-hosted agent with production access is a high-value target
Self-hosted agents run pipeline code with their own credentials and network access, so a compromised agent — or a malicious pull request run on one — can reach secrets and production. Run agents with least privilege, prefer ephemeral per-job containers, keep them patched, and never execute untrusted PRs on agents that hold sensitive access.