How to Use Azure App Service Deployment Slots for Safer Releases

Azure App Service deployment slots provide live environments for an app, each with its own host name. You can deploy a new version to a nonproduction slot, test it, warm it up, and swap it into production with a controlled release path.

Check the App Service tier

Deployment slots require the Standard, Premium, or Isolated tier of an App Service plan. The number of supported slots depends on the tier. Microsoft recommends checking the target tier before creating or scaling slots. [1]

1. Create a staging slot

1. Open the App Service app in the Azure portal.
2. Under Deployment, select Deployment slots.
3. Select Add.
4. Give the slot a short name such as staging.
5. Choose whether to clone configuration from an existing slot.
6. Select Add to create it.

A new slot has its own host name and starts with 0% customer traffic by default. Cloned settings can include app settings, connection strings, framework versions, WebSockets, HTTP version, and platform bitness. A private endpoint is not cloned across slots. [1]

2. Deploy the build to the slot

Open the staging slot as its own App Service resource and deploy the build to that slot. You can deploy from a different branch or repository. The slot contains no application content merely because its configuration was cloned, so deploy the application before testing.

Keep continuous deployment pointed at a nonproduction slot. Microsoft recommends deploying the production branch to a staging slot and swapping it into production instead of continuously deploying directly to the production slot. [2]

3. Separate slot-specific configuration

Review app settings and connection strings that should remain with the slot during a swap. Examples include staging service endpoints, test databases, feature flags, and credentials. Mark values as deployment-slot settings when they must not move into production.

Also review authentication, managed identity, virtual network integration, custom domains, certificates, IP restrictions, and diagnostic settings. Not every App Service setting swaps in the same way. [1]

4. Test the staging URL

1. Open the slot’s URL from its resource page.
2. Run a smoke test for the home page, authentication, key API calls, and data access.
3. Verify logs and health checks.
4. Confirm that staging points to staging dependencies.
5. Ask the relevant stakeholder to approve the build.

Do not expose a staging slot broadly without access restrictions when it contains unfinished code or test data. App Service provides access restriction controls for the slot.

5. Swap the slot into production

1. Open the App Service and select Deployment slots.
2. Choose Swap.
3. Set the source to the staging slot and the target to production.
4. Review the configuration changes.
5. Use swap with preview where you need to validate production settings before completing the swap.
6. Complete the swap after the validation checks pass.

App Service warms the source slot before changing routing. The target remains online while the source is prepared. After the swap, the previous production version remains in the staging slot, which gives you a fast rollback path by swapping again. [1]

6. Roll back carefully

If the new production version is not healthy, confirm the issue and swap the previous production version back from the staging slot. Keep in mind that long-running operations may be abandoned when workers recycle during a swap. Design application code and background work to tolerate restarts. [1]

Common mistakes

• Assuming cloned configuration also deploys application content.
• Allowing staging to use production credentials or destructive data.
• Deploying directly to production when a staging slot is available.
• Forgetting to test slot-specific settings and managed identity behavior.
• Using a slot as a rollback plan without keeping the previous build intact.

Sources

1. Microsoft Learn: Set up staging environments in Azure App Service
2. Microsoft Learn: Deployment best practices for Azure App Service