Cloud Parts

Azure App Service

Azure’s platform for web apps and APIs: you rent a pool of VMs called an App Service plan, and every app you put in it runs on those VMs without you managing them.

What it is
Platform as a service (PaaS)
Type
Managed service on Azure
Made by
Microsoft
License
Proprietary
Facts checked
12 October 2026
Website

What it is

App Service runs web apps, REST APIs and mobile back ends written in .NET, Java (SE, Tomcat or JBoss), Node.js, Python or PHP, on Windows or Linux, or any app packaged as a custom container. Every app lives in an App Service plan, which fixes the region, the operating system, the pricing tier and the number and size of VM instances. You pay for the plan’s instances, not per app: all apps in a plan, plus their deployment slots, backups and WebJobs, share the same VMs and scale out together.

The tier sets what you get. Free and Shared run your app on VMs shared with other customers under a CPU quota and can’t scale out. Basic, Standard and the Premium tiers give the plan dedicated VMs (up to 3, 10 and 30 instances, the last on Premium v2 to v4), and IsolatedV2 runs them in an App Service Environment on a dedicated virtual network. From Standard up, deployment slots let you deploy to a live staging copy with its own hostname, warm it up, and swap it into production without dropping requests; swapping again rolls back.

Two features need no code. Built-in authentication, often called Easy Auth, signs users in through Microsoft Entra, Google, Facebook or X before requests reach your app. Scaling can be rule-based autoscale on CPU, memory or a schedule (Standard and up), or automatic scaling (Premium v2 to v4), where the platform adds instances as HTTP traffic grows and keeps prewarmed ones ready.

Why teams pick it

  • One plan can host many apps at no extra cost per app, and custom domains, SNI TLS certificates and deployment slots are free
  • Deployment slots (5 per app on Standard, 20 on Premium and Isolated) give zero-downtime releases and one-step rollback
  • Sign-in through Microsoft Entra, Google, Facebook or X with no SDK or code changes
  • Windows and Linux, code or containers, plus a Managed Instance option for legacy Windows apps that need COM, registry access or MSI installers

Watch out for

  • On dedicated tiers you pay for every VM instance in the plan whether its apps are busy or idle; there is no scale to zero
  • Apps in one plan share the same VMs, so a busy app slows its neighbors; isolating an app means giving it its own plan
  • Free and Shared get 60 and 240 CPU minutes a day, run on VMs shared with other customers, and can’t scale out
  • Deployment slots and autoscale start at Standard, automatic scaling at Premium v2, and Basic stops at 3 instances

Alternatives

What all platform as a service (paas) have in common →
AWS Elastic BeanstalkAWSUpload your code and Elastic Beanstalk builds the AWS setup to run it (EC2 instances, a load balancer, an Auto Scaling group) in your own account, where you can still see and change every piece.Cloud FoundryOpen sourceAn open-source PaaS you run yourself: `cf push` uploads your code, a buildpack stages it into a droplet, and Diego keeps the requested number of instances running behind the Gorouter.DokkuOpen sourceA Heroku-like PaaS on one server of your own: `git push` to it, and Dokku builds the app with buildpacks or a Dockerfile and runs it in Docker containers behind nginx.Fly.ioCommercialFly.io turns your Docker image into fast-booting Firecracker microVMs on its own servers in regions around the world, and routes each user to the nearest one.Google App EngineGoogle CloudGoogle’s original platform as a service: describe your app in an `app.yaml`, run one deploy command, and Google runs and scales the instances.HerokuCommercialThe platform that defined PaaS: `git push` your code, and Heroku builds it with a buildpack and runs it on managed containers called dynos behind its own HTTP router.RenderCommercialRender builds and deploys web services, background workers, cron jobs and managed Postgres and Key Value stores from your Git repo, all described in one `render.yaml` file if you like.

How it fits with other technologies

Deploy with the Azure CLI, then release through a staging slot · bash

# Creates the plan and the app, then zip-deploys the current folder
az webapp up --name shop-api --resource-group shop-rg \
  --runtime "PYTHON:3.14" --plan shop-plan --sku S1

az webapp deployment slot create --name shop-api \
  --resource-group shop-rg --slot staging
# ...deploy the next release to the staging slot, test it, then:
az webapp deployment slot swap --name shop-api \
  --resource-group shop-rg --slot staging --target-slot production

See it in a real stack

No architecture uses Azure App Service yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2012–2017

On June 7, 2012, Scott Guthrie announced Windows Azure Web Sites, a simpler way to deploy ASP.NET, Node.js and PHP sites that could “start small (and for free) and then scale up” as traffic grew. Up to 10 sites ran free in a shared, multi-tenant environment, and you could move them to a “reserved mode” where you were the only customer on the VM. Deploys came from FTP, Git, TFS or Web Deploy, and a new site was ready to deploy to in under 10 seconds.

Web Sites became generally available with an SLA on June 27, 2013, alongside new autoscale support. On March 24, 2015, Microsoft folded Azure Websites and Azure Mobile Services into a single product, Azure App Service, and added Logic Apps and API Apps. Web Apps kept all of Websites’ capabilities at the same price and was generally available from day one, while the other app types started in preview.

In September 2017 App Service became generally available on Linux too, with built-in images for ASP.NET Core, Node.js, PHP and Ruby, together with Web App for Containers, which deploys your own Docker image.

Why it’s built this way

A free shared tier with a paid reserved tier above it
Guthrie pitched Web Sites as a way to start a project at no cost on shared servers, then move to dedicated VMs and add instances as traffic grew, with the same deployment options at every size.
Pay for the VMs, not per app
With App Service, Guthrie wrote, you could create any number of web, mobile, logic and API apps and run them on one App Service deployment at no additional cost. The plan is still the unit you pay for.
Deploy the way developers already worked
From the start Web Sites accepted FTP, Git, TFS and Web Deploy, and Visual Studio and WebMatrix could publish directly, so existing ASP.NET and PHP teams could keep the tools they had.

Timeline

  1. 2012

    Windows Azure Web Sites announced on June 7 for ASP.NET, Node.js and PHP

  2. 2013

    Web Sites generally available with an SLA, plus autoscale

  3. 2015

    Websites and Mobile Services merge into Azure App Service on March 24

  4. 2017

    App Service on Linux and Web App for Containers generally available

Sources9 · facts checked 12 October 2026

Improve this page on GitHub