Azure App Service Slots: Keep Settings Where They Belong During Swap

The release that broke after the swap

You push a new build to the staging slot of an Azure App Service. The slot passes every test. You run the swap, traffic moves to the new code, and within minutes the application starts returning errors. The database connection string is pointing at the staging database, or worse, the setting vanished entirely.

This is a common footgun with Azure App Service deployment slots. A deployment slot is a separate instance of your app with its own hostname, configuration, and content. During a swap, Azure moves code and configuration between slots. Whether an app setting or connection string moves with the code or stays attached to the slot depends on a single flag: slot setting.

How slot settings work

An app setting marked as a slot setting is sticky. It remains with the slot after a swap, so production keeps its production connection string even when the staging code moves into it. A setting that is not marked as a slot setting travels with the swap target like application code. If the target slot does not contain that setting, it can be removed from the destination slot after the swap completes.

Azure App Service performs a warm-up and swap operation rather than simply cutting over DNS. The target slot is initialized, and if you have configured health checks, Azure verifies the slot is responding before directing traffic. This reduces the chance of sending users to a broken release, but it does not protect you from configuration that moves to the wrong place.

Worked example: mark a connection string as slot-specific

Run these commands in Azure Cloud Shell or a local terminal with the Azure CLI installed. You need Contributor or Owner permissions on the App Service resource, or the specific Microsoft.Web/sites/slots/write action.

# Replace placeholders with your values
RESOURCE_GROUP="my-rg"
APP_NAME="my-api"
SLOT_NAME="staging"
SETTING_NAME="DefaultConnection"

# List current settings to see which are already slot settings
az webapp config appsettings list \
  --resource-group $RESOURCE_GROUP \
  --name $APP_NAME \
  --slot $SLOT_NAME \
  --query "[?slotSetting == true].name" \
  --output table

# Mark an existing app setting as a slot setting so it stays with the slot
az webapp config appsettings set \
  --resource-group $RESOURCE_GROUP \
  --name $APP_NAME \
  --slot $SLOT_NAME \
  --slot-setting true \
  --settings $SETTING_NAME="Server=tcp:staging-db.database.windows.net;..."

# Verify the flag
az webapp config appsettings list \
  --resource-group $RESOURCE_GROUP \
  --name $APP_NAME \
  --slot $SLOT_NAME \
  --query "[?name=='$SETTING_NAME'].{name:name, slotSetting:slotSetting}" \
  --output table

Expected check: the slotSetting field should be true for DefaultConnection. If it is false or missing, the value will move during the next swap.

Risk: marking a setting as slot-specific means the two slots can diverge intentionally. That is usually what you want for connection strings and storage keys, but it also means a setting added only to production will not appear in staging after a swap unless you add it there too.

Trade-offs and limitations

• SSL bindings do not swap automatically. Certificates bound to one slot must be re-bound or uploaded to the target slot before the swap, or HTTPS can fail after traffic moves.
• Settings omitted from the target slot may be removed. If a non-slot setting exists in production but not in staging, swapping staging into production can delete that setting from production.
• Slots share the App Service plan. You pay for the plan capacity once, but each slot consumes runtime resources on the same instances. A busy staging slot can affect production performance.

Pre-swap checklist

1. Audit app settings and connection strings in both slots.
2. Mark environment-specific values such as databases, storage accounts, and feature flags as slot settings.
3. Verify SSL certificates exist on the target slot.
4. Warm up the target slot by browsing its URL directly.
5. Perform the swap in the Azure portal or with az webapp deployment slot swap, then check application logs and the production URL.

If something goes wrong, you can swap back immediately. The previous slot still holds the prior code and its sticky settings, so rollback is fast and does not require redeployment.

Treat slot settings as the boundary between what travels with your release and what stays anchored to the environment. Check the flag before you swap, not after the errors start.