••Updated: November 2, 2025•⏱️ 10 min read•💬 1 Comment
Azure App Service (PaaS): Build & Run Web Apps, REST APIs, and Mobile Backends
Azure App Service (PaaS): Build & Run Web Apps, REST APIs, and Mobile Backends
A complete, production-grade guide to Azure App Service for developers and platform engineers: architecture, CI/CD, autoscale, networking, security, diagnostics, and hands-on troubleshooting with PowerShell, Azure CLI, Kudu, and Microsoft Graph.
Why Azure App Service?
Azure App Service is a fully managed PaaS that abstracts servers, OS patching, capacity planning, and load balancing, so teams can focus on features. You can host modern web apps, REST APIs, and mobile backends using .NET, Java, Python, Node.js, PHP, and Ruby—with built-in CI/CD, autoscaling, diagnostics, and Microsoft Entra ID (Azure AD) authentication.
Zero server admin—patching, OS upgrades, and fleet ops handled for you.
Scale in minutes—increase instances or scale up pricing tiers seamlessly.
App Service is a true PaaS: Microsoft manages compute hosts, OS patching, runtime updates, and load balancers. You select an App Service Plan, deploy code or containers, and the platform handles the rest.
Key Points
Managed OS and runtime images for Linux and Windows.
Tip: Size up or down the plan without redeploying the app code.
Quick FAQ (10)
Is the OS patched automatically? Yes, App Service handles OS/runtime patching.
Do I manage load balancers? No, built-in L4/L7 load balancing is included.
Can I deploy containers? Yes, both single container and multi-container (compose) on Linux.
Does the plan isolate apps? Apps share the plan’s VMs; ASE offers full isolation.
How to check platform issues? Service Health + Resource Health + Diagnostics.
How to scale? Scale up (SKU) or out (instances) in the plan’s Scale blade.
What runtimes are supported? .NET, Java, Node, Python, PHP, Ruby (on Linux).
Can I pin runtimes? Yes—choose major/minor stack versions per app.
How to automate creation? ARM/Bicep, Terraform, Az PowerShell, Azure CLI.
Does PaaS support WebSockets? Yes—enable it in Configuration > General Settings.
2) Multi-language Support (.NET, Java, Python, Node, PHP, Ruby)
Choose a language/runtime and deploy without changing your architecture. Platform images are tuned for .NET, Java, Python, Node.js, PHP, and Ruby (Linux).
Key Points
Pick a runtime stack + version in Configuration.
Use custom container if you need system dependencies.
Node/Java apps can specify startup commands or scripts.
Azure CLI: Create Node.js App
rg=rg-appsvc-demo
loc=eastus
plan=asp-web-prod
app=web-node-001
az group create -n $rg -l $loc
az appservice plan create -n $plan -g $rg --sku P1v3 --is-linux
az webapp create -g $rg -p $plan -n $app --runtime "NODE|20-lts"
az webapp config appsettings set -g $rg -n $app --settings NODE_ENV=production ENABLE_ORYX_BUILD=true
Quick FAQ (10)
How do I set Python version? Choose stack in Configuration > General settings.
Does Java need an app server? Linux App Service supports Java SE or Tomcat images.
Can I bring system libs? Yes with custom Docker images.
Is PHP supported on Windows? Use Linux for current PHP runtime support.
Can I run .NET 8? Yes, select .NET 8 stack.
Start script for Node? Set Startup Command or use package.json scripts.
JVM tuning? Use JAVA_OPTS in app settings.
pip/npm restore? Oryx builder handles dependencies at build/deploy.
Ruby supported? Yes on Linux containers or bring your own image.
Localization? Configure culture/timezone via settings and code.
3) Host Web Apps, REST APIs, and Mobile Backends
App Service specializes in stateless HTTP workloads—web front-ends, JSON APIs, GraphQL, and mobile gateway backends. Add persistence via Azure SQL Database, Azure Storage, or Cosmos DB.
Key Points
Enable ARR Affinity only when sticky sessions are required.
Use Azure API Management in front of APIs for throttling, auth, and versioning.
Cache layer: Azure Cache for Redis to reduce load.
Should I use APIM? Yes for API security, throttling, and developer portal.
GraphQL OK? Yes—host it like any Node/.NET API.
Mobile push? Use Notification Hubs; App Service hosts the backend.
File uploads? Send to Blob Storage; keep apps stateless.
gRPC? Use HTTP/2 support and appropriate runtime.
Rate limiting? APIM or NGINX in container; app logic where needed.
Long running jobs? Offload to WebJobs, Functions, or Queues.
Static web? Prefer Static Web Apps; or cache at CDN.
Multipart forms? Stream to storage to avoid memory spikes.
JSON size limits? Tune server and client; paginate responses.
4) Integrated DevOps & CI/CD
App Service plugs into Azure DevOps, GitHub, Bitbucket, and other providers for continuous delivery. Use GitHub Actions or Azure Pipelines to build with Oryx and deploy across slots.
Key Points
Zero-downtime deployment using slots + health checks.
Oryx builds auto-detect language & lock dependency versions.
Use staged rollouts with slot traffic (% based).
PowerShell: Create Slots + Swap
$rg="rg-appsvc-demo"; $app="webapp-prod-001"
New-AzWebAppSlot -Name $app -ResourceGroupName $rg -Slot "staging"
# Deploy to 'staging' (via your pipeline), then swap:
Switch-AzWebAppSlot -Name $app -ResourceGroupName $rg -SourceSlotName "staging" -DestinationSlotName "production"
Azure CLI: Set Up Deployment from GitHub
az webapp deployment source config \
--name webapp-prod-001 --resource-group rg-appsvc-demo \
--repo-url https://github.com/yourorg/yourrepo --branch main --manual-integration
Quick FAQ (10)
Can I use GitHub Actions? Yes—use the Azure Web Apps deploy action.
Blue/green? Use slots and Swap with traffic ramp-up.
Infra as code? ARM/Bicep/Terraform are all supported.
Monorepos? Build matrix or path filters in pipelines.
Secrets? Store in Key Vault and reference via managed identity.
Rollback? Swap back or redeploy previous artifact.
Warmup settings reduce cold starts after scale out.
Set Health Check Path to route around bad instances.
Use Min instance floor to absorb traffic spikes.
Quick FAQ (10)
Horizontal vs. vertical? Out = more instances; up = bigger SKU.
Custom metrics? Yes via Azure Monitor metric alerts.
Schedule-based scaling? Define time windows in autoscale profiles.
Pre-warming? Use Always On + warmup requests.
Health probe path? Configure under Health check.
Autoscale cooldown? Avoid oscillation; 5–10 min works well.
Per app scaling? Scaling is at plan level; isolate critical apps in their own plan.
Cost guardrails? Set max instances + budget alerts.
Queue length metric? Use HttpQueueLength for backpressure.
Memory rules? Use MemoryWorkingSet metric on Windows plans.
6) Global Availability
Deploy apps close to your users across global regions for low latency and failover. Use slot swaps and geo-redundant deployment patterns with Traffic Manager or Front Door.
Key Points
Active/active with Front Door + health probes.
Blue/green per region with independent slots.
Geo-replicate state (database/storage) appropriately.
CLI: Deploy Same App Name in Multiple Regions
for r in "eastus" "westeurope"; do
az group create -n rg-$r -l $r
az appservice plan create -g rg-$r -n asp-$r --is-linux --sku P1v3
az webapp create -g rg-$r -p asp-$r -n myapp-$r --runtime "NODE|20-lts"
done
Quick FAQ (10)
How do I fail over? Front Door routes around unhealthy backends.
DNS vs. Front Door? Front Door adds WAF, TLS, and anycast edge.
Data replication? Choose geo-replicated DB/storage strategy.
Latency testing? Use Front Door metrics + RUM in App Insights.
Certs per region? Manage centrally in Front Door, or per app.
Deployment per region? Pipeline stages per environment/region.
Same name globally? App names are DNS global; use suffix by region.
Edge caching? Use CDN/Front Door caching for static assets.
DR drills? Practice region evacuation with scripts.
RPO/RTO? Define based on data tier (SQL/Storage) not App Service.
7) Custom Domains & SSL/TLS
Map vanity domains and secure with free App Service Managed Certificates or bring certs from Key Vault.
Slots let you deploy and test without touching production. Swap when ready; swap-settings control which app settings/connection strings stay in each slot.
Roles in tokens? Define app roles in Entra app registration.
Custom policy? Use your own middleware or APIM policies.
B2C? Use Azure AD B2C as identity provider to EasyAuth.
Logout? Call /.auth/logout endpoint.
Token refresh? Rely on provider; use MSAL on client.
Impersonation? Use On-behalf-of flow in your API.
Anonymous pages? Configure Allow unauthenticated for those routes.
WAF? Put Front Door WAF in front of the app if needed.
12) App Service Environment (ASE)
For high security and isolation, use ASE to host apps in a dedicated subnet with private IPs and scale capabilities.
Key Points
Private networking only—no public endpoints if desired.
Best for regulated workloads needing isolation.
Higher cost but stronger boundaries and capacity.
Quick FAQ (10)
When to choose ASE? Isolation, private networking, and high scale.
Public access? Optional—can be disabled.
Cost? Higher than shared plans; plan accordingly.
VNet address space? Plan subnets carefully for growth.
Private DNS? Configure split-horizon where needed.
Ingress? Private endpoints or internal load balancers.
Hybrid? Combine with ExpressRoute for on-prem access.
Migration? Redeploy via IaC + data migration.
Monitoring? Same App Insights/Monitor patterns apply.
WAF? Use Application Gateway WAF or Front Door.
13) VNet Integration
Securely reach private resources via VNet integration or expose your app privately via Private Endpoints. Combine with ExpressRoute or VPN for on-prem.
var client = new SecretClient(new Uri("https://kv-prod-001.vault.azure.net/"),
new DefaultAzureCredential());
var secret = await client.GetSecretAsync("DbPassword");
Quick FAQ (10)
System vs. user-assigned? System tied to app; user-assigned reusable.
Key Vault references? Use @Microsoft.KeyVault(SecretUri=...) in app settings.
Rotate secrets? No app changes—identity stays constant.
Graph access? Grant roles on Graph as needed.
SQL access? Use Entra auth for SQL with MSI.
Storage SAS? Prefer role-based access, not keys.
Least privilege? Grant minimal roles at specific scopes.
Diagnostics? Check token acquisition failures in logs.
Local dev? Use developer credentials via DefaultAzureCredential chain.
Multi-tenant? Ensure correct tenant is targeted.
15) Container Support (Docker & Custom Images)
Run custom Linux/Windows containers for full control over runtime and dependencies. Pull from ACR or public registries.
CLI: Configure Container Deploy
az webapp create -g rg-appsvc-demo -p asp-linux -n web-cnt-001 \
--deployment-container-image-name contoso.azurecr.io/app:1.0.0
az webapp config container set -g rg-appsvc-demo -n web-cnt-001 \
--docker-custom-image-name contoso.azurecr.io/app:1.0.1 \
--docker-registry-server-url https://contoso.azurecr.io
Key Points
Use WEBSITES_PORT app setting to expose container port.
Health check path should hit container liveness endpoint.
Prefer minimal bases (Alpine/Distroless) for smaller attack surface.
Quick FAQ (10)
Multi-container? Use docker-compose on Linux.
Private registry? Use admin creds or ACR with Managed Identity.
Startup cmd? Set in Startup Command or Dockerfile CMD.
Thanks for sharing. I read many of your blog posts, cool, your blog is very good. https://www.binance.com/cs/register?ref=OMM3XK51