[Issue] azd deploy automatically deploys to a deployment slot instead of the main app when `AZD_DEPLOY_{service}_SLOT_NAME` is not set

[GABRIELNGBTUC]

• Make sure you've installed the latest version using instructions

Output from azd version
azd version 1.23.13 (commit a1ccaff)

Describe the bug
Based on the Microsoft DevBlogs about deployment slots with AZD, a user can set the environment variable AZD_DEPLOY_{service}_SLOT_NAME to target a specific deployment slot when running azd deploy.

This also implies that by omitting this environment variable, azd will deploy directly to the main app. However, when running azd deploy subsequently by omitting this environment variable, azd always deploys the service to the last deployed deployment slot and not the main app. This prevents us to have two pipelines, one deploying to the main app and another to the deployment slot.

To Reproduce

1. Set the AZD_DEPLOY_{service}_SLOT_NAME environment variable
2. run azd deploy service_name --no-prompt
3. Remove AZD_DEPLOY_{service}_SLOT_NAME
4. run azd deploy service_name --no-prompt

In the deployment logs, nothing is deployed to the main app and both deployments target the deployment slot.

Expected behavior
When AZD_DEPLOY_{service}_SLOT_NAME is not set, azd deploy targets the main app.

Additional context

I can see from this PR #6627 that the selection is done based on deployment history. I don't know about others but the last thing I would like from azd is to silently select a deployment slot for me based on an unknow criteria not explained anywhere. Especially not in a pipeline environment.

production is a reserved word in deployment slots too. So the simplest solution would be to always deploy to the main app when AZD_DEPLOY_{service}_SLOT_NAME is set to production.

[vhvb1989]

Thank you for reporting this @GABRIELNGBTUC

The expected auto-slot-selection rules are:

-1. First deployment: Deploys to main app + all slots (ensures consistency)
-2. Single slot scenario: Automatically deploys to that slot
-3. Multiple slots: Prompts user to select target (including main app)
-4. No slots: Deploys to main app only (existing behavior)

Based on your repro instructions, your first deployment is actually setting AZD_DEPLOY_{service}_SLOT_NAME ? Can you confirm that is your very first deployment? (either from azd up or azd provision + azd deploy) ?

What I suspect is that, since you are running in CI, with multiple slots, azd is following into option 3. It is prompting to pick which slot to deploy to, and since we have the --no-prompt flag, azd is taking the default option which maybe is by coincidence the slot you used before with the ENV VAR. I'll take a look to this - I think there should not be any default for the prompt and azd should be retuning an error mentioning you didn't define what slot to use and you are running in CI.

The other thing I suspect is that, if you didn't make any initial deployment to the main slot, azd might always fall into option 1 and deploy to main slot and all other slots. Azd looks the main slot deployment history to know when is the very first deployment - and the expectation is that the very fist time you deploy your app you would deploy the same version to main and all slots.

[vhvb1989]

Also @GABRIELNGBTUC can you confirm if you have just one only slot or more than one?

I am thinking that if you have just one slot, then azd is using rule 2. and automatically picks the slot by default. The assumption here is that, when you are using slots, you only want to deploy to your main app the very first time. After that, you only deploy to slots. Azd should ask you which if you have more than one, or auto-pick if you only have one.

The expectation is that if you want to deploy to the main app, you would to a slot-swap and not a direct deploy to the main app

[vhvb1989]

Thanks for reporting this. After investigating the slot deployment implementation (service_target_appservice.go → determineDeploymentTargets), the behavior you are seeing is working as designed.

What is happening in your scenario

Based on your repro steps with a single deployment slot, here is what the code does:

1. Run 1 (with AZD_DEPLOY_{SERVICE}_SLOT_NAME set): azd checks deployment history, finds previous deployments exist, sees exactly 1 slot → deploys to that slot. The env var is actually not consulted in this case — with only one slot, there is only one possible target.

2. Run 2 (without the env var): same check — previous deployments exist, exactly 1 slot → deploys to that slot again. Same result.

In the single-slot scenario, the AZD_DEPLOY_{SERVICE}_SLOT_NAME env var has no effect because there is no ambiguity to resolve — the only target is that one slot.

Why azd never deploys directly to the main app when slots exist

This is intentional. Once slots are configured and the first deployment has occurred, azd will never deploy directly to the main app (production). The design expects users to deploy to a slot and then swap that slot into production (e.g., using the azd appservice swap extension). This prevents accidental direct-to-production deployments.

The AZD_DEPLOY_{SERVICE}_SLOT_NAME env var is only consulted when there are 2 or more slots, to allow CI pipelines to auto-select which slot to target without an interactive prompt.

Summary

Slots	Env var behavior	Target
0	N/A	Main app
1	Ignored — only one possible target	That slot
2+	Used to auto-select; prompts if unset	Selected slot

To update the main app, use slot swapping after deploying to a slot.

---

I have created #7370 to track documenting this behavior, since it is not currently explained anywhere and the design decisions are non-obvious.

[GABRIELNGBTUC]

@vhvb1989
We are using a single slot as you have guessed.

I understand that it is "as designed" behaviour. However, creating a second slot just for the purpose of deploying to the main app and using azd appservice swap after every deployment may work for a single app. But when you have tens of them, the overhead on wasted app service plan resource and deployment times are not sustainable.

This would be easily fixed by having AZD_DEPLOY_{SERVICE}_SLOT_NAME directly deploy to the main app when it is set to production, regardless of whether there are 1 or multiple deployment slots.

[vhvb1989]

Can you tell me more about that scenario @GABRIELNGBTUC ? the one causing overhead?

You don't have to create a second slot. For every application you are hosting, you might have one appservice plus one only slot.
You have the slot for each service which you want to have a way to deploy and preview your app in the slot before releasing that to the main app.

There are 2 classic scenarios you can follow:

• 1. using CI: You have a CI pipeline that is trigger automatically when you push changes to your main branch. This pipeline deploys your app to the slot so you can preview the app. Once you confirm the changes are good and ready to be in the main app, you would manually trigger a CI pipeline that runs appservice slot swap. It moves the slot's app to the main app and the main app into the slot.
• 2. local flow: Instead of using CI pipelines, you would just run azd to deploy directly to the slot as many times as you want. And when you are ready, you do swap

If you have many applications, you would only create slots for those which you want to preview and support swapping. Swap also gives you rollback, in case you swap a change from your slot to the main app and discover an issue, you can easily swap again to restore the main app how it was before.

You would want to have more than one single slot when you are mapping each slot to a different branch in a team, so you can preview multiple changes in different slots at the same time. In that world, you can make CI to do the swap to the main app depending on the branch that you merged to main.

[GABRIELNGBTUC]

@vhvb1989

We have two dev branches:

1. The first one (we'll call it dev/main) is the main development track that is currently being used. Until now, the branch was always deployed to the main app directly
2. We then add a new branch (dev/replacement) that is a new track meant to possibly sunset dev/main in the future (in months with a full dev/test/production pipeline)

Each branch continuously receives commits and need deployments, but they also are not different enough that they warrant being deployed to different web apps.

Since we were always deploying dev/main to the main app, we now created a deployment slot for dev/replacement. Our plan is then to continuously deploy dev/main to the main app and dev/replacement to the slot and perform a single swap when dev/main will be deprecated. dev/replacement should never reach the main app while dev/main is expected to always be the version on the main app.

Because of the current limitations of AZD we then are left with the following options to reach our objective:

• Single deployment slot with swap: Impossible or unpractical. It is possible that we may do deployments of dev/main and dev/replacement in parallel. Meaning that even if we do not automatically swap slots when deploying dev/replacement, we have no guarantee that the version on the deployment slot that will be swapped during deployments of dev/main, will not be dev/replacement during parallel deployments.
• Two deployment slots: In this configuration, we have a deployment slot for dev/main and another for dev/replacement, dev/replacement is never swapped while dev/main is always swapped on a deployment. There is no risk of conflicts, however we have a hanging deployment slot that is here purely for the purpose of enabling "direct" deployments to the main app. Which is both a waste of resources and possibly increasing our surface of attack on a slot that should be unnecessary.

The proposal that I have of allowing azd to read the value production from AZD_DEPLOY_{SERVICE}_SLOT_NAME to deploy to the main app would prevent the need of additional deployment slots and guarantee that dev/main is always deployed to the main app and that dev/replacement is always deployed to the single deployment slot.