6.3 Hosted vs. Self-Hosted Agents & Runners

6.3 Hosted vs. Self-Hosted Agents & Runners

In both Azure Pipelines and GitHub Actions, pipelines do not execute directly in the cloud management plane. Instead, orchestration engines dispatch compiled task instructions to dedicated compute engines known as Agents in Azure DevOps and Runners in GitHub Actions. Selecting, provisioning, securing, and scaling the appropriate agent infrastructure is one of the most heavily tested competency areas on the AZ-400 certification exam.

DevOps architects must balance maintenance overhead, security boundaries, build performance, cost efficiency, and network topology when selecting between Microsoft-hosted agents, static self-hosted machines, and elastic Azure Virtual Machine Scale Set (VMSS) agent pools.

---

1. Microsoft-Hosted Agents & GitHub-Hosted Runners

Microsoft-hosted agents and GitHub-hosted runners are fully managed, turnkey compute instances provisioned directly by Microsoft Azure.

Architectural Characteristics

• Ephemeral Lifecycle: Every time a pipeline job runs, the orchestration engine provisions a fresh virtual machine from a pre-built golden operating system image. As soon as the job finishes (whether it succeeds, fails, or is canceled), the entire virtual machine is destroyed. No artifacts, temporary files, downloaded packages, or environment changes persist to subsequent jobs.
• Clean-State Security: Because the VM is permanently discarded after execution, there is zero possibility of cross-build contamination, lingering malware, or accidental credential leakage between different pipeline executions or teams.
• Pre-installed Toolsets: Hosted images come pre-installed with hundreds of development tools, including .NET SDKs, Java JDKs, Python runtimes, Node.js, Ruby, Go, Docker, Azure CLI, PowerShell Core, Terraform, and package managers.
• Available Operating System Images:
  • ubuntu-latest (Ubuntu 22.04 / 24.04 LTS)
  • windows-latest (Windows Server 2022 / 2025 with Visual Studio Enterprise)
  • macos-latest (macOS 13 Ventura / macOS 14 Sonoma / macOS 15 Sequoia on Apple Silicon ARM64)

Hardware Specifications and Constraints

• Standard hosted VMs provide 2 vCPUs, 7 GB of RAM, and approximately 10 GB to 14 GB of available SSD storage space for private projects.
• Execution Time Limits:
  • Private projects: Maximum of 60 minutes per job on free tier, or 360 minutes (6 hours) with paid parallel jobs.
  • Public projects: Maximum of 360 minutes (6 hours) per job.

Fundamental Limitations

1. No Direct Private Network Connectivity: Hosted agents reside in dynamic public Azure subnets. They cannot natively reach internal on-premises databases, private Active Directory domain controllers, or Azure resources secured behind Azure Private Endpoints or Virtual Network (VNet) service endpoints.
2. Dynamic Public IP Addresses: Hosted agents do not possess static IP addresses. Their outbound IPs are drawn from broad weekly Azure Datacenter IP ranges. Whitelisting these IP ranges on corporate perimeter firewalls is impractical and violates security best practices.
3. Compute and Disk Caps: Workloads requiring heavy parallel compilations (e.g., massive C++ monoliths, game engines, or multi-gigabyte container image layers) often fail due to disk exhaustion or CPU throttling.
4. No Inter-Job Caching: Unless pipelines explicitly use caching tasks (Cache@2 or actions/cache@v4), package dependencies must be downloaded from the internet on every run.

---

2. Self-Hosted Agents & Runners

When hosted agents cannot meet security, network, or performance requirements, organizations deploy Self-Hosted Agents (Azure DevOps) or Self-Hosted Runners (GitHub Actions).

Architecture & Operating System Support

A self-hosted agent is a persistent compute instance (physical server, on-premises VMware/Hyper-V virtual machine, or cloud IaaS VM) managed entirely by the customer. The core agent application is a lightweight, cross-platform .NET application running on:

• Linux: Ubuntu, Red Hat Enterprise Linux, Debian, CentOS (configured as a systemd background service).
• Windows: Windows 10/11 or Windows Server (configured as a standard Windows Service).
• macOS: macOS 12+ running on Intel or Apple Silicon (configured as a launchd service).

Network Communication Model (Crucial Exam Concept!)

A frequent misconception on the AZ-400 exam is that self-hosted agents require inbound firewall ports to receive jobs from Azure DevOps. This is completely false.

[Corporate Private Network / VNet]                          [Public Cloud]
┌──────────────────────────────────────┐                   ┌───────────────────────────┐
│  Self-Hosted Agent VM                │                   │  Azure DevOps Services    │
│  ┌────────────────────────────────┐  │                   │  (dev.azure.com)          │
│  │ Agent Listener Process (.NET)  │  │                   │                           │
│  └───────────────┬────────────────┘  │                   │                           │
│                  │                   │                   │                           │
│                  │ Outbound HTTPS    │                   │                           │
│                  │ Long-Polling      │                   │                           │
│                  │ (Port 443 ONLY)   │                   │                           │
│                  ▼                   │                   │                           │
│          [Corporate Firewall] ───────┼──HTTPS (TCP 443)──► [Job Dispatch Message Bus]│
│          (NO INBOUND PORTS OPEN)     │                   │                           │
└──────────────────────────────────────┘                   └───────────────────────────┘

• Pure Outbound Polling: The self-hosted agent listener initiates an outbound HTTPS connection over TCP port 443 to Azure DevOps (https://dev.azure.com) or GitHub (https://api.github.com).
• Long Polling Message Bus: The agent polls an internal HTTP-based message queue. When a pipeline job matches the agent pool and demands, Azure DevOps returns the job details in the HTTP response body.
• Zero Inbound Ports: Perimeter firewalls require no inbound openings (no port 80, 443, SSH, or RDP). The agent can reside safely behind corporate NAT and Web Application Firewalls.
• Outbound Streaming: Build logs, telemetry, and test results are streamed outbound over the same HTTPS channel.

Corporate Proxy and Custom SSL CA Configuration

In enterprise networks where all outbound internet traffic must route through an inspecting forward proxy:

• Proxy Settings: Configured during agent setup or via the .proxy file in the agent root directory:

  http://proxy.corp.contoso.com:8080
  

  If authentication is required: http://user:password@proxy.corp.contoso.com:8080.
• Bypassing Proxy: Configured in .proxybypass for intranet addresses.
• Custom Certificate Authority (CA): When SSL inspection proxies terminate TLS traffic, the agent must trust the corporate root certificate. The certificate is placed in the OS trust store, and the agent is started with the --sslcacert parameter pointing to the PEM bundle, or configured via the NODE_EXTRA_CA_CERTS environment variable.

Operational Burdens: The "Dirty State" Problem

Unlike hosted agents, self-hosted agents are persistent. If a build script leaves temporary files, alters registry keys, installs packages globally, or crashes mid-execution, subsequent jobs inherit that modified environment. DevOps engineers must explicitly configure workspace cleaning (checkout: self, clean: true) or schedule maintenance tasks to prevent disk saturation and build non-determinism.

---

3. Cost, Licensing, Connectivity and Maintainability

The blueprint asks you to design agent infrastructure against four named criteria, so score every option on all four rather than on speed alone.

Two rules resolve most scenario questions:

1. Any requirement to reach a private resource forces self-hosted (or a VMSS pool inside the VNet). Firewall allowlisting cannot fix a Microsoft-hosted agent, because the agent initiates outbound long-polling to Azure DevOps and never accepts inbound connections.
2. Any requirement for a clean, guaranteed-identical workspace favours Microsoft-hosted or VMSS with re-imaging. A long-lived self-hosted agent accumulates cached packages, leftover environment variables and stale global tool installs, which is the classic "works on agent 3 but fails on agent 7" defect.

Free-tier and grant mechanics also matter: public projects receive 10 free Microsoft-hosted parallel jobs with no monthly minute cap, while private projects start with one grant-based parallel job. Buying additional self-hosted parallel jobs is far cheaper than Microsoft-hosted ones, which is why large enterprises usually mix a small hosted pool for open-source work with a large self-hosted or VMSS pool for product builds.