What Is Azure App Service?
Azure App Service is a PaaS offering that runs your web application, API, or mobile backend on Microsoft-managed infrastructure — you deploy code or a container image, and Azure handles the OS patching, load balancing, and web server configuration for you. It supports multiple language runtimes (.NET, Java, Node.js, Python, PHP, Ruby) natively via built-in images, or you can bring a custom Docker container for full control over the runtime environment while still avoiding VM management.
Cricket analogy: App Service is like playing at a stadium with a curator-maintained pitch and ground staff handling drainage and mowing — you just turn up and bat, instead of also having to prepare the square yourself like on a VM.
Deployment Slots and CI/CD
App Service supports deployment slots — separate live environments (like 'staging') with their own hostname that share the same App Service Plan — letting you deploy and fully warm up a new version in staging, run smoke tests against it, and then swap it into production with a nearly instantaneous, connection-draining slot swap that avoids downtime. Slots integrate directly with GitHub Actions, Azure Pipelines, or a container registry webhook, so a push to your main branch can automatically build, deploy to staging, and (optionally) auto-swap to production.
Cricket analogy: Deployment slots are like warming up a substitute batter in the nets in full match kit before sending them out, rather than throwing an unprepared player straight from the dressing room into a live delivery.
Scaling: Up vs Out
App Service separates two scaling dimensions: scaling up (or down) changes the App Service Plan tier — moving from Basic to Premium, say — giving each instance more CPU, memory, and features like slots or VNet integration; scaling out changes the instance count within the current tier, running multiple copies of your app behind Azure's built-in load balancer. Autoscale rules can scale out automatically based on CPU or memory thresholds or a schedule, and Premium/Isolated tiers support scaling out to far more instances than Basic, which caps out at 3.
Cricket analogy: Scaling up is like promoting a player from domestic cricket to add more skill per player (Basic to Premium tier), while scaling out is like adding more players to the squad, such as carrying five bowlers instead of four for depth.
# GitHub Actions: build and deploy to an App Service staging slot
name: deploy-webapp
on:
push:
branches: [main]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
run: npm ci && npm run build
- name: Deploy to staging slot
uses: azure/webapps-deploy@v3
with:
app-name: 'app-web-prod'
slot-name: 'staging'
package: '.'
- name: Swap staging into production
run: az webapp deployment slot swap --resource-group rg-webapp --name app-web-prod --slot stagingThe App Service Plan (not the app itself) determines your pricing tier, compute allocation, and available features. Multiple apps can share one Plan's compute for cost efficiency, but they also compete for that Plan's resources — an unexpectedly heavy app on a shared Plan can starve its neighbors.
The Free and Shared tiers do not support custom domains with SSL, deployment slots, or autoscale, and apps on the Free tier are put to sleep after 20 minutes of inactivity, causing a slow 'cold start' on the next request — never use them for production workloads.
Configuration and Secrets
App Service Application Settings inject environment variables into your app at runtime (visible under Configuration in the portal), which is how you typically vary connection strings and feature flags between deployment slots without changing code. For actual secrets, best practice is to store them in Azure Key Vault and reference them from App Service using Key Vault references (the @Microsoft.KeyVault(...) syntax) combined with a managed identity, so the app authenticates to Key Vault without any credential ever being stored in App Service configuration itself.
Cricket analogy: Using a managed identity to fetch secrets from Key Vault is like a player accessing the dressing room through a biometric fingerprint scan rather than carrying a spare key that could be lost or copied — no shared credential to leak.
- Azure App Service is a PaaS: you deploy code or a container, and Azure manages the OS, patching, and web server.
- Deployment slots let you warm up and test a new version before an instantaneous, near-zero-downtime swap into production.
- Scaling up changes the App Service Plan tier (more resources per instance); scaling out adds more instances.
- The Free and Shared tiers lack SSL custom domains, slots, and autoscale, and are unsuitable for production.
- Application Settings inject environment variables per slot; real secrets belong in Azure Key Vault, referenced via managed identity.
- Multiple apps can share one App Service Plan, but they also compete for that Plan's compute resources.
Practice what you learned
1. What is the main advantage of Azure App Service over deploying an app on a raw VM?
2. What does a deployment slot swap primarily achieve?
3. What is the difference between scaling up and scaling out in App Service?
4. What is the recommended way to store secrets used by an App Service app?
5. Which App Service tier should never be used for production workloads?
Was this page helpful?
You May Also Like
Azure Functions Basics
Azure Functions is a serverless compute service that runs small, event-triggered pieces of code without you provisioning or managing any servers.
Azure Virtual Machines
Azure Virtual Machines (VMs) provide on-demand, resizable compute as a service, letting you run Windows or Linux workloads in Microsoft's datacenters with full control over the OS.
Azure Container Instances
Azure Container Instances (ACI) runs individual containers directly in Azure without provisioning VMs or managing a container orchestrator like Kubernetes.