Azure Developer CLI extension framework is now generally available, enabling teams to create reusable extensions that automate project setup, deployment, and validation steps. This GA release lets organizations codify internal standards—like approved architectures or security checks—into azd workflows that developers can invoke with a single command. By extending azd, teams reduce manual steps and improve consistency across Azure application development.
What the Extension Framework Enables
The azd extension framework allows developers to create reusable packages that encapsulate multi-step Azure development workflows. These extensions can automate tasks such as provisioning infrastructure using approved templates, connecting to internal service catalogs, or running pre-deployment security and compliance checks. By packaging these steps into an extension, teams ensure consistent execution across projects and reduce reliance on fragmented documentation or manual processes.
Extensions are built using familiar azd concepts: they define hooks for lifecycle events like init, provision, deploy, and validate. Developers can write extension logic in scripts or code that runs at these stages, integrating with existing tools such as GitHub Actions, Azure Policy, or internal service brokers. The framework supports versioning and distribution via package feeds, making it easy to update and share extensions across teams.
Because extensions run within the azd context, they inherit access to Azure credentials, environment context, and service bindings. This means an extension can, for example, validate a Bicep template against organizational policies during the validate phase, or prompt for approval before deploying to a production subscription. The tight integration ensures that custom logic works seamlessly with standard azd commands like 'azd up' or 'azd pipeline'.
Building and Distributing Extensions
Creating an azd extension starts with defining an extension.json manifest that specifies the extension’s name, version, and the lifecycle hooks it implements. Developers then add implementation files—such as shell scripts, PowerShell, or Node.js code—that execute at the defined stages. The framework includes scaffolding tools to help generate the initial structure, reducing the barrier to entry for teams adopting the extension model.
Once built, extensions can be published to any package feed compatible with NuGet, including Azure Artifacts, GitHub Packages, or a private registry. Consumers install them using 'azd extension add', specifying the feed and package name. Updates are managed through standard version semantics, allowing teams to roll out improvements or patch security issues without disrupting developer workflows.
The extension framework supports isolation and dependency management, ensuring that one extension’s tools or scripts do not interfere with another’s. This allows organizations to maintain a library of specialized extensions—for example, one for data-intensive apps using Cosmos DB, another for web apps with static frontends—while avoiding conflicts. Auditing and logging hooks are also available to track extension usage for compliance or optimization.
Practical Impact on Developer Experience
With the extension framework GA, platform teams can shift from documenting procedural steps to delivering executable workflows. Instead of asking developers to follow a wiki page to set up a new service, they can provide an azd extension that provisions the correct resources, applies tags, and configures monitoring—all in one command. This reduces onboarding friction and decreases the likelihood of configuration drift.
The model also encourages inner-sourcing: teams that build useful extensions can share them across the organization, fostering reuse and consistency. For example, a security team might publish an extension that runs container image scans and policy checks during deployment, while a platform team offers one that sets up observability with Azure Monitor and Log Analytics. Over time, this creates a catalog of trusted, standardized workflows.
Because extensions are versioned and discoverable, they support long-term platform evolution. As best practices change—such as moving from VMs to container apps or adopting new identity patterns—platform teams can update the extension and notify consumers via semantic versioning. Developers continue to use familiar azd commands, but now benefit from automated, up-to-date implementation of organizational standards.
What to do next
To get started, review the azd extension framework documentation and scaffold your first extension using the built-in templates. Identify a repetitive, multi-step process in your team’s Azure workflow—such as environment setup or pre-deployment validation—and codify it as an extension. Share it via your internal package feed and gather feedback to refine its usability and coverage.
Source: Azure Developer CLI extension framework is GA: build dev workflows for apps using Azure (Azure).
