Coming Soon: GET-IT: Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET Coming Soon: GET-IT: Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET
Microsoft Azure

Azure Web App Deployment Slots


12404760 – electric background

In this post, I will explain the role of web app deployment slots in Azure and how to use them.



Sponsored Content

Say Goodbye to Traditional PC Lifecycle Management

Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.

What Are Deployment Slots?

Normally in the application development world, code goes through several phases before it is pushed into production, such as:

  1. Development
  2. Test
  3. Production

You can create these three separate environments in several ways with web apps:

  • Shared App Service Plan: You create a web app for each phase in a single app service plan. This reduces costs but it does create a potential for conflicts.
  • Separate App Service Plans: A web app is deployed for each phase in different app services plans. There might be an app service plan for each phase. Alternatively, you might have a plan for dev and test and a second plan for production. Isolation does increase costs but you can minimize this by using lower cost/scale plans for test/dev than you would for production.

Some organizations like to take things a little further. You can QA your code quite a bit in a test environment but there nothing like running it on a real system … or even with real users. We can do this using deployment slots.



A deployment slot is a release of a web app. On the face, it is a deployment slot of a web app but it is actually a linked and re-release of the original web app. For example, we can have a production web app and create a pre-production version of it. We can then upload new code into the pre-production deployment slot, running in the same app service plan as production, and test it in a couple of ways:

  • Isolated: The deployment slot has its own URL and can be accessed independently by testers.
  • Phased release: We can put the deployment slot into limited production, validating the application settings, such as database connection strings, are working correctly (Windows app service plans only).

Once we are happy with the quality of code in the deployment slot, we can promote it into production, thus demoting the old production deployment slot to pre-production.

Creating a Deployment Slot

I have a single web app, called petri, running in an app service plan, called bww.

An Azure web app with no deployment slots [Image Credit: Aidan Finn]
An Azure Web App Without Deployment Slots [Image Credit: Aidan Finn]

This web app is running version 1 of my web app code.

Version 1 of the code running in production [Image Credit: Aidan Finn]
Version 1 of the Code Running in Production [Image Credit: Aidan Finn]

I opened the web app, petri, browsed to Deployment Slots under Deployment and clicked Add Slot. The deployment slot is given a new name, petri-preprod in this case, and I opted to close the settings from the original web app.

Creating a new Azure web app deployment slot [Image Credit: Aidan Finn]
Creating a New Azure Web App Deployment Slot [Image Credit: Aidan Finn]

After a few moments, the new deployment slot appears in the same resource group as the production web app. This deployment slot is effectively its own web app now, with its own application settings, copy of the code, etc.

The new deployment slot appears [Image Credit: Aidan Finn]
The New Deployment Slot Appears [Image Credit: Aidan Finn]

The deployment slot also has its own URL, which is based on its own name and the name of the original web app. In my case, the URL of the deployment slot is

A new version of the code is uploaded to the deployment slot and can be tested with its own URL without impacting the production system.

Version 2 of the code running in the Azure web app deployment slot [Image Credit: Aidan Finn]
Version 2 of the Code Running in the Azure Web App Deployment Slot [Image Credit: Aidan Finn]

When I am happy with the new version of the code, I can return to Deployment Slots in the web app and click Swap.

It’s time to swap pre-production with production [Image Credit: Aidan Finn]
It’s Time to Swap Pre-Production with Production [Image Credit: Aidan Finn]

In the Swap blade, you can select the source and destination deployment slot, where the source deployment slot will be promoted to replace the destination slot.

Note that there are two swap types:

  • (Straight) Swap: You simply swap the deployment slots.
  • Swap with Preview: The application settings of the destination (production) deployment slot are copied to the source (pre-production) deployment slot. This allows you to test the new version of the code with the production web app’s database before the actual swap and requires a second step to complete the swap over.

Swapping Azure web app deployment slots [Image Credit: Aidan Finn]
Swapping Azure Web App Deployment Slots [Image Credit: Aidan Finn]

I chose the simple Swap action to replace the production system with the pre-production system. Now, I browse the URL of the production system. It has been updated with the code of the pre-production deployment slot.

The new version of code is now in production in the Azure web app [Image Credit: Aidan Finn]
The New Version of Code Is Now in Production in the Azure Web App [Image Credit: Aidan Finn]


Note that the pre-production version of the site now has the previous production code. This means that a rollback is easy to do by reversing the swap.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (0)

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.
Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: