Azure Container Apps
Azure Container Apps runs containers as a serverless service: you deploy images, set scale rules and ingress, and Azure runs the underlying Kubernetes, Dapr, KEDA and Envoy for you. Apps can scale to zero, run jobs, use serverless GPUs, and give AI agents sandboxed code execution through dynamic sessions.12
Also known as ACA, Container Apps
- Intended for
- Application developers, Teams building microservices and APIs, AI engineers hosting small models or agent tools, Platform teams that want containers without running Kubernetes
- Runs on
- Azure public regions, Azure Container Apps on Azure Arc-enabled Kubernetes (custom locations)3
At a glance
- What is it?
- Azure Container Apps is a managed platform for running containerized applications and jobs without managing servers or a Kubernetes cluster. Microsoft builds it on Kubernetes and open-source projects (Dapr, KEDA and Envoy) but does not expose the Kubernetes API. You work with container apps, revisions, environments and jobs. It offers a Consumption plan (serverless, pay for what runs) and a Dedicated plan made of workload profiles with dedicated hardware.24
- What does it do?
- Container Apps deploys containers from any public or private registry, exposes HTTPS or TCP ingress, and scales replicas on HTTP traffic, events, CPU or memory, or any KEDA scaler, often down to zero. It runs on-demand, scheduled and event-driven jobs, hosts Azure Functions, splits traffic across revisions for blue/green or A/B releases, offers internal service discovery, secrets and Log Analytics logging, and can join your own virtual network. Serverless GPUs (NVIDIA A100 and T4) add on-demand GPU compute, and dynamic sessions provide Hyper-V isolated sandboxes for running untrusted or AI-generated code.1
- Who needs it?
- Developers who want to ship APIs, web back ends, background workers and microservices in containers without operating a cluster; teams with spiky or event-driven load that benefits from scale to zero; and AI teams that need a place to run small open models on GPUs or to execute code generated by an agent in an isolated sandbox. Microsoft's agent guidance names Container Apps with serverless GPUs as a good option for small language models, and Container Apps or AKS for hosting agents with a custom orchestration framework.5
- What does it need?
- An Azure subscription
- A container image in a registry (Docker Hub, Azure Container Registry or another registry)
- Azure CLI with the containerapp extension, the Azure portal or ARM/Bicep templates
- For serverless GPUs: a workload profiles environment in a supported region and GPU quota (enabled by default for Enterprise Agreement and pay-as-you-go customers)
- Optionally an existing virtual network for private networking
- What it is not
- Container Apps is not a managed Kubernetes cluster: you cannot use kubectl against it or install arbitrary cluster add-ons. If you need the Kubernetes API, Microsoft points to AKS. It is not limited to web apps (App Service focuses there) and is not only a functions service, although it can host Azure Functions. Scale to zero does not apply to apps that scale on CPU or memory load. Serverless GPUs are not general GPU clusters: one container per app gets the GPU, and multi-GPU or fractional GPU replicas are not supported.16
Availability and licensing. Generally available (checked 26 October 2026). Serverless GPUs are offered in listed regions, with GPU quota on by default for EA and pay-as-you-go. Foundry models on serverless GPUs are in public preview. The GPU stack moves to driver 580 and CUDA 13.x from 23 May 2026 at the earliest. The product page lists a monthly Consumption free grant per subscription (180,000 vCPU-seconds, 360,000 GiB-seconds, 2 million requests), a 99.95% SLA, Dedicated, Flexible and Savings plans, and a new Container Apps Sandboxes offering not yet described in the Learn plan article.67
The problem it solves
Many teams want the benefits of containers and Kubernetes-style patterns (service discovery, revisions, autoscaling on events) but do not want to staff a platform team to run clusters, ingress controllers, autoscalers and upgrades.
Container Apps provides those patterns as a managed service. You describe the app and its scale rules, and the platform handles the infrastructure underneath, including GPU nodes when you ask for them.
How it works
You create an environment, which is the secure boundary and network for a group of apps, and choose a plan:
- Consumption: serverless, apps scale in and out on demand and you pay for running apps.
- Dedicated: workload profiles with general purpose, memory-heavy or GPU hardware, billed per profile instance, with single-tenant isolation. Serverless GPUs run on consumption GPU workload profiles in a workload profiles environment.
Inside an environment, each container app has revisions (immutable versions you can split traffic across), scale rules based on KEDA, optional ingress and Dapr sidecars. Jobs run to completion on demand, on a schedule or from events. Session pools keep prewarmed, isolated sandboxes ready; requests carrying a session identifier are routed to a session that is destroyed after a cooldown period.48
Diagram as a list
Copilot & business apps
- Users, APIs and event sourcesSend HTTP requests or events (queues, Kafka and other KEDA sources)
Agents & automation
- Dynamic session poolsHyper-V isolated sandboxes for AI-generated or untrusted codeConnects to Environment with Consumption or Dedicated workload profiles
Data & analytics
- Azure Log AnalyticsStores app logs for monitoring
Developer tools
- Container apps and revisionsRun your containers, with optional Dapr sidecarsConnects to Environment with Consumption or Dedicated workload profiles
- Container Apps jobsRun tasks to completion on demand, on schedule or from eventsConnects to Environment with Consumption or Dedicated workload profiles
Cloud & hybrid infrastructure
- Ingress (HTTPS or TCP, Envoy-based)Routes external or internal traffic to app revisionsConnects to Container apps and revisions
- KEDA scale rulesAdd or remove replicas based on traffic and events
- Environment with Consumption or Dedicated workload profilesNetwork and compute boundary, including consumption GPU profiles
- Container registrySupplies images (artifact streaming in Premium ACR speeds GPU cold start)
Capabilities
Event-driven autoscaling and scale to zero1
Scale on HTTP traffic, events, CPU, memory or any KEDA-supported scaler; most apps can scale to zero.
Why it matters: Spiky or idle workloads do not pay for idle replicas on the Consumption plan.
Limits: Apps that scale on CPU or memory cannot scale to zero.
Revisions and traffic splitting1
Each change creates a revision, and traffic can be split across revisions.
Why it matters: Supports blue/green releases and A/B tests without extra tooling.
Limits: Managing many active revisions adds cost and complexity.
Jobs2
Containers that run to completion on demand, on a schedule or in response to events.
Why it matters: Batch and background processing share the same platform as apps.
Limits: Long-running stateful services belong in apps, not jobs.
Dapr and Functions hosting1
Built-in Dapr APIs for microservices and the ability to run Azure Functions with triggers and bindings.
Why it matters: Teams get service invocation, state and pub/sub patterns without running Dapr themselves.
Limits: No direct access to the underlying Kubernetes APIs to customize Dapr or the cluster.
Serverless GPUs6
On-demand NVIDIA A100 or T4 GPUs with per-second billing and scale to zero.
Why it matters: A middle path between serverless model APIs and dedicated managed compute for running your own model.
Limits: One GPU-using container per app, no multi or fractional GPU replicas, limited regions, and quota is required.
Foundry models on serverless GPUs (preview)6
Deploy supported Microsoft Foundry models (MLFLOW type) directly to serverless GPUs.
Why it matters: Teams can run catalog models inside their own container boundary.
Limits: Public preview; only certain model types are supported.
Dynamic sessions8
Prewarmed, Hyper-V isolated sandboxes from session pools, as code interpreter or custom container pools.
Why it matters: Agents can run model-generated or user-submitted code without touching production systems.
Limits: Sessions are short-lived and available in listed regions only.
Practical use cases
A set of small services and APIs needs hosting, but the team has no Kubernetes operators.
- Approach
- Deploy each service as a container app in one environment with internal ingress and service discovery.
- Role of Azure Container Apps
- Container Apps runs, scales and routes the services.
- Data, infrastructure and skills
- Container images and an Azure subscription.
- Type of benefit
- Lower operations effort
- Caveats
- No Kubernetes API access; move to AKS if you later need it.
- First step
- Deploy two services and call one from the other through internal ingress.
An agent needs to run Python that the model writes, without risking production systems.
- Approach
- Give the agent a code interpreter session pool and route each conversation to its own session.
- Role of Azure Container Apps
- Dynamic sessions provide isolated, short-lived sandboxes.
- Data, infrastructure and skills
- A session pool in a supported region and agent code that calls the pool endpoint.
- Type of benefit
- Risk reduction
- Caveats
- Sessions are ephemeral; persist results elsewhere.
- First step
- Create a code interpreter session pool and run a test snippet through its API.
A team wants to serve a small open model only during working hours.
- Approach
- Run the model container on serverless GPUs with scale to zero.
- Role of Azure Container Apps
- Container Apps supplies GPUs on demand and bills per second.
- Data, infrastructure and skills
- GPU quota in a supported region and a serving image.
- Type of benefit
- Cost control
- Caveats
- Cold starts on first request; large models may need AKS.
- First step
- Deploy the model on a T4 profile and measure cold start with artifact streaming on.
Works with
Optional integration
- Microsoft Foundry ModelsSupported Foundry models can be deployed to Container Apps serverless GPUs (public preview).
- Azure ArcContainer Apps can be deployed as a cluster extension on Azure Arc-enabled Kubernetes through custom locations.
Alternative approaches
- Azure Kubernetes Service (AKS)Microsoft recommends AKS when you need direct Kubernetes API access; Container Apps otherwise.
- Azure GPU virtual machinesMicrosoft suggests Container Apps with serverless GPU for small language models.
- Microsoft FoundryMicrosoft's agent guidance presents GPU-backed containers as a third build path next to Foundry when you want to run your own models.
- Microsoft Foundry ModelsMicrosoft suggests Container Apps with serverless GPU for hosting your own small models.
Optional integration for
- Azure ArcContainer Apps on Azure Arc can be deployed to custom locations on Arc-enabled clusters.
Relationship labels follow Microsoft's documentation. "Alternative approaches" does not mean one is better: each profile says when it fits.
Compared with
Getting started
Deploy a first app
Use the quickstart with the Azure CLI or portal to deploy a public sample image with external ingress.
Check: The app URL responds and the revision shows as running.
Add scale rules
Configure an HTTP or event-based KEDA rule and a minimum replica count of zero if the workload can tolerate cold starts.
Check: Replica count drops to zero when idle and rises under load.
Choose a plan
Stay on Consumption for variable load; add Dedicated workload profiles when you need isolation, larger sizes or steadier throughput.
Check: Workload profile assignments match the app's resource needs.
Try a GPU model (optional)
Create a workload profiles environment in a GPU region, confirm A100 or T4 quota, and deploy a model image or a supported Foundry model with az containerapp up.
Check: The GPU app serves requests and scales back to zero when idle.
Official resources
Deciding whether you need it?
Three free tools apply Microsoft's own published guidance to your situation, and say when Azure Container Apps or any new technology is not needed.
Sources
Each statement above links to the source it comes from. Labels say who reported it.
- Azure Container Apps overview (opens in a new tab)
- Comparing Container Apps with other Azure container options (opens in a new tab)
- Azure Arc overview (opens in a new tab)
- Azure Container Apps plan types (opens in a new tab)
- Technology plan for AI agents (Cloud Adoption Framework) (opens in a new tab)
- Using serverless GPUs in Azure Container Apps (opens in a new tab)
- Azure Container Apps product page (opens in a new tab)
- Dynamic sessions in Azure Container Apps (opens in a new tab)
- microsoft/azure-container-apps repository (opens in a new tab)
Thank you. Your correction was sent.
The editors check it against the sources. If you left an email address, they may reply about it.