Azure App Service Overview: Managed Web Apps and APIs

What App Service provides out of the box

When you deploy to App Service, you get a substantial amount of infrastructure managed for you automatically:

• HTTPS and TLS certificates. Every App Service app gets a free managed TLS certificate on its default *.azurewebsites.net domain. For custom domains, App Service integrates with Azure-managed certificates (free) or your own certificates stored in Key Vault.
• Custom domains. Map your domain name to your app with CNAME or A record pointing, and App Service serves traffic on that domain with HTTPS.
• Auto-scaling. Scale out to more instances based on CPU, memory, HTTP queue length, or a schedule. App Service handles load balancing across instances automatically.
• Deployment slots. Run a staging version of your app alongside production. Swap between production and staging with a single click, with no downtime. The swap is instant — traffic routing flips without restarting either environment.
• Continuous deployment integration. Connect directly to GitHub, Azure DevOps, or Bitbucket. Every push to a branch automatically deploys to App Service.
• Diagnostic logging. Application logs, web server logs, detailed error messages, and failed request traces — all configurable without touching the OS.
• Managed identities. App Service apps can use a managed identity to authenticate to other Azure services (Key Vault, databases, storage) without storing credentials in app settings.

App Service Plans: tiers and what they mean

An App Service Plan is the compute resource your apps run on. The plan determines the region, VM size, number of instances, and the features available. Multiple apps can share one plan — they all run on the same underlying instances.

Most production web applications run on Standard or Premium tier. Standard S1 is a common starting point for small to medium apps — it includes autoscaling, deployment slots, and dedicated compute. Upgrade to Premium when you need better VM performance, more slots, or VNet integration for private database access.

Ways to deploy to App Service

ZIP deploy

Package your application as a ZIP file and push it to App Service. Fastest for simple deploys where your build artifact is a directory of files:

# Deploy a ZIP package to App Service
az webapp deployment source config-zip \
  --resource-group my-rg \
  --name my-web-app \
  --src ./app.zip

GitHub Actions continuous deployment

Connect your App Service to a GitHub repository and choose a branch. Azure generates a GitHub Actions workflow file that builds and deploys on every push:

# Connect GitHub to App Service (triggers GitHub Actions workflow generation)
az webapp deployment source config \
  --resource-group my-rg \
  --name my-web-app \
  --repo-url https://github.com/myorg/myapp \
  --branch main \
  --manual-integration

Container image deploy

If your application is packaged as a Docker image, App Service can pull it from Azure Container Registry and run it directly. This is useful for polyglot applications or apps with complex dependencies that are easier to manage in a container:

# Configure App Service to use a container image from ACR
az webapp config container set \
  --resource-group my-rg \
  --name my-web-app \
  --docker-custom-image-name myacr.azurecr.io/myapp:latest \
  --docker-registry-server-url https://myacr.azurecr.io

Configuration and environment variables

App Service exposes application settings as environment variables to your app at runtime. Set them through the portal or CLI:

# Set environment variables for the app
az webapp config appsettings set \
  --resource-group my-rg \
  --name my-web-app \
  --settings \
    NODE_ENV=production \
    API_ENDPOINT=https://api.example.com \
    LOG_LEVEL=info

For secrets like database passwords or API keys, use Key Vault references instead of plain-text app settings. A Key Vault reference looks like @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/db-password/) as the value of an app setting. App Service fetches the secret from Key Vault at startup and provides it as an environment variable — without storing the value in App Service configuration.

Deployment slots: zero-downtime releases

Deployment slots are separate versions of your app running alongside each other under the same App Service Plan. The most common pattern is two slots: production and staging.

Your CI/CD pipeline deploys to the staging slot. Warm-up traffic hits staging. Once you confirm it is healthy — by running smoke tests or checking Application Insights — you swap staging to production. The swap is instant: App Service switches the routing configuration, so traffic that was hitting staging now hits production and vice versa. No restart, no downtime.

# Create a staging slot
az webapp deployment slot create \
  --resource-group my-rg \
  --name my-web-app \
  --slot staging

# Swap staging to production when ready
az webapp deployment slot swap \
  --resource-group my-rg \
  --name my-web-app \
  --slot staging \
  --target-slot production

Slots also support “sticky settings” — app settings that do not swap with the slot. Use sticky settings for slot-specific configuration like connection strings or environment names that should stay with each slot rather than moving to production when you swap.