App Service is the quickest production-grade way to run a web app without managing servers.
Azure App Service runs web apps, REST APIs and mobile back ends on managed infrastructure. You deploy code (Python, Node.js, .NET, Java, PHP) or a container; Azure handles the OS, patching, load balancing and TLS.
Two resources are involved:
- The App Service plan is the compute you pay for: OS (Linux or Windows), tier (Free, Basic, Standard, Premium v3/v4, Isolated) and instance count. Several apps can share one plan and its VMs.
- The web app is your site, with a default hostname
<name>.azurewebsites.net.
Configuration lives in app settings, exposed to your code as environment variables, and connection strings. Scale up by changing the plan tier and out by adding instances, manually or with autoscale rules.
Deployment slots (Standard tier and up) are live staging copies of the app, such as staging. Deploy to the slot, warm it up, then swap it into production with no downtime; swap back to roll back. Mark environment-specific settings as slot settings so they don't move with a swap.
Other features worth knowing: built-in authentication ("Easy Auth"), custom domains with free managed certificates, VNet integration for outbound calls to private resources, and Always On to avoid cold starts after idle periods.
Example
# From a folder containing a Python (Flask/FastAPI/Django) app:
az webapp up --name orders-web-dev --resource-group rg-web \
--runtime "PYTHON:3.12" --sku B1
az webapp config appsettings set -g rg-web -n orders-web-dev \
--settings FEATURE_X=on LOG_LEVEL=info
# Zero-downtime release with a slot (needs Standard or higher)
az appservice plan update -g rg-web -n <plan-name> --sku S1
az webapp deployment slot create -g rg-web -n orders-web-dev --slot staging
az webapp deployment slot swap -g rg-web -n orders-web-dev --slot staging --target-slot productionRemember
- Plan = compute you pay for; app = site running on it
- App settings become environment variables
- Slots + swap give zero-downtime deploys and instant rollback
- Scale up = bigger tier; scale out = more instances
Watch out for
- Putting a heavy batch job in the same plan as the production site, so both compete for the same instances.