Deploying to Azure App Service Slots with azd: Finally, No More Workarounds

⏱️ 6 min read📅 28 March 2026

So… You Want Predictable Azure Deployments? Welcome to Slot City

Bak şimdi, I’ll be blunt—since 2016, deployment slots in Azure App Service have been that one trick that keeps impressing me (even after all these years). But let’s not pretend it was painless. If you ever poked around the Azure Developer CLI (azd) for anything outside of quick hello-worlds, you probably got smacked by reality: deploying to a non-prod slot felt like using a Swiss Army knife as a crowbar. Hacking together weird scripts, massaging YAML until your eyes bled, maybe crossing your fingers and hoping nothing broke. The past tense matters here—because this latest azd update finally brings slots out of the shadows and into the real workflow.

Bakın, This isn’t just convenience for nerds like us—it actually shifts how blue/green deployments look when you’re on deadline in production environments (şaşırtıcı ama gerçek). I’ll walk through what changed, where things tripped me up last month at a fintech project in Istanbul (don’t get me started), and why I might retire my regular Friday rant about azd failures.

The Elephant in the Room: Why Deployment Slots Matter (And Hurt)

Şöyle ki, No sense sugarcoating it—if you aren’t using slots yet, every push is going straight to prod. Ballsy move. Or wild optimism? Possibly both (buna dikkat edin)

Flashback to late 2021—a hospital SaaS migration landed in my lap. Zero-downtime deployments were “critical” but our only option was swapping slots by hand with PowerShell stitched haphazardly into brittle DevOps pipelines. The thing looked more like spaghetti than anything I cooked up back at university—and debug time chewed through entire afternoons.

Before this update, azd users could only deploy straight into the default production slot—so much for safe testing or blue/green strategies.

The fallout? Missed our maintenance window twice and heard from some pretty steamed doctors locked out after so-called “successful” releases.

Bicep Meets Reality: Defining Slots Without Tears

This part is actually fun now—with this new azd release (shoutout PR #6627 for fellow changelog junkies), setting up extra slots won’t leave you grumpy before lunch. You describe each slot right there with your Bicep resources, no convoluted templates needed:

resource webApp 'Microsoft.Web/sites@2021-03-01' = {
name: 'my-appservice'
location: resourceGroup().location
kind: 'app'
properties: { serverFarmId: myPlan.id }
}
resource stagingSlot 'Microsoft.Web/sites/slots@2021-03-01' = {
name: '${webApp.name}/staging'
location: webApp.location
properties: {}
}

If you want less busywork—just use those shiny Azure Verified Modules. They tuck away most of the ARM/Bicep noise:

module appservice 'br/public:app-service:1.3.2' = {
name: 'my-appservice'
params:{ /* ...params */ }
}
module stagingSlot 'br/public:web-app-deployment-slot:1.0.2' = {
name:'staging'
params:{ appServiceName : appservice.outputs.name }
}

💡 Note: Hunting for slots on Free or Basic plans? Don’t bother—they don’t exist unless you’re Standard tier or higher.

No More Guesswork with azd up & azd deploy

I tried rolling this out two weeks back while helping a retail client migrate their workflows near Ankara—the whole thing ran smoother than I expected if we’re being honest.

You run azd up. Multiple slots defined (say ‘production’ plus ‘staging’)? After initial setup it simply asks which one to target next time around.
If human interaction bores you—or if automation is king in CI/CD—you can just set AZD_DEPLOY_MYAPI_SLOT_NAME=staging. No prompts, no guesswork; robots love it too.
Your code hits exactly the right slot without any home-brewed scripting—that’s honestly never happened out-of-the-box before with azd!

Pitfalls Still Lurking?

I’m glad things are looking up but let’s stay grounded—some snags remain: Auto-Install azd Extensions in Dev Containers: My Hands-On Take yazımızda da bu konuya değinmiştik. Azure Developer CLI in January 2026: Config Tweaks, Speed Gains & A Few Surprises yazımızda da bu konuya değinmiştik.

If your naming between Bicep/modules versus environment variables drifts even slightly… expect nasty debugging sessions over missed deployments.
No built-in rollbacks yet—a swap is still separate business (see what I really think about swaps here:Azure Developer CLI’s App Service Slot Swap). Don’t blur them!
If pipeline secrets live per-slot/environment already… triple-check config before jumping ship or chaos will ensue quickly.

Straightforward Automation—for Real This Time?

I spent last Saturday night jamming this into an old GitHub Actions workflow (yeah—I party hard). Setting that env var before calling azd deploy? That’s literally all there is now.
Nothing sneaky buried ten pages deep in docs either.
The only snag came from mismatched output names between my module outputs and env vars—which sent me hunting down the typo over thirty minutes and two mugs of coffee—but compared to wrestling legacy scripts? Piece of cake!

Finally—the same predictable deployments whether you’re running interactively or via CI/CD pipelines!

A Quick Table Recap Because Who Doesn’t Love Tables?

Scenario	You Before	You Now With New azd
Bicep Slot Definition	Painful custom logic/scripts	Straightforward resource/module block
Select Target Slot	N/A — always production by default	Select interactively OR via env var
Pipelines Support	Duct tape + custom bash/pwsh steps	Add one env var export — done!
Tiers Supported	N/A — worked nowhere useful anyway!	Standard+ tiers only — makes sense!

Caveats and Surprising Use Cases From the Field

An unexpected bonus from Logosoft’s FinOps dashboard pilot earlier this month—we saw junior developers trying out new ‘qa’ or ‘feature-preview’ slots left and right because nobody had to decode ancient YAML files anymore (“Don’t touch those lines unless you enjoy pain”). Productivity shot up—and so did billable learning hours because people stopped being terrified they’d accidentally roast prod!

One little letdown though—still no native multi-region slot orchestration via plain vanilla azd yet; global teams will need DIY glue jobs awhile longer.

Migrating Old Projects? Here’s What Bit Me…

If you’re still rocking classic infra definitions not built on Bicep modules—or hybrid setups mixing raw ARM JSON—the odds of random breakage go way up; refactor first if sanity matters.
Certain crusty naming schemes seem invisible to current azd parsing logic; batch migrations demand hands-on dry runs before flipping everything live.
If your App Service Plan hops between tiers mid-pipeline—even though it’s rare—I noticed sometimes resources just bail quietly due to quota limits.

The Bottom Line—Is It Worth Switching Today?

I’m genuinely not overselling when I say this lands as probably my favorite practical enhancement since JMESPath filtering came along (JMESPath in Azure Developer CLI article here if that’s news!). Whether you’re moonlighting solo or wrangling enterprise-scale automation across continents like we do every week at Logosoft, stamping out mystery-meat deployments pays off almost instantly.

If you’ve avoided deployment slots because tooling was awful—stop waiting! For once I’m mostly happy instead of skeptical.
If homemade scripts/pipelines kept things glued together until now—a careful migration pays dividends quickly (& fewer headaches).
If none of this means much yet… buy coffee for someone who’s shipped broken code straight onto prod—they’ll tell you why predictability suddenly matters more than sleep!

Source: Deploy to Azure App Service deployment slots with azd