The swap: content changes, nothing restarts.

An App Service plan is the compute — a set of VM instances at a given size and tier. An app is a tenant on that compute: its own code, its own settings, its own URL, but no dedicated machine of its own. Put two apps on one plan and you pay for the plan once, not twice — the plan does not know or care how many apps sit on it, only how much CPU and memory they ask of it together. A deployment slot is a different idea entirely: a full, live copy of one app, with its own URL, that can trade places with production in a single operation. This lab proves both facts by doing them, not by reading about them.

The plan is billed. The app is free.

Create the plan, then the first app on it, then push a page small enough to write inline. The page is a bare Node server — no dependencies, so the deploy is instant.

# Windows/Git Bash: stop it mangling resource-id arguments (harmless on macOS/Linux)
export MSYS_NO_PATHCONV=1

SUFFIX=$RANDOM
RG="campux-lab-slot-rg"
LOCATION="eastus"
PLAN="campux-slot-plan"
APP1="campux-app1-$SUFFIX"

az group create --name "$RG" --location "$LOCATION" -o table

# S1 (Standard) — the smallest tier that supports deployment slots
az appservice plan create --name "$PLAN" --resource-group "$RG" \
  --sku S1 --is-linux -o table

az webapp create --name "$APP1" --resource-group "$RG" --plan "$PLAN" \
  --runtime "NODE:20-lts" -o table

mkdir -p slotlab && cd slotlab
cat > server.js <<'EOF'
const http = require('http');
http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('campux-slot-lab v1\n');
}).listen(process.env.PORT || 8080);
EOF
cat > package.json <<'EOF'
{ "name": "campux-slot-lab", "version": "1.0.0", "scripts": { "start": "node server.js" } }
EOF
zip -r ../app-v1.zip . > /dev/null && cd ..

az webapp deploy --name "$APP1" --resource-group "$RG" \
  --src-path app-v1.zip --type zip -o none

Add a second app to the identical plan and deploy the same page to it. Nothing about creating it references billing — that is the point: the plan is what is metered, and it is already paid for.

APP2="campux-app2-$SUFFIX"

az webapp create --name "$APP2" --resource-group "$RG" --plan "$PLAN" \
  --runtime "NODE:20-lts" -o table

az webapp deploy --name "$APP2" --resource-group "$RG" \
  --src-path app-v1.zip --type zip -o none

# both apps, same plan ID
az webapp list --resource-group "$RG" \
  --query "[].{name:name, plan:appServicePlanId}" -o table

Add a staging slot to app1 — a full second copy of it, with its own URL — and deploy a changed page to the slot only. Production does not see this change yet.

az webapp deployment slot create --name "$APP1" --resource-group "$RG" \
  --slot staging -o table

cd slotlab
sed -i 's/campux-slot-lab v1/campux-slot-lab v2/' server.js
zip -r ../app-v2.zip . > /dev/null && cd ..

az webapp deploy --name "$APP1" --resource-group "$RG" \
  --slot staging --src-path app-v2.zip --type zip -o none

A swap warms up every instance in the staging slot first, then switches the routing that decides which slot answers to the production hostname. No content is copied at request time and no deploy command touches production — the slot that was already running takes over.

az webapp deployment slot swap --name "$APP1" --resource-group "$RG" \
  --slot staging --target-slot production -o table

curl https://$APP1.azurewebsites.net

A swap is symmetric: running the identical command again trades the two slots back, which is exactly how you roll back a bad release without a redeploy.

az webapp deployment slot swap --name "$APP1" --resource-group "$RG" \
  --slot staging --target-slot production -o table

curl https://$APP1.azurewebsites.net   # -> v1 again

# tear down — the S1 plan bills by the hour, so do not skip this
az group delete --name "$RG" --yes
az group exists --name "$RG"   # -> false

You put two apps on one App Service plan and confirmed they share one bill. You added a staging slot to an app, deployed a changed page to it, and swapped it into production, then watched the production URL change content without a deploy or a restart command ever touching it. You know a plan is compute and an app is a tenant on that compute, and that a slot swap is a routing change against pre-warmed instances, not a live redeploy. This is the exact mechanism behind zero-downtime releases and instant rollback in production. What this lab deliberately skips — a private VNet in front of the plan, Key Vault-backed secrets, a CI/CD pipeline that triggers the swap automatically — is the enterprise-shaped version of the same idea, already built as the Campux Retail capstone deploy.