Beyond tool availability, what are the actual trade-offs of self-hosted versus Microsoft-hosted Azure Pipelines agents — cost, control, security, and startup latency?

Microsoft-hosted agents win on startup simplicity and zero infrastructure management but cost more per minute at scale and offer less control over the environment; self-hosted agents are cheaper at high, sustained usage and give full control over hardware/network/tooling, at the cost of owning provisioning, patching, and scaling that infrastructure yourselves, plus taking on responsibility for the security of a persistent build environment.

Cost: Microsoft-hosted agents are billed per minute of usage (with a free tier), which is attractive for low or spiky usage but scales linearly with build volume — a team running thousands of build-minutes daily can find self-hosted agents (paying for owned or reserved compute instead) meaningfully cheaper at that volume, since the marginal cost of an additional build on already-provisioned self-hosted capacity is much lower.

Control: self-hosted agents run on infrastructure you fully control — specific hardware (including GPUs or specialized instances Microsoft-hosted images don't offer), custom networking (access to internal resources behind a firewall/VPN that a Microsoft-hosted agent, running on Microsoft's infrastructure, simply can't reach), and full control over exactly what's installed and at what version. Microsoft-hosted agents are locked to whatever the hosted image provides, updated on Microsoft's schedule, not yours.

Security: this cuts both ways. Microsoft-hosted agents are ephemeral — a fresh, clean VM per job, discarded afterward, meaning no persistent state or credentials lingering between builds, and no self-managed attack surface. Self-hosted agents, being persistent, carry the operational burden of keeping that environment patched and secured — a compromised self-hosted agent can potentially persist across builds in a way an ephemeral Microsoft-hosted agent structurally can't. Conversely, self-hosted agents can be placed inside a network perimeter Microsoft-hosted agents can never access, which is sometimes a security requirement in itself (builds that must never leave a private network).

Startup latency: Microsoft-hosted agents have queueing and VM-startup overhead per job (provisioning a fresh VM takes real time before the job even begins); self-hosted agents, if kept warm/idle and ready, can pick up a job with much lower startup latency, which matters for teams optimizing for fast CI feedback loops at high build frequency.

The practical decision: Microsoft-hosted is the reasonable default for most teams (simplicity, no infrastructure to own, ephemeral security posture), and self-hosted becomes worth the added operational responsibility specifically when cost at scale, the need for network-restricted access, specialized hardware, or startup-latency requirements outweigh that simplicity.

• Microsoft-hosted agents minimize operational overhead and offer ephemeral-VM security by default, at a per-minute cost that scales with usage.
• Self-hosted agents can be cheaper at high sustained volume and offer full control over hardware, networking, and tooling, at the cost of owning provisioning and security.
• Security trade-offs cut both ways: Microsoft-hosted is ephemeral and clean by default; self-hosted can reach network-restricted resources Microsoft-hosted structurally cannot.
• Self-hosted agents kept warm avoid Microsoft-hosted's per-job VM-provisioning latency, mattering for high-frequency CI feedback loops.

• Azure Pipelines: Microsoft-hosted agents
• Azure Pipelines: Self-hosted agents
• Azure DevOps: Pricing