Self-hosted agent
What it is
A self-hosted agent is pipeline execution software that you install and register on a machine you control, such as an on-premises machine or VM. It joins an agent pool and runs jobs there instead of on Microsoft-hosted compute.
Why it exists
Hosted agents are convenient and maintained for you, but may not meet a private-network, custom-tool, or compliance requirement. Self-hosted agents let you control the runtime while using the same pipeline engine. They also create an operational and security boundary you must maintain.
Key ideas
- Azure Pipelines: install, configure, register, and run the agent. A PAT is one registration option; a service principal or device code flow may also be supported. Registration credentials are not a reason to put a long-lived PAT in pipeline YAML.
- The agent is registered in one organization-level pool; projects and pipelines are then authorized to use that pool. A job selects it with
pool: <poolName>. - Capabilities/
demands:— declare tools (e.g.java,dotnet) so jobs request capable agents. - GitHub Actions: self-hosted runners added at repo/org/enterprise level, chosen with
runs-on: [self-hosted, linux, x64]. - Agents are single-job at a time (one agent = one concurrent job) unless you register multiples.
Exam notes
- Plan secure outbound connectivity to the Azure DevOps or GitHub service and apply the provider’s current network guidance. Do not expose a broad inbound management path merely to run builds.
- If using a PAT for Azure Pipelines registration, give it only the documented agent-pool scope and protect it. Prefer another supported registration method when it better fits the environment.
- Demand/capability matching is a classic exam item.
- Managed agents simplify upgrades; self-hosted means you patch and maintain the machine.
Related
agent-pool · azure-pipelines · github-actions
📘 Source: Microsoft Learn — Azure Pipelines agents and self-hosted agent authentication options, checked 2026-09-17.