Self-hosted Linux agents (2.x)

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Important

This article provides guidance for using the 2.x version agent software with Azure DevOps Server and TFS. If you're using Azure DevOps Services, see Self-hosted Linux agents.

To run your jobs, you need at least one agent. A Linux agent can build and deploy different kinds of apps, including Java and Android apps. We support Ubuntu and Red Hat.

Before you begin:

• If your pipelines are in Azure Pipelines and a Microsoft-hosted agent meets your needs, you can skip setting up a private Linux agent.
• Otherwise, you've come to the right place to set up an agent on Linux. Continue to the next section.

Learn about agents

If you already know what an agent is and how it works, feel free to jump right in to the following sections. But if you'd like some more background about what they do and how they work, see Azure Pipelines agents.

Check prerequisites

The agent is based on .NET Core 3.1. You can run this agent on several Linux distributions. We support the following subset of .NET Core supported distributions:

• x64
  • Debian 9
  • Fedora 30, 29
  • Linux Mint 18, 17
  • openSUSE 42.3 or later
  • Oracle Linux 8, 7
  • Red Hat Enterprise Linux 8, 7, 6 (see note 1)
  • SUSE Enterprise Linux 12 SP2 or later
  • Ubuntu 20.04, 18.04, 16.04
  • Azure Linux 1.0 (see note 3)
• ARM32 (see note 2)
  • Debian 9
  • Ubuntu 18.04
• ARM64
  • Debian 9
  • Ubuntu 21.04, 20.04, 18.04

Note

Note 1: RHEL 6 requires installing the specialized rhel.6-x64 version of the agent.

Important

As of February 2023, no more agent releases support RHEL 6. For more information, see Customers using Red Hat Enterprise Linux (RHEL) 6 should upgrade the OS on Self-hosted agents.

Note

Note 2: ARM instruction set ARMv7 or above is required. Run uname -a to see your Linux distro's instruction set.

Note

Azure Linux OS distribution currently has partial support from the Azure DevOps Agent. We are providing a mechanism for detection of this OS distribution in installdependencies.sh script, but due to lack of support from the .Net Core side, we couldn't guarantee full operability of all agent functions when running on this OS distribution.

Regardless of your platform, you need to install Git 2.9.0 or higher. We strongly recommend installing the latest version of Git.

Note

The agent installer knows how to check for other dependencies. You can install those dependencies on supported Linux platforms by running ./bin/installdependencies.sh in the agent directory.

Be aware that some of these dependencies required by .NET Core are fetched from third party sites, like packages.efficios.com. Review the installdependencies.sh script and ensure any referenced third party sites are accessible from your Linux machine before running the script.

Please also make sure that all required repositories are connected to the relevant package manager used in installdependencies.sh (like apt or zypper).

For issues with dependencies installation (like 'dependency was not found in repository' or 'problem retrieving the repository index file') - you can reach out to distribution owner for further support.

Subversion

If you're building from a Subversion repo, you must install the Subversion client on the machine.

You should run agent setup manually the first time. After you get a feel for how agents work, or if you want to automate setting up many agents, consider using unattended config.

TFVC

If you are using TFVC, you also need the Oracle Java JDK 1.6 or higher. (The Oracle JRE and OpenJDK aren't sufficient for this purpose.)

TEE plugin is used for TFVC functionality. It has an EULA, which you need to accept during configuration if you plan to work with TFVC.

Since the TEE plugin is no longer maintained and contains some out-of-date Java dependencies, starting from Agent 2.198.0 it's no longer included in the agent distribution. However, the TEE plugin is downloaded during checkout task execution if you're checking out a TFVC repo. The TEE plugin is removed after the job execution.

Note

Note: You may notice your checkout task taking a long time to start working because of this download mechanism.

If the agent is running behind a proxy or a firewall, you need to ensure access to the following site: https://vstsagenttools.blob.core.windows.net/. The TEE plugin is downloaded from this address.

If you're using a self-hosted agent and facing issues with TEE downloading, you may install TEE manually:

1. Set DISABLE_TEE_PLUGIN_REMOVAL environment or pipeline variable to true. This variable prevents the agent from removing the TEE plugin after TFVC repository checkout.
2. Download TEE-CLC version 14.135.0 manually from Team Explorer Everywhere GitHub releases.
3. Extract the contents of TEE-CLC-14.135.0 folder to <agent_directory>/externals/tee.

Prepare permissions

Information security for self-hosted agents

The user configuring the agent needs pool admin permissions, but the user running the agent does not.

The folders controlled by the agent should be restricted to as few users as possible and they contain secrets that could be decrypted or exfiltrated.

The Azure Pipelines agent is a software product designed to execute code it downloads from external sources. It inherently could be a target for Remote Code Execution (RCE) attacks.

Therefore, it is important to consider the threat model surrounding each individual usage of Pipelines Agents to perform work, and decide what are the minimum permissions could be granted to the user running the agent, to the machine where the agent runs, to the users who have write access to the Pipeline definition, the git repos where the yaml is stored, or the group of users who control access to the pool for new pipelines.

It is a best practice to have the identity running the agent be different from the identity with permissions to connect the agent to the pool. The user generating the credentials (and other agent-related files) is different than the user that needs to read them. Therefore, it is safer to carefully consider access granted to the agent machine itself, and the agent folders which contain sensitive files, such as logs and artifacts.

It makes sense to grant access to the agent folder only for DevOps administrators and the user identity running the agent process. Administrators may need to investigate the file system to understand build failures or get log files to be able to report Azure DevOps failures.

Decide which user you'll use

As a one-time step, you must register the agent. Someone with permission to administer the agent queue must complete these steps. The agent will not use this person's credentials in everyday operation, but they're required to complete registration. Learn more about how agents communicate.

Authenticate with a personal access token (PAT)

1. Sign in with the user account you plan to use in your Azure DevOps organization (https://dev.azure.com/{Your_Organization}).

2. From your home page, open your user settings, and then select Personal access tokens.

   

3. Create a personal access token.

   

4. For the scope select Agent Pools (read, manage) and make sure all the other boxes are cleared. If it's a deployment group agent, for the scope select Deployment group (read, manage) and make sure all the other boxes are cleared.

   Select Show all scopes at the bottom of the Create a new personal access token window window to see the complete list of scopes.

5. Copy the token. You'll use this token when you configure the agent.

Confirm the user has permission

Make sure the user account that you're going to use has permission to register the agent.

Is the user an Azure DevOps organization owner or TFS or Azure DevOps Server administrator? Stop here, you have permission.

Otherwise:

1. Open a browser and navigate to the Agent pools tab for your Azure Pipelines organization or Azure DevOps Server or TFS server:

   1. Sign in to your organization (https://dev.azure.com/{yourorganization}).

   2. Choose Azure DevOps, Organization settings.

      

   3. Choose Agent pools.

      

2. Select the pool on the right side of the page and then click Security.

3. If the user account you're going to use is not shown, then get an administrator to add it. The administrator can be an agent pool administrator, an Azure DevOps organization owner, or a TFS or Azure DevOps Server administrator.

   If it's a deployment group agent, the administrator can be a deployment group administrator, an Azure DevOps organization owner, or a TFS or Azure DevOps Server administrator.

   You can add a user to the deployment group administrator role in the Security tab on the Deployment Groups page in Azure Pipelines.

Note

If you see a message like this: Sorry, we couldn't add the identity. Please try a different identity., you probably followed the above steps for an organization owner or TFS or Azure DevOps Server administrator. You don't need to do anything; you already have permission to administer the agent queue.

Download and configure the agent

Azure Pipelines

1. Log on to the machine using the account for which you've prepared permissions as explained above.

2. In your web browser, sign in to Azure Pipelines, and navigate to the Agent pools tab:

   1. Sign in to your organization (https://dev.azure.com/{yourorganization}).

   2. Choose Azure DevOps, Organization settings.

      

   3. Choose Agent pools.

      

3. Select the Default pool, select the Agents tab, and choose New agent.

4. On the Get the agent dialog box, click Linux.

5. On the left pane, select the specific flavor. We offer x64 or ARM for most Linux distributions.

6. On the right pane, click the Download button.

7. Follow the instructions on the page.
   

8. Unpack the agent into the directory of your choice. cd to that directory and run ./config.sh.

Server URL

Azure Pipelines: https://dev.azure.com/{your-organization}

Authentication type

Azure Pipelines

Choose PAT, and then paste the PAT token you created into the command prompt window.

Note

When using PAT as the authentication method, the PAT token is used only for the initial configuration of the agent. Learn more at Communication with Azure Pipelines or TFS.

TFS or Azure DevOps Server

Important

Make sure your server is configured to support the authentication method you want to use.

When you configure your agent to connect to TFS, you've got the following options:

• Alternate Connect to TFS or Azure DevOps Server using Basic authentication. After you select Alternate you'll be prompted for your credentials.

• Integrated Not supported on macOS or Linux.

• Negotiate (Default) Connect to TFS or Azure DevOps Server as a user other than the signed-in user via a Windows authentication scheme such as NTLM or Kerberos. After you select Negotiate you'll be prompted for credentials.

• PAT Supported only on Azure Pipelines and TFS 2017 and newer. After you choose PAT, paste the PAT token you created into the command prompt window. Use a personal access token (PAT) if your Azure DevOps Server or TFS instance and the agent machine are not in a trusted domain. PAT authentication is handled by your Azure DevOps Server or TFS instance instead of the domain controller.

Note

When using PAT as the authentication method, the PAT token is used only for the initial configuration of the agent on Azure DevOps Server and the newer versions of TFS. Learn more at Communication with Azure Pipelines or TFS.

Run interactively

For guidance on whether to run the agent in interactive mode or as a service, see Agents: Interactive vs. service.

To run the agent interactively:

1. If you have been running the agent as a service, uninstall the service.

2. Run the agent.

   ./run.sh
   

To restart the agent, press Ctrl+C and then run run.sh to restart it.

To use your agent, run a job using the agent's pool. If you didn't choose a different pool, your agent is placed in the Default pool.

Run once

For agents configured to run interactively, you can choose to have the agent accept only one job. To run in this configuration:

./run.sh --once

Agents in this mode will accept only one job and then spin down gracefully (useful for running in Docker on a service like Azure Container Instances).

Run as a systemd service

If your agent is running on these operating systems you can run the agent as a systemd service:

• Ubuntu 16 LTS or newer
• Red Hat 7.1 or newer

We provide an example ./svc.sh script for you to run and manage your agent as a systemd service. This script is generated after you configure the agent. We encourage you to review, and if needed, update the script before running it.

Some important caveats:

• If you run your agent as a service, you cannot run the agent service as root user.
• Users running SELinux have reported difficulties with the provided svc.sh script. Refer to this agent issue as a starting point. SELinux is not an officially supported configuration.

Note

If you have a different distribution, or if you prefer other approaches, you can use whatever kind of service mechanism you prefer. See Service files.

Commands

Change to the agent directory

For example, if you installed in the myagent subfolder of your home directory:

cd ~/myagent$

Install

Command:

sudo ./svc.sh install [username]

This command creates a service file that points to ./runsvc.sh. This script sets up the environment (more details below) and starts the agents host. If username parameter is not specified then the username is taken from the $SUDO_USER environment variable which is set by sudo command. This variable is always equal to the name of the user who invoked the sudo command.

Start

sudo ./svc.sh start

Status

sudo ./svc.sh status

Stop

sudo ./svc.sh stop

Uninstall

You should stop before you uninstall.

sudo ./svc.sh uninstall

Update environment variables

When you configure the service, it takes a snapshot of some useful environment variables for your current logon user such as PATH, LANG, JAVA_HOME, ANT_HOME, and MYSQL_PATH. If you need to update the variables (for example, after installing some new software):

./env.sh
sudo ./svc.sh stop
sudo ./svc.sh start

The snapshot of the environment variables is stored in .env file (PATH is stored in .path) under agent root directory, you can also change these files directly to apply environment variable changes.

Run instructions before the service starts

You can also run your own instructions and commands to run when the service starts. For example, you could set up the environment or call scripts.

1. Edit runsvc.sh.

2. Replace the following line with your instructions:

   # insert anything to setup env when running as a service
   

Service files

When you install the service, some service files are put in place.

systemd service file

A systemd service file is created:

/etc/systemd/system/vsts.agent.{tfs-name}.{agent-name}.service

For example, you have configured an agent (see above) with the name our-linux-agent. The service file is either:

• Azure Pipelines: the name of your organization. For example if you connect to https://dev.azure.com/fabrikam, then the service name would be /etc/systemd/system/vsts.agent.fabrikam.our-linux-agent.service

• TFS or Azure DevOps Server: the name of your on-premises server. For example if you connect to http://our-server:8080/tfs, then the service name would be /etc/systemd/system/vsts.agent.our-server.our-linux-agent.service

sudo ./svc.sh install generates this file from this template: ./bin/vsts.agent.service.template

.service file

sudo ./svc.sh start finds the service by reading the .service file, which contains the name of systemd service file described above.

Alternative service mechanisms

We provide the ./svc.sh script as a convenient way for you to run and manage your agent as a systemd service. But you can use whatever kind of service mechanism you prefer (for example: initd or upstart).

You can use the template described above as to facilitate generating other kinds of service files.

Use a cgroup to avoid agent failure

It's important to avoid situations in which the agent fails or become unusable because otherwise the agent can't stream pipeline logs or report pipeline status back to the server. You can mitigate the risk of this kind of problem being caused by high memory pressure by using cgroups and a lower oom_score_adj. After you've done this, Linux reclaims system memory from pipeline job processes before reclaiming memory from the agent process. Learn how to configure cgroups and OOM score.

Replace an agent

To replace an agent, follow the Download and configure the agent steps again.

When you configure an agent using the same name as an agent that already exists, you're asked if you want to replace the existing agent. If you answer Y, then make sure you remove the agent (see below) that you're replacing. Otherwise, after a few minutes of conflicts, one of the agents will shut down.

Remove and re-configure an agent

To remove the agent:

1. Stop and uninstall the service as explained above.

2. Remove the agent.

   ./config.sh remove
   

3. Enter your credentials.

After you've removed the agent, you can configure it again.

Unattended config

The agent can be set up from a script with no human intervention. You must pass --unattended and the answers to all questions.

To configure an agent, it must know the URL to your organization or collection and credentials of someone authorized to set up agents. All other responses are optional. Any command-line parameter can be specified using an environment variable instead: put its name in upper case and prepend VSTS_AGENT_INPUT_. For example, VSTS_AGENT_INPUT_PASSWORD instead of specifying --password.

Required options

• --unattended - agent setup will not prompt for information, and all settings must be provided on the command line
• --url <url> - URL of the server. For example: https://dev.azure.com/myorganization or http://my-azure-devops-server:8080/tfs
• --auth <type> - authentication type. Valid values are:
  • pat (Personal access token) - PAT is the only scheme that works with Azure DevOps Services.
  • negotiate (Kerberos or NTLM)
  • alt (Basic authentication)
  • integrated (Windows default credentials)

Authentication options

• If you chose --auth pat:
  • --token <token> - specifies your personal access token
  • PAT is the only scheme that works with Azure DevOps Services.
• If you chose --auth negotiate or --auth alt:
  • --userName <userName> - specifies a Windows username in the format domain\userName or userName@domain.com
  • --password <password> - specifies a password

Pool and agent names

• --pool <pool> - pool name for the agent to join
• --agent <agent> - agent name
• --replace - replace the agent in a pool. If another agent is listening by the same name, it will start failing with a conflict

Agent setup

• --work <workDirectory> - work directory where job data is stored. Defaults to _work under the root of the agent directory. The work directory is owned by a given agent and should not be shared between multiple agents.
• --acceptTeeEula - accept the Team Explorer Everywhere End User License Agreement (macOS and Linux only)
• --disableloguploads - don't stream or send console log output to the server. Instead, you may retrieve them from the agent host's filesystem after the job completes.

Windows-only startup

• --runAsService - configure the agent to run as a Windows service (requires administrator permission)
• --runAsAutoLogon - configure auto-logon and run the agent on startup (requires administrator permission)
• --windowsLogonAccount <account> - used with --runAsService or --runAsAutoLogon to specify the Windows user name in the format domain\userName or userName@domain.com
• --windowsLogonPassword <password> - used with --runAsService or --runAsAutoLogon to specify Windows logon password (not required for Group Managed Service Accounts and Windows built in accounts such as 'NT AUTHORITY\NETWORK SERVICE')
• --enableservicesidtypeunrestricted - used with --runAsService to configure the agent with service SID type as SERVICE_SID_TYPE_UNRESTRICTED (requires administrator permission)
• --overwriteAutoLogon - used with --runAsAutoLogon to overwrite the existing auto logon on the machine
• --noRestart - used with --runAsAutoLogon to stop the host from restarting after agent configuration completes

Troubleshooting configuring the agent with the runAsAutoLogon option

Configuring the agent with the runAsAutoLogon option runs the agent each time after restarting the machine. Perform next steps if the agent is not run after restarting the machine.

If the agent was already configured on the machine

Before reconfiguring the agent, it is necessary to remove the old agent configuration, so try to run this command from the agent folder:

.\config.cmd remove --auth 'PAT' --token '<token>'

Check if the agent was removed from your agent pool after executing the command:

<Azure DevOps organization> / <Project> / Settings / Agent pools / <Agent Pool> / Agents

Remove the agent from your agent pool manually if it was not removed by running the command.

Then try to reconfigure the agent by running this command from the agent folder:

.\config.cmd --unattended --agent '<agent-name>' --pool '<agent-pool-name>' --url '<azure-dev-ops-organization-url>' --auth 'PAT' --token '<token>' --runAsAutoLogon --windowsLogonAccount '<domain\user-name>' --windowsLogonPassword '<windows-password>'

Specify the agent name (any specific unique name) and check if this agent appeared in your agent pool after reconfiguring.

It will be much better to unpack an agent archive (which can be downloaded here) and run this command from the new unpacked agent folder.

Check if the Windows registry key is recorded and saved correctly

Run the whoami /user command to get the <sid>. Open Registry Editor and follow the path:

Computer\HKEY_USERS\<sid>\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Check if there is the VSTSAgent key. Delete this key if it exists, then close Registry Editor and configure the agent by running the .\config.cmd command (without args) from the agent folder. Before answering the question Enter Restart the machine at a later time?, open Registry Editor again and check if the VSTSAgent key has appeared. Press Enter to answer the question, and check if the VSTSAgent key remains in its place after restarting the machine.

Check if Windows registry keys work fine on your machine

Create a autorun.cmd file that contains the following line: echo "Hello from AutoRun!". Open Registry Editor and create in the path above a new key-value pair with the key AutoRun and the value

C:\windows\system32\cmd.exe /D /S /C start "AutoRun" "D:\path\to\autorun.cmd"

Restart your machine. You have an issue with Windows registry keys if you do not see a console window with the Hello from AutoRun! message.

Deployment group only

• --deploymentGroup - configure the agent as a deployment group agent
• --deploymentGroupName <name> - used with --deploymentGroup to specify the deployment group for the agent to join
• --projectName <name> - used with --deploymentGroup to set the project name
• --addDeploymentGroupTags - used with --deploymentGroup to indicate that deployment group tags should be added
• --deploymentGroupTags <tags> - used with --addDeploymentGroupTags to specify the comma separated list of tags for the deployment group agent - for example "web, db"

Environments only

• --addvirtualmachineresourcetags - used to indicate that environment resource tags should be added
• --virtualmachineresourcetags <tags> - used with --addvirtualmachineresourcetags to specify the comma separated list of tags for the environment resource agent - for example "web, db"

./config.sh --help always lists the latest required and optional responses.

Diagnostics

If you're having trouble with your self-hosted agent, you can try running diagnostics. After configuring the agent:

./run.sh --diagnostics

This will run through a diagnostic suite that may help you troubleshoot the problem. The diagnostics feature is available starting with agent version 2.165.0.

Help on other options

To learn about other options:

./config.sh --help

The help provides information on authentication alternatives and unattended configuration.

Capabilities

Your agent's capabilities are cataloged and advertised in the pool so that only the builds and releases it can handle are assigned to it. See Build and release agent capabilities.

In many cases, after you deploy an agent, you'll need to install software or utilities. Generally you should install on your agents whatever software and tools you use on your development machine.

For example, if your build includes the npm task, then the build won't run unless there's a build agent in the pool that has npm installed.

Important

Capabilities include all environment variables and the values that are set when the agent runs. If any of these values change while the agent is running, the agent must be restarted to pick up the new values. After you install new software on an agent, you must restart the agent for the new capability to show up in the pool, so that the build can run.

If you want to exclude environment variables as capabilities, you can designate them by setting an environment variable VSO_AGENT_IGNORE with a comma-delimited list of variables to ignore.

FAQ

How do I make sure I have the latest agent version?

1. Navigate to the Agent pools tab:

   1. Sign in to your organization (https://dev.azure.com/{yourorganization}).

   2. Choose Azure DevOps, Organization settings.

      

   3. Choose Agent pools.

      

2. Click the pool that contains the agent.

3. Make sure the agent is enabled.

4. Navigate to the capabilities tab:

   1. From the Agent pools tab, select the desired agent pool.

      

   2. Select Agents and choose the desired agent.

      

   3. Choose the Capabilities tab.

      

      Note

      Microsoft-hosted agents don't display system capabilities. For a list of software installed on Microsoft-hosted agents, see Use a Microsoft-hosted agent.

5. Look for the Agent.Version capability. You can check this value against the latest published agent version. See Azure Pipelines Agent and check the page for the highest version number listed.

6. Each agent automatically updates itself when it runs a task that requires a newer version of the agent. If you want to manually update some agents, right-click the pool, and select Update all agents.

How do I make sure I have the latest agent version?

1. Navigate to the Agent pools tab:

   1. Sign in to your organization (https://dev.azure.com/{yourorganization}).

   2. Choose Azure DevOps, Organization settings.

      

   3. Choose Agent pools.

      

2. Click the pool that contains the agent.

3. Make sure the agent is enabled.

4. Navigate to the capabilities tab:

   1. From the Agent pools tab, select the desired agent pool.

      

   2. Select Agents and choose the desired agent.

      

   3. Choose the Capabilities tab.

      

      Note

      Microsoft-hosted agents don't display system capabilities. For a list of software installed on Microsoft-hosted agents, see Use a Microsoft-hosted agent.

5. Look for the Agent.Version capability. You can check this value against the latest published agent version. See Azure Pipelines Agent and check the page for the highest version number listed.

6. Each agent automatically updates itself when it runs a task that requires a newer version of the agent. If you want to manually update some agents, right-click the pool, and select Update all agents.

Why is sudo needed to run the service commands?

./svc.sh uses systemctl, which requires sudo.

Source code: systemd.svc.sh.template on GitHub

I'm running a firewall and my code is in Azure Repos. What URLs does the agent need to communicate with?

If you're running an agent in a secure network behind a firewall, make sure the agent can initiate communication with the following URLs and IP addresses.

Domain URL	Description
https://{organization_name}.pkgs.visualstudio.com	Azure DevOps Packaging API for organizations using the {organization_name}.visualstudio.com domain
https://{organization_name}.visualstudio.com	For organizations using the {organization_name}.visualstudio.com domain
https://{organization_name}.vsblob.visualstudio.com	Azure DevOps Telemetry for organizations using the {organization_name}.visualstudio.com domain
https://{organization_name}.vsrm.visualstudio.com	Release Management Services for organizations using the {organization_name}.visualstudio.com domain
https://{organization_name}.vssps.visualstudio.com	Azure DevOps Platform Services for organizations using the {organization_name}.visualstudio.com domain
https://{organization_name}.vstmr.visualstudio.com	Azure DevOps Test Management Services for organizations using the {organization_name}.visualstudio.com domain
https://*.blob.core.windows.net	Azure Artifacts
https://*.dev.azure.com	For organizations using the dev.azure.com domain
https://*.vsassets.io	Azure Artifacts via CDN
https://*.vsblob.visualstudio.com	Azure DevOps Telemetry for organizations using the dev.azure.com domain
https://*.vssps.visualstudio.com	Azure DevOps Platform Services for organizations using the dev.azure.com domain
https://*.vstmr.visualstudio.com	Azure DevOps Test Management Services for organizations using the dev.azure.com domain
https://app.vssps.visualstudio.com	For organizations using the {organization_name}.visualstudio.com domain
https://dev.azure.com	For organizations using the dev.azure.com domain
https://login.microsoftonline.com	Microsoft Entra sign-in
https://management.core.windows.net	Azure Management API's
https://vstsagentpackage.azureedge.net	Agent package

To ensure your organization works with any existing firewall or IP restrictions, ensure that dev.azure.com and *dev.azure.com are open and update your allow-listed IPs to include the following IP addresses, based on your IP version. If you're currently allow-listing the 13.107.6.183 and 13.107.9.183 IP addresses, leave them in place, as you don't need to remove them.

IPv4 ranges

• 13.107.6.0/24
• 13.107.9.0/24
• 13.107.42.0/24
• 13.107.43.0/24

IPv6 ranges

• 2620:1ec:4::/48
• 2620:1ec:a92::/48
• 2620:1ec:21::/48
• 2620:1ec:22::/48

Note

For more information about allowed addresses, see Allowed address lists and network connections.

How do I run the agent with self-signed certificate?

Run the agent with self-signed certificate

How do I run the agent behind a web proxy?

Run the agent behind a web proxy

How do I restart the agent

If you are running the agent interactively, see the restart instructions in Run interactively. If you are running the agent as a systemd service, follow the steps to Stop and then Start the agent.

How do I configure the agent to bypass a web proxy and connect to Azure Pipelines?

If you want the agent to bypass your proxy and connect to Azure Pipelines directly, then you should configure your web proxy to enable the agent to access the following URLs.

For organizations using the *.visualstudio.com domain:

https://login.microsoftonline.com
https://app.vssps.visualstudio.com 
https://{organization_name}.visualstudio.com
https://{organization_name}.vsrm.visualstudio.com
https://{organization_name}.vstmr.visualstudio.com
https://{organization_name}.pkgs.visualstudio.com
https://{organization_name}.vssps.visualstudio.com

For organizations using the dev.azure.com domain:

https://dev.azure.com
https://*.dev.azure.com
https://login.microsoftonline.com
https://management.core.windows.net
https://vstsagentpackage.azureedge.net
https://vssps.dev.azure.com

To ensure your organization works with any existing firewall or IP restrictions, ensure that dev.azure.com and *dev.azure.com are open and update your allow-listed IPs to include the following IP addresses, based on your IP version. If you're currently allow-listing the 13.107.6.183 and 13.107.9.183 IP addresses, leave them in place, as you don't need to remove them.

IPv4 ranges

• 13.107.6.0/24
• 13.107.9.0/24
• 13.107.42.0/24
• 13.107.43.0/24

IPv6 ranges

• 2620:1ec:4::/48
• 2620:1ec:a92::/48
• 2620:1ec:21::/48
• 2620:1ec:22::/48

Note

This procedure enables the agent to bypass a web proxy. Your build pipeline and scripts must still handle bypassing your web proxy for each task and tool you run in your build.

For example, if you are using a NuGet task, you must configure your web proxy to support bypassing the URL for the server that hosts the NuGet feed you're using.

I'm using TFS and the URLs in the sections above don't work for me. Where can I get help?

Web site settings and security