> For the complete documentation index, see [llms.txt](https://docs.terrakube.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.terrakube.io/user-guide/vcs-providers/azure-devops.md).

# Azure DevOps

{% hint style="danger" %}
OAuth apps are deprecated in Azure DevOps.[https://devblogs.microsoft.com/devops/no-new-azure-devops-oauth-apps](https://devblogs.microsoft.com/devops/no-new-azure-devops-oauth-apps/) as an alternative for now a managed identity can be used but the setup is only available using the API, for more information please check:

<https://github.com/terrakube-io/terrakube/pull/2101>
{% endhint %}

For using repositories from Azure Devops with Terrakube workspaces and modules you will need to follow these steps:

{% hint style="info" %}
**Manage VCS Providers** permission is required to perform this action, please check [Team Management](/user-guide/organizations/team-management.md) for more info.
{% endhint %}

Navigate to the desired organization and click the **Settings** button, then on the left menu select **VCS Providers**

<figure><img src="/files/a9QAbsWKRTZzMR0mzvO0" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
If you prefer, you can add a new VCS Provider directly from the [Create workspace](/user-guide/workspaces/creating-workspaces.md) or Create Module screen.
{% endhint %}

Click the **Azure Devops** button

<figure><img src="/files/HI8SlCIUDU8ZpsZNrE8m" alt=""><figcaption></figcaption></figure>

In the next screen click the link to [register a new OAuth Application](https://aex.dev.azure.com/app/register?mkt=en-US) in Azure Devops

<figure><img src="/files/14mDHowrNKAn9aLncj5L" alt=""><figcaption></figcaption></figure>

In the Azure Devops page, complete the required fields and click **Create application**

<table><thead><tr><th width="354">Field</th><th>Description</th></tr></thead><tbody><tr><td>Company Name</td><td>Your company name.</td></tr><tr><td>Application name</td><td>The name of your application or you can use the Organization name</td></tr><tr><td>Application website</td><td>Your application or website url</td></tr><tr><td>Callback URL</td><td>Copy the Callback URL from the Terrakube URL</td></tr><tr><td>Authorized scopes (checkboxes)</td><td>Only the following should be checked: Code (read) Code (status)</td></tr></tbody></table>

{% hint style="info" %}
You can complete the fields using the information suggested by terrakube in the VCS provider screen
{% endhint %}

<figure><img src="/files/LmMJfxtBByD1ySSgzF2b" alt=""><figcaption></figcaption></figure>

In the next screen, copy the **App ID** and **Client Secret**

<figure><img src="/files/Dl197Vfvf2sQQ5UyFn3I" alt=""><figcaption></figcaption></figure>

Go back to Terrakube to enter the information you copied from the previous step. Then, click the **Connect and Continue** button.

<figure><img src="/files/UOwoV76iVbc8aIxLwEiT" alt=""><figcaption></figcaption></figure>

You will see an Azure Devops window, click the **Accept** button to complete the connection

<figure><img src="/files/kGBlshoVl4gXhimacZp6" alt=""><figcaption></figcaption></figure>

Finally, if the connection was established successfully, you will be redirected to the VCS provider’s page in your organization. You should see the connection status with the date and the user that created the connection.

<figure><img src="/files/cEIug1OhRz9Ix7XzBrk4" alt=""><figcaption></figcaption></figure>

And now, you will be able to use the connection in your workspaces and modules:

<figure><img src="/files/m6MR7Nfx8wS8DJpW8U67" alt=""><figcaption></figcaption></figure>

### Webhooks

Azure DevOps (`dev.azure.com` and Azure DevOps Server) supports triggering workspace runs from repository activity, using either connection type (OAuth/Personal Access Token, or Service Principal/Managed Identity). There are two ways to detect changes:

**Inbound service hooks (default).** When a workspace with an Azure DevOps VCS is saved, Terrakube creates an Azure DevOps [service hook](https://learn.microsoft.com/azure/devops/service-hooks/overview) subscription that posts to the Terrakube webhook endpoint. Each delivery is authenticated with a per-webhook token, and commit status is reported back to Azure DevOps as the run progresses. Supported events:

| Terrakube event      | Azure DevOps `eventType`                             |
| -------------------- | ---------------------------------------------------- |
| Push                 | `git.push`                                           |
| Pull Request         | `git.pullrequest.created`, `git.pullrequest.updated` |
| Pull Request comment | `ms.vss-code.git-pullrequest-comment-event`          |

Because service hooks are delivered from the Azure DevOps cloud, the Terrakube webhook endpoint must be reachable from the public internet, and the connection needs **Edit Subscriptions** permission to create them.

{% hint style="warning" %}
The [PR comment plan/apply workflow](/user-guide/workspaces/webhooks.md#posting-plan-and-apply-results-on-pull-requests) (Post Plan on PR / Allow Apply via PR Comment, `terrakube plan` / `terrakube apply` comments) is currently only available for GitHub, GitLab, and Bitbucket. Azure DevOps pull request events can trigger jobs, but results aren't posted back as PR comments yet.
{% endhint %}

**Outbound commit polling (opt-in).** If Terrakube runs on a private network that the Azure DevOps cloud can't reach, inbound service hooks will silently fail. Polling reverses the direction: Terrakube periodically makes an outbound call to fetch the tip commit of each Azure DevOps workspace branch and starts a run when it changes, reusing the same credentials already used for cloning — no inbound network exposure required. Polling is disabled by default; enable it with these API environment variables:

| Environment variable             | Default | Description                                               |
| -------------------------------- | ------- | --------------------------------------------------------- |
| `AzureDevOpsPollingEnabled`      | `false` | Enable outbound commit polling.                           |
| `AzureDevOpsPollingInterval`     | `15000` | Milliseconds between polls of each workspace branch.      |
| `AzureDevOpsPollingInitialDelay` | `10000` | Milliseconds to wait after startup before the first poll. |

The first observed commit for a branch only records a baseline and does not trigger a run. Branch and file-path filters on the workspace webhook are applied the same way as for inbound pushes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.terrakube.io/user-guide/vcs-providers/azure-devops.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.