# Azure Developer CLI (azd): a workflow CLI for Azure apps, and what it does not do

> azd wraps Azure provisioning and deployment behind four verbs (code, build, deploy, monitor) and a template system. It suits teams that want Azure's recommended defaults without writing Bicep by hand, and frustrates anyone who needs fine-grained control over infrastructure.

**Azure/azure-dev** — A developer CLI for working with Azure resources to build and deploy AI applications. Commands map to key workflow stages: code, build, deploy, and monitor.

- Repository: https://github.com/Azure/azure-dev
- Website: https://aka.ms/azd
- Stars: 570 · Forks: 366
- Language: Go
- License: MIT
- Published: 2026-08-27 · Updated: 2026-08-27 · Language: en
- Canonical page: https://hysenlabs.com/projects/azure-azure-dev

## What azd is for, and who it is not for

azd is a command-line tool that takes an application from a local repository to running Azure resources. The README frames the workflow as four stages: code, build, deploy, monitor. Each stage is a command group rather than a script you maintain yourself.

The audience is narrow and specific. It is for developers who are building on Azure and do not want to hand-author the resource definitions that sit underneath their application. The README describes the templates as "opinionated templates that follow Azure development standards," which is the honest description of the trade: you get Azure's recommended practices applied for you, and you give up some control over how those practices are expressed.

It is not for teams whose infrastructure already lives in a Terraform module set or a hand-maintained Bicep tree that other systems depend on. azd's value comes from owning the provisioning step. If something else already owns it, azd becomes a second workflow layered on top of the first, and the two will disagree about state.

The project is written in Go, licensed under MIT, and lives at github.com/Azure/azure-dev. The most recent push to the default branch was on 2026-08-27, and the most recent stable CLI release listed is azure-dev-cli_1.32.0 from 2026-08-26. That is recent enough that the repository is not dormant, though the README does not publish a support window or a release cadence commitment.

## How the template and provisioning flow actually works

The mechanism the README exposes is template-driven. You start from a template in the gallery linked as azure.github.io/awesome-azd, and azd uses that template to know what to build, what to provision, and where to deploy it. The four command stages map onto that: the code stage gets a working tree, build produces the artifact, deploy pushes both infrastructure and application, monitor reports on what is running.

What the README does not document is the internal architecture: there is no description of how azd reconciles template state with live Azure state, what happens when a resource is modified outside azd, or how it detects drift. The repository layout shows a cli/ directory, an ext/ directory for extensions, a schemas/ directory, and a docs/ directory, which tells you the project is structured around a core CLI plus separately versioned extensions. The extension directories matter because the AI-related capability ships that way rather than in the core binary: the recent releases include azd-ext-azure-ai-projects_1.0.0-beta.8 and azd-ext-azure-ai-agents_1.0.0-beta.13, both dated 2026-08-27, while the core CLI is at 1.32.0. Two different version lines, two different stability levels.

That split is worth noting for anyone planning adoption. The core CLI is at a 1.x version. The AI extensions are at 1.0.0-beta. If your use case is an AI application on Azure, the part you most need is the part still labelled beta.

## Installing azd on Windows, macOS and Linux

The README gives package-manager paths for all three platforms. On Windows, winget is listed as the recommended route:

```powershell
winget install microsoft.azd
```

After it completes, `azd version` should print the installed CLI version. Chocolatey is offered as an alternative with `choco install azd`, and there is a PowerShell install script for environments where neither package manager is available.

On macOS the README uses a Homebrew cask from Azure's own tap, and it requires an explicit trust step first:

```bash
brew trust azure/azd && brew install --cask azure/azd/azd
```

The README explains why: Homebrew will not install casks from third-party sources until that source is trusted. It also warns that if you are upgrading from a non-Homebrew installation, you should remove the existing azd binary first, otherwise you can end up with two binaries on PATH.

On Linux the install is a single script:

```bash
curl -fsSL https://aka.ms/install-azd.sh | bash
```

The same script is documented for uninstalling on Linux and macOS. Shell completion for bash, zsh, fish and powershell is enabled through `azd completion <shell> --help`.

One detail that belongs in the install section rather than buried: azd collects usage data and sends it to Microsoft by default. The README gives the opt-out as an environment variable:

```bash
export AZURE_DEV_COLLECT_TELEMETRY=no
```

If you are installing into a regulated environment, set that before first run rather than after.

## The telemetry default and the infrastructure-ownership trade

Two limitations are visible directly in the README, and both are the kind that show up late if you do not plan for them.

The first is telemetry. azd sends usage data to Microsoft unless you set AZURE_DEV_COLLECT_TELEMETRY=no. The README states this plainly and links the Microsoft Privacy Statement, so it is not hidden. But the default is on, which means an unconfigured CI runner or a developer laptop will report usage the moment azd runs. If your organisation requires opt-in rather than opt-out for tooling telemetry, the environment variable has to be part of your provisioning of developer machines, not an afterthought.

The second is the ownership question. The README describes azd as having "Azure recommended practices built-in" via opinionated templates. That is a real benefit for a greenfield project and a real constraint for an existing one. Nothing in the README documents how to take an existing, hand-managed Azure environment and bring it under azd, nor how azd behaves when the deployed resources no longer match what the template expects. The README does not document rollback either: the uninstall instructions remove the CLI, and there is no documented procedure for reverting a deployment azd performed.

That gap is the strongest argument for treating azd as a tool you adopt at the start of a project rather than retrofit onto an established one.

## How azd differs from Terraform and from the Azure CLI

The natural comparison is Terraform, and the difference is in who defines the desired state. With Terraform you write the resource declarations yourself and the tool reconciles them against the provider's API. With azd, the template supplies the declarations and azd drives the workflow around them. You are trading authorship for convention. Terraform's model handles an existing estate gracefully because you can import resources into state; azd's model, as documented, starts from a template and does not describe an import path.

The other comparison is the Azure CLI, `az`. The Azure CLI is a resource-level command surface: you call it with the specific operation you want. azd is a workflow-level surface: you call it with the stage you are in. They are not competitors so much as different altitudes, and the README does not claim azd replaces `az`. If your work is mostly one-off resource operations, `az` is the right tool and azd adds a layer you will not use. If your work is repeatedly taking an application from repository to running service, azd's four-stage model is the thing that saves the repetition.

A third option worth naming is the VS Code extension linked from the README, published as ms-azuretools.azure-dev. It is the same workflow behind a graphical surface. Neither the README nor the extension listing describes feature parity between the two, so if you need a specific command, check the CLI first.

## Maintenance, licence and what upgrading costs you

azd is MIT licensed. That is permissive: you can use it commercially, modify it, and redistribute it, provided the copyright notice and permission notice are preserved. The README also carries a trademark section stating that Microsoft trademarks and logos in the project may only be used under Microsoft's Trademark & Brand Guidelines, and that third-party trademarks follow their own policies. So the code is permissive while the branding is not, which is the usual arrangement and worth knowing if you plan to fork and ship under your own name.

On maintenance: the last push to the default branch was on 2026-08-27, and the current stable CLI release is azure-dev-cli_1.32.0. The repository is not archived. The README does not state a support policy, a deprecation policy, or an end-of-life schedule for any version line, so upgrade cost has to be inferred from the release structure rather than from a documented promise. The extension versioning is the part to watch: azure-ai-agents and azure-ai-projects are both on 1.0.0-beta releases, and beta version lines in most projects do not carry compatibility guarantees across minor bumps. If you build against those extensions, budget for reading release notes before each upgrade. If you only use the core CLI at 1.32.0, the surface is smaller and the upgrade risk correspondingly lower.

The repository also documents a Contributor License Agreement requirement for contributions, with a bot handling it on pull requests, and points template authors at separate standardisation guidelines. That matters only if you intend to contribute back rather than consume.

## Conclusion

Adopt azd if your team is building on Azure and wants opinionated templates to carry the provisioning and deployment work, and if you are willing to let the tool own the infrastructure definition. Do not adopt it if your infrastructure is already defined in Terraform or hand-written Bicep that you intend to keep as the source of truth, because azd's workflow assumes it drives the deployment. Before committing, verify three things: that the template you intend to start from exists in the template gallery, that azd's telemetry default is acceptable or that you set AZURE_DEV_COLLECT_TELEMETRY=no, and that the extension you need (for example azure-ai-agents or azure-ai-projects) is at a version you are comfortable shipping, since both were still at 1.0.0-beta in the August 2026 releases.

## FAQ

### What is the Azure Developer CLI (azd)?

It is a developer-centric command-line tool for building, deploying and operating Azure applications, written in Go and licensed under MIT. Its commands map to four workflow stages: code, build, deploy and monitor, and it works from opinionated templates that apply Azure development standards.

### Is azd free to use?

The project is licensed under MIT, which permits commercial and private use. The README does not describe a paid tier for the CLI itself, though the Azure resources you deploy with it are billed by Azure separately.

### Does azd work with VS Code?

The README links a VS Code extension published on the Marketplace as ms-azuretools.azure-dev. The README does not describe how its feature set compares with the CLI's, so check the CLI for a specific command if the extension does not expose it.

## Sources

- [Official documentation](https://aka.ms/azd)
- [Official README](https://github.com/Azure/azure-dev#readme)
- [Project repository](https://github.com/Azure/azure-dev)
- [Release notes](https://github.com/Azure/azure-dev/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/azure-azure-dev