The Azure Developer CLI’s extension framework is now generally available. If you haven’t followed the azd project, extensions are the plugin system that lets teams add their own commands, automation, and service integrations to the CLI without forking it or wrapping it in scripts. The GA applies to the framework itself: the parts of azd that build, distribute, install, and run extensions.
One caveat the team states plainly, and it’s the right framing: GA of the framework doesn’t make every extension generally available. Extension owners version and release their features independently. The Foundry extensions, for example, keep their preview status, and the development and nightly feeds remain for experimental builds.
What the framework gives you
An azd extension can introduce new commands or subcommands, from a top-level azd demo to nested namespaces like azd ai setup. Extensions are isolated modules, so you install only what a project needs and remove them cleanly. They can prompt for input, run multi-step workflows, listen for CLI events, and call external APIs, which is how the Microsoft Foundry team built their command-line experience on top of the platform.
Distribution works like a package manager. Extensions come from source registries, and azd ships with an official registry preconfigured. Teams can add private registries for internal extensions, and there’s an opt-in dev registry for experimental builds. For GA, the team stabilized the extension interfaces, broadened lifecycle and provider integration, and added project-level extension requirements with version constraints, so a repo can declare which extensions it needs and at which versions instead of relying on tribal knowledge.
What’s new in the August releases
The August azd releases (1.30.0 through 1.32.0) carried the GA work plus some additions worth knowing:
- Extension bundles install directly from HTTPS URLs with
azd extension install, no registry registration required first. - Official-source extensions can report named usage events through the new TelemetryService.ReportUsage gRPC API, with bounded attributes.
- Layered provisioning infers dependencies from Bicep parameter references, so dependent layers run in the right order without manual sequencing.
- Azure Functions services can deploy from a Dockerfile, a prebuilt image, or an Azure Container Registry remote build.
docker.imagePassthroughdeploys an already-published image by reference, skipping local and remote image operations entirely.
Authoring and publishing
The authoring experience runs through the azd x developer extension, which was improved for GA. You scaffold a new extension with azd x init, and releases can be distributed through official, private, development, or nightly sources depending on audience. Validation providers and MCP tool support cover the more advanced workflow cases, which matters if your extension needs to gate actions or talk to agent tooling.
Extension source code lives in the Azure Developer CLI repository on GitHub, and there’s a browsable Awesome azd extension gallery if you’d rather see what exists before writing your own.
The private-registry story deserves a second look for larger organizations. Because extension sources are plain manifests at URLs, an internal feed is just a JSON file on internal hosting plus access controls. That means platform teams can curate a list of approved extensions and distribute it by URL, close to how internal NuGet or npm feeds work, without anyone building a portal.
There is one gap worth flagging: the dev registry’s extensions aren’t signed, and the docs say so outright. If your security posture requires signed binaries for anything on a developer workstation, stick to the official source and your own private builds until that changes.
Why teams should care
Most engineering organizations accumulate homegrown glue around their cloud CLI: scripts that wire up environments, run migrations, or enforce internal conventions before a deployment. The extension framework gives that glue a proper home, with versioning, distribution, and lifecycle management handled by the CLI instead of a wiki page and a setup script.
Compare the pre-extension alternative. The usual options were wrapping azd in a shell script that runs before and after every invocation, maintaining a fork of the CLI with your patches rebased on every release, or building a separate internal tool that duplicates azd’s environment model. All three rot in different ways. An extension tracks the CLI’s own release cadence, gets its dependencies resolved by the package management you just read about, and dies cleanly when azd extension uninstall runs.
The project-level requirements feature is the quiet highlight. Being able to declare “this repo needs extension X at version Y” turns onboarding from a README pilgrimage into azd extension install. That’s the difference between a plugin system people admire and one they actually use.
To get started, install the latest azd, run azd extension list to see what’s in the official registry, and try the demo extension. If you have an internal workflow worth productizing, azd x init is the starting line, and the Awesome azd gallery is the place to check whether someone already built it.