When Should You Use a Self-hosted Agent Instead of a Microsoft-hosted Agent?

1. What is it?

In Azure Pipelines, you should use a self-hosted agent when your CI/CD process requires greater control over the execution environment, access to private networks, custom software, or specialized infrastructure.

A self-hosted agent runs on a machine managed by your organization, whereas a Microsoft-hosted agent runs on infrastructure managed by Microsoft.

Simple rule:

• Microsoft-hosted agent: Best for standard builds, automated testing, and deployments to accessible cloud services.

• Self-hosted agent: Best for internal deployments, custom build environments, and specialized infrastructure requirements.

2. When Should You Use a Self-hosted Agent?

Scenario 1: Deploying to Internal Servers (Most Important)

Suppose your company has three environments:

• SIT Server – 192.168.1.10

• UAT Server – 192.168.1.20

• Production Server – 192.168.1.30

These are example private IP addresses and cannot normally be accessed directly from the public internet.

Solution: Install a self-hosted agent inside the company's network.

Azure DevOps Pipeline
         |
         v
Self-hosted Agent
(Company Network)
         |
         |----> SIT Server
         |
         |----> UAT Server
         |
         |----> Production Server

The agent can deploy applications to these servers when the necessary network access, permissions, and deployment tools are configured.

Real example: Deploying an ASP.NET Core Web API application to internal IIS servers.

Scenario 2: Custom Software Requirements

Suppose your application requires:

• A specific .NET SDK version.

• A legacy .NET Framework SDK.

• A custom database deployment tool.

• Third-party build software.

• Licensed enterprise development tools.

You can install and configure these tools permanently on a self-hosted agent.

Microsoft-hosted agents provide many common tools, but additional software may need to be installed during each job.

Scenario 3: Faster Builds Through Persistent Caching

Self-hosted agents can retain downloaded dependencies and build caches between jobs.

For example:

First Build
   |
   |-- Download NuGet Packages
   |-- Build Application
   |
   v
Packages Cached

Second Build
   |
   |-- Reuse Cached Packages
   |-- Build Application

This can reduce build times, particularly for large enterprise solutions.

However, self-hosted agents are not automatically faster. Performance depends on hardware, caching, configuration, and workload.

Scenario 4: Security and Compliance Requirements

Some organizations require:

• Builds to run on company-controlled infrastructure.

• Restricted access to internal databases.

• Private network connectivity.

• Controlled software installation.

• Specific security and auditing policies.

A self-hosted agent may be appropriate when these requirements cannot be satisfied by Microsoft-hosted agents.

Important: Self-hosting does not automatically guarantee better security. Your organization must manage updates, credentials, isolation, and agent permissions.

Scenario 5: Specialized Hardware

A project may require:

• High-memory build servers.

• GPU-enabled machines.

• Specialized processors.

• Hardware-connected testing equipment.

Self-hosted agents allow organizations to select hardware appropriate for these workloads.

3. Microsoft-hosted vs Self-hosted – Scenario Comparison

These are typical recommendations, not absolute restrictions. Microsoft-hosted agents can also access private resources when appropriate secure connectivity is configured.

4. YAML Configuration

Microsoft-hosted Agent

pool:
  vmImage: 'windows-latest'

steps:
- script: dotnet build
  displayName: 'Build Application'

Azure DevOps provides the agent.

Self-hosted Agent

pool:
  name: 'MyCompanyPool'

steps:
- script: dotnet build
  displayName: 'Build Application'

Azure DevOps selects an eligible available agent from MyCompanyPool.

5. Real-time Project Scenario

Suppose your organization develops an ASP.NET Core Web API with SQL Server.

You have an Azure DevOps pipeline and three internal IIS environments.

Here, using both types of agents provides a practical separation between application builds and internal deployments.

6. Important Interview Questions

Q1. Why would you choose a self-hosted agent?

When a pipeline requires private network access, custom tools, specialized hardware, or greater control over its execution environment.

Q2. Is a self-hosted agent always faster?

No. It can improve performance through persistent caches and dedicated hardware, but performance depends on the infrastructure and workload.

Q3. Can a self-hosted agent deploy to multiple environments?

Yes. A self-hosted agent can deploy to SIT, UAT, and Production if it has the necessary connectivity and permissions. Separate pools or agents may be preferable for security isolation.

Q4. Can we use Microsoft-hosted agents for CI and self-hosted agents for CD?

Yes. This is a common hybrid approach in enterprise applications.

7. Interview-ready Answer

We use a self-hosted agent instead of a Microsoft-hosted agent when our pipeline requires access to internal company servers, custom software, specialized hardware, or greater control over the execution environment.

For example, in an ASP.NET Core application, we may use Microsoft-hosted agents to build the application and execute unit tests.

However, if we need to deploy the application to internal IIS servers in SIT, UAT, and Production environments, we can use a self-hosted agent installed within the company's network.

Self-hosted agents can also improve build performance by retaining caches and preinstalled dependencies, but they require infrastructure maintenance and security management.

Key interview point: Use Microsoft-hosted agents by default for standard workloads. Choose self-hosted agents when specific network, software, hardware, security, or performance requirements justify managing your own infrastructure.