L10. Runner and Agent Infrastructure: GitHub-Hosted vs Self-Hosted

Hosted Agents vs Self-Hosted Agents

Every pipeline job runs on an agent (Azure Pipelines) or runner (GitHub Actions). You have two fundamental choices. Microsoft-hosted agents and GitHub-hosted runners are fully managed by Microsoft and GitHub respectively. A fresh VM is provisioned for each job, the job runs, and the VM is discarded. Zero maintenance overhead. However:

• They cannot reach private/on-premises networks
• Job time limits apply (GitHub Actions: 6 hours per job)
• Concurrency is limited by your plan (free tier: 20 concurrent jobs)

Self-hosted agents and runners are machines you manage and register against the pipeline service. A self-hosted agent installed in your corporate network can reach internal databases, on-prem services, and private APIs. You can pre-install licensed software. At the cost of your team owning patching, security hardening, and lifecycle management.

Decision Factors

Choosing between hosted and self-hosted depends on several criteria:

High-volume CI/CD operations often use self-hosted agents to reduce per-job costs and gain network access. Small teams or projects with modest needs use hosted agents for zero maintenance.

Scale Sets: Elastic Self-Hosted Pools

Azure DevOps scale set agents back a self-hosted agent pool with a VM scale set. The scale set automatically adds VMs when jobs queue up and removes them when idle, combining the private network reach of self-hosted agents with the elastic scaling of hosted agents.

This avoids the trade-off: you get self-hosted connectivity and tool customization, plus automatic scaling without managing individual VMs.

Ephemeral vs Persistent Self-Hosted Agents

Ephemeral agents are torn down and rebuilt from scratch after each job, ensuring every job starts clean. No cache, no state leaking between jobs. Persistent agents are reused across jobs. They start faster (no rebuild overhead), but state from one job could leak into another (cached credentials, leftover files, malicious code installed by a previous job).

For public repositories, Microsoft and GitHub recommend ephemeral agents or restricting self-hosted runners to private repositories only.

Security Risk: Self-Hosted on Public Repos

A self-hosted runner or agent on a public repository is a significant security risk. A malicious external contributor can create a pull request whose workflow runs arbitrary code on your self-hosted infrastructure, potentially stealing credentials, planting backdoors, or exfiltrating data.

Mitigations include:

• Restrict self-hosted runners to private repositories only
• Require approval for workflow runs from outside contributors
• Run ephemeral agents that rebuild after each job
• Monitor agent resource usage for suspicious activity

Exam tip: The AZ-400 exam tests the decision factors (cost, network access, maintenance) and the self-hosted-on-public-repo security risk, which is the most heavily tested agent scenario.