Builder versus Azure PaaS
App Service Builder is a source-defined preview experience: describe the app in builder.yaml, build a version, and deploy it.
Current quickstarts use authorized GitHub source.
Its documented surface is deliberately narrower than regular Azure App Service or Azure Container Apps.
Similar product names and shared Azure concepts do not imply feature parity.
Choose by application model
Start with your workload and required level of control. This flowchart is a readable decision path, not an exclusive product recommendation. For production workloads, choose an appropriately supported service rather than Builder Private Preview.
- 1. Do you need Kubernetes APIs and cluster-level control?
If not, continue to the next question.
Yes: consider
Azure Kubernetes Service (AKS)Managed Kubernetes with control over workloads and cluster configuration.
- 2. Are you creating isolated environments for executing code?
If not, continue to the next question.
- 3. Is your application organized around event handlers?
If not, continue to the next question.
- 4. Do you need a frontend-focused service with staging and integrated APIs?
If not, continue to the next question.
- 5. Are you trying a source-defined static or HTTP app in development/test?
If not, continue to the next question.
Yes: consider
App Service Builder Private PreviewCheck preview access and supported scope. Do not deploy production workloads.
- 6. Do you need established managed web hosting from code or a container?
If not, continue to the next question.
- 7. Are you bringing container images for HTTP apps or microservices?
If none fit, review the options with your requirements.
Yes: consider
Azure Container Apps express or Container AppsConsider express for streamlined HTTP hosting; standard Container Apps for environments, microservices, and jobs.
| Offering | What you manage | A good starting point when |
|---|---|---|
| App Service Builder | Application source, an app manifest, built versions, deployments, and app configuration | You are in the approved preview and want a development/test static site, HTTP app, or combined static-plus-web app within the documented limits |
| Azure App Service | A web app, its hosting plan, runtime or container, deployment configuration, and service features | You need established managed web hosting and its broader web-app feature set |
| Azure Container Apps | Container apps, revisions, an environment, ingress, and scale rules; jobs for background execution | You want container-oriented services, multiple microservices, event-driven scaling, or scheduled/event-driven jobs |
| Azure Container Apps express | A container-image HTTP app with opinionated defaults and a streamlined app-centric experience | You bring a container image and want managed HTTP hosting and scale-to-zero without the full standard Container Apps workflow |
| ACA sandboxes | Isolated, on-demand execution environments and their lifecycle | You need agent/code execution, development environments, or disposable compute rather than a published web app |
| Azure Kubernetes Service (AKS) | Kubernetes workloads and cluster configuration through Kubernetes APIs | You need cluster-level control, Kubernetes ecosystem tooling, or workload orchestration beyond a web-app abstraction |
| Azure Functions | Functions, event triggers, bindings, and hosting configuration | Your workload is organized around event handlers rather than a continuously running web process |
| Azure Static Web Apps | A frontend repository, build configuration, static content, and integrated or linked APIs | You want a frontend-focused workflow with globally distributed static content and repository-driven deployment |
These are application-model comparisons, not pricing, performance, SLA, or migration guarantees. Features in established services depend on their plan, configuration, and region.
Builder and regular App Service
Both can host web applications, but their customer workflows differ. Builder's manifest describes what to build and serve; a built version separates source/build readiness from deployment activation. Regular App Service offers code or custom-container deployment and a broader set of hosting, networking, domain, and deployment options.
Choose regular App Service when requirements depend on its documented features, such as custom domains, deployment slots, or VNet integration, with the applicable plan. Those are not supported Builder customer workflows in this preview. Do not treat a Builder built version as an App Service deployment slot, or assume App Service plan settings carry over.
Builder and Container Apps
Builder's source workflow produces the supported static and web outputs without asking you to design a Container Apps environment. It permits at most one static output and one public compute output per app. Scale web apps using a CPU utilization target, a memory utilization target, or both. A positive minimum keeps instances running. You can also opt into HTTP scaling with a positive minimum or let an image-backed app sleep with minimum zero. See the scaling guide for runtime prerequisites and request-interruption risks.
Container Apps is a better starting point for container-oriented microservices, customer-defined traffic-based or event-driven scaling rules, and jobs. Builder does not expose custom HTTP/event scaling rules or background jobs as supported preview workflows. Builder apps can use system-assigned and user-assigned managed identities to call Azure services. Databases, caches, and private networking are not provisioned automatically.
For a simpler container-image HTTP app, consider Azure Container Apps express. Its opinionated experience differs from Builder's source build workflow and from the full Container Apps feature set. Express currently documents VNet egress and environment private endpoints; those features do not become Builder networking options. Check its own supported features and limitations rather than assuming parity with standard Container Apps.
Isolated execution and Kubernetes control
ACA Sandboxes targets on-demand isolated microVMs for code execution and development environments. That is a different application model from ordinary Container Apps hosting and from Builder's web-app workflow. Do not choose Builder on the assumption that it offers a sandbox execution API, interactive shell, snapshots, or suspend/resume.
AKS provides a managed Kubernetes service for workloads that need Kubernetes APIs and control over cluster configuration. That brings a different operating model and responsibilities from Builder's manifest/build/deployment abstraction. Use AKS when that control is a requirement, not because a Builder web app happens to run on cloud compute.
Builder, Functions, and Static Web Apps
Choose Functions when event triggers and bindings are central to the application. A Builder HTTP endpoint does not turn a web process into the Functions programming model or add queue-triggered background execution.
Choose Static Web Apps when its frontend deployment model, globally distributed static content, pull-request staging, or integrated API workflow is the requirement. Builder can also publish static content and compose it with one web output, but a GitHub source connection does not enable automatic push deployment. Do not infer Static Web Apps features from the presence of a Builder static output.
For an existing Static Web Apps application, use the Builder evaluation guide to inventory required features and test an isolated development/test copy. This is a preview assessment, not a production migration or cutover procedure.
Before committing to a platform
Check Builder's supported scope, recognized runtimes and build shapes, and your approved preview target. Use the sample catalog to try a focused app shape. Cost describes the initial no-charge preview and separately billed dependencies. Confirm region availability with your preview contact before choosing a target.