Azure Developer CLI (azd) April 2026 Updates

Emiliano Montesdeoca — Fri, 08 May 2026 00:00:00 +0000

Azure Developer CLI (azd) shipped five releases in April 2026 (1.23.14 through 1.24.2), with the big story being hooks that now run in Python, JavaScript, TypeScript, and .NET — not just Bash and PowerShell.

Multi-language hooks in azure.yaml

Hooks can now point to .py, .js, .ts, or .cs files in addition to shell scripts. Each language gets automatic dependency resolution:

Python — detects requirements.txt or pyproject.toml, creates a virtualenv, and installs deps before running. Configure the env name with virtualEnvName.
JavaScript / TypeScript — detects package.json and runs npm install automatically. TypeScript executes via npx tsx with no compile step needed. Choose your package manager with the packageManager config block.
.NET — runs .cs files with dotnet run. Single-file scripts are supported on .NET 10+. Configure the target framework via the configuration/framework block.

This means teams that already live in one of these languages no longer need to maintain a separate Bash or PowerShell hook just to wire up provisioning lifecycle events.

azd update graduates to public preview

azd update is now in public preview across all platforms. A single command handles the update regardless of how azd was originally installed — no more tracking down Homebrew, WinGet, or MSI paths separately.

Non-interactive mode via AZD_NON_INTERACTIVE

Setting AZD_NON_INTERACTIVE=true (or using --non-interactive / --no-prompt) now produces consistent, deterministic failures in CI/CD pipelines when a required input cannot be resolved automatically. Previously the behavior was inconsistent across commands.

AI model quota preflight check

azd provision validates Azure Cognitive Services quota before attempting to provision AI model resources. Deployments that would fail due to quota limits now surface the error early in the process rather than partway through provisioning.

“Fix this error” in Copilot troubleshooting

The azd Copilot troubleshooting integration gains the ability to directly apply a suggested fix — not just describe it. When the agent identifies a fixable issue, it can make the change in-place.

Custom provisioning providers and Key Vault secret resolver

Extension authors can now register alternative infrastructure backends with WithProvisioningProvider(). Separately, azd automatically resolves @Microsoft.KeyVault(...) references before passing configuration to extensions, removing the need for manual secret resolution in custom providers.

Template and watch-mode exclusions

Two new ignore files give finer control over file handling:

.azdignore — excludes contributor-only files (docs, CI configs) from template copies so end users get a clean project scaffold.
.azdxignore — excludes directories from triggering rebuilds during azd x watch, reducing noise during iterative development.

Reserved-name preflight and docker.network option

azd now warns when predicted resource names would contain Azure reserved words (MICROSOFT, WINDOWS, or the LOGIN prefix) before provisioning begins. A new docker.network option passes --network to docker build, which is useful in corporate proxy environments that require a specific Docker network.

Security fixes

The Windows MSI package now includes code-signing verification. A separate fix closes an environment variable leak that could expose values across extension command boundaries.

A packed month — the multi-language hook support in particular removes a real friction point for teams not working primarily in Bash. See the full release notes for the complete changelog across all five releases.

Your AI Experiments on Azure Are Burning Money — Here's How to Fix That

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

If you’re building AI-powered apps on Azure right now, you’ve probably noticed something: your cloud bill looks different than it used to. Not just higher — weirder. Spiky. Hard to predict.

Microsoft just published a great piece on cloud cost optimization principles that still matter, and honestly, the timing couldn’t be better. Because AI workloads have changed the game when it comes to costs.

Why AI workloads hit different

Here’s the thing. Traditional .NET workloads are relatively predictable. You know your App Service tier, you know your SQL DTUs, you can estimate monthly spend pretty accurately. AI workloads? Not so much.

You’re testing multiple models to see which one fits. You’re spinning up GPU-backed infrastructure for fine-tuning. You’re making API calls to Azure OpenAI where token consumption varies wildly depending on prompt length and user behavior. Every experiment costs real money, and you might run dozens before you land on the right approach.

That unpredictability is what makes cost optimization critical — not as an afterthought, but from day one.

Management vs. optimization — know the difference

One distinction from the article that I think developers overlook: there’s a difference between cost management and cost optimization.

Management is tracking and reporting. You set up budgets in Azure Cost Management, you get alerts, you see dashboards. That’s table stakes.

Optimization is where you actually make decisions. Do you really need that S3 tier, or would S1 handle your load? Is that always-on compute instance sitting idle on weekends? Could you use spot instances for your training jobs?

As .NET developers, we tend to focus on the code and leave the infrastructure decisions to “the ops team.” But if you’re deploying to Azure, those decisions are your decisions too.

What actually works

Based on the article and my own experience, here’s what moves the needle:

Know what you’re spending and where. Tag your resources. Seriously. If you can’t tell which project or experiment is eating your budget, you can’t optimize anything. Azure Cost Management with proper tagging is your best friend.

Set guardrails before you experiment. Use Azure Policy to restrict expensive SKUs in dev/test environments. Set spending limits on your Azure OpenAI deployments. Don’t wait until the bill arrives to realize someone left a GPU cluster running over the weekend.

Rightsize continuously. That VM you picked during prototyping? It’s probably wrong for production. Azure Advisor gives you recommendations — actually look at them. Review monthly, not yearly.

Think about lifecycle. Dev resources should spin down. Test environments don’t need to run 24/7. Use auto-shutdown policies. For AI workloads specifically, consider serverless options where you pay per execution instead of keeping compute warm.

Measure value, not just cost. This one’s easy to forget. A model that costs more but delivers significantly better results might be the right call. The goal isn’t to spend the least — it’s to spend smart.

The takeaway

Cloud cost optimization isn’t a one-time cleanup. It’s a habit. And with AI workloads making spend less predictable than ever, building that habit early saves you from painful surprises later.

If you’re a .NET developer building on Azure, start treating your cloud bill like you treat your code — review it regularly, refactor when it gets messy, and never deploy without understanding what it’s going to cost you.

Cloud | The .NET Blog