Azure Container Apps Express in 2026 and Where Its Preview Gap Still Sends You Back
In this article
- What Express Actually Is
- Express Compared to a Standard Container Apps Environment
- The Preview Feature Gap
- Enterprise blockers
- Platform-pattern blockers
- Workload-shape blockers
- The Agent-Backend Angle
- Region Availability and the EU Consequence
- Where This Fits in the Wider Container Hierarchy
- The Migration Footnote
- Where This Leaves Architects Today
In short: Azure Container Apps Express, announced at Build 2026, removes the environment-provisioning step and gives HTTP apps subsecond cold starts on a default public ingress endpoint. The preview feature gap is wide (no VNet, managed identity, custom domains, Dapr, jobs, multi-revision, GPU) and Express is only in West Central US and East Asia. Use it today for prototypes, internal dashboards, and ephemeral agent backends; standard Container Apps still owns production microservices in regulated environments.
At Build 2026, Microsoft announced Azure Container Apps Express as a new public-preview environment tier inside Azure Container Apps. The promise: bring a container image and have an HTTP app on a default public ingress endpoint in seconds, with subsecond cold starts from prewarmed pools.
Two things make Express more than a marketing rebrand. First, the underlying compute layer is new. Express runs on Azure Container Apps Sandboxes, a platform layer with prewarmed capacity pools, strong tenant isolation, and a streamlined data plane. Second, Express ships with a separate management UI at containerapps.azure.com, distinct from the standard Azure portal experience.
The preview feature gap is significant, and so is the region constraint. Express is faster for a focused set of workloads. For most production cases today, a standard Container Apps environment is still the right place to land.
What Express Actually Is
Express is a streamlined Container Apps environment tier purpose-built for HTTP-first web workloads. It removes the “create an environment, then deploy an app” two-step that has been part of Container Apps since GA. When you use the new portal, the environment is created for you and treated as a lightweight app grouping rather than an infrastructure boundary. When you use the CLI, you still create an environment with --environment-mode express, but provisioning completes in seconds rather than minutes.
The compute model is consumption-only. You pay per-second for vCPU and memory while the app is serving requests, and the free grant for consumption workloads applies to Express too. There is no per-environment management fee and no separate load balancer charge. This matches the billing shape of a public-ingress consumption environment in standard Container Apps, without the Dedicated Plan Management fee that workload-profile environments carry once features such as VNet integration or private endpoints are turned on. Scale-from-zero is built in, with cold start optimised by the Sandboxes layer underneath.
Express supports Linux containers built for linux/amd64, pulled from any registry that allows anonymous or token-based access. There are no special base-image requirements.
Express Compared to a Standard Container Apps Environment
The internal ACA-family comparison matters more than the cross-platform one. The two tiers run on the same service, share the same CLI, and produce the same kind of artifact, but the operational model is different.
| Dimension | Express | Standard Container Apps environment |
|---|---|---|
| Environment provisioning | Seconds, often invisible in portal flow | Minutes, explicit step |
| Cold start | Subsecond from prewarmed pool | Standard consumption cold start |
| Configuration surface | Opinionated defaults, minimal knobs | Full knobs across consumption and dedicated profiles |
| Compute | Consumption only | Consumption and dedicated workload profiles, including GPU |
| Protocol support | HTTP only | HTTP and TCP |
| Networking | Public default ingress domain only | VNet integration, internal environments, private endpoints |
| Identity | Not yet available | Managed identity for runtime and image pull |
| Service discovery between apps | Not yet available | Built-in internal FQDN and Dapr service invocation |
| Multi-revision and traffic splitting | Not yet available | Supported, used for blue-green and canary |
| Jobs and batch | Not supported | Supported via Container Apps Jobs |
| Management UI | containerapps.azure.com | Azure portal |
| Pricing | Per-second consumption, scale-to-zero, free grant applies | Per-second consumption or dedicated profile billing |
For prototypes, dev environments, and HTTP APIs that do not yet have enterprise networking, identity, or revisioning requirements, Express is the more pleasant tier. For anything that needs VNet integration, managed identity, traffic splitting, or jobs, the standard environment is still the only choice.
The Preview Feature Gap
The documented Express overview is explicit about which features are available today and which are marked “in development.” The list is long enough that calling Express production-ready depends entirely on the workload. Grouping the gap by decision impact makes the trade-off clearer than one flat list.
Enterprise blockers
These are the capabilities most production deployments inside a regulated organisation cannot run without.
| Capability | Status in Express today | What its absence forces |
|---|---|---|
| VNet integration, private endpoints | In development | Standard environment with workload profiles |
| Managed identity (runtime and image pull) | In development | Standard environment |
| Custom domains, BYOC certificates | In development | Standard environment, or Front Door / Application Gateway in front |
| Easy Auth, IP restrictions, CORS | In development | Standard environment, or a fronting service |
| OpenTelemetry, Azure Monitor metrics | In development | Standard environment |
| Zone redundancy, peer-to-peer encryption | In development | Standard environment |
Platform-pattern blockers
These are the building blocks ACA users typically rely on for service-to-service composition.
| Capability | Status in Express today | What its absence forces |
|---|---|---|
| Dapr integration | In development | Standard environment |
| Service discovery between apps (internal FQDN, Dapr invocation) | In development | Standard environment |
| Multi-revision and traffic splitting | In development | Standard environment |
| KEDA-based custom autoscaling rules | In development | Standard environment (Express scales from zero, but custom KEDA scalers are not yet authorable) |
| Health probes | In development | Standard environment |
Workload-shape blockers
These are the capabilities that simply rule out certain workload types on Express today.
| Capability | Status in Express today | What its absence forces |
|---|---|---|
| Container Apps Jobs | In development | Standard environment |
| GPU compute | In development | Standard dedicated workload profiles with serverless GPUs |
| Sidecars, init containers, volume mounts, Azure File storage | In development | Standard environment |
| TCP workloads, additional ingress ports | Not on the roadmap during preview | Standard environment |
The gap is being closed on a rapid cadence and Microsoft’s express FAQ describes new features shipping throughout preview. The architect’s call today is whether the workload tolerates the gap until the relevant capability lands. For a throwaway demo, the answer is yes. For an internal corporate API that must terminate inside a VNet and authenticate via managed identity, the answer is no.
The Agent-Backend Angle
Microsoft positions Express for two audiences: developers shipping fast and agent runtimes that deploy on demand. The second audience is new and worth taking seriously. Model Context Protocol (MCP) servers, tool-use endpoints, multi-step workflow APIs, and human-in-the-loop UIs share a profile that classic web hosting does not handle well: instant provisioning, instant teardown, unpredictable bursts, and short-lived endpoints that may exist for minutes rather than months.
Express maps to that shape because Sandboxes underneath provide the prewarmed capacity. Whether an organisation calls those workloads “agentic” or just “ephemeral HTTP endpoints” matters less than the platform behaviour required. Express today is one of the cleaner Azure-native ways to host that pattern, particularly when the alternative is provisioning a full environment or a job runner for an endpoint that will not exist next week.
The caveat is that the same preview gap applies. Agent backends that need managed identity to call Azure Key Vault, that need to terminate inside a VNet, or that need Dapr pub/sub for tool orchestration still need a standard environment. The model-side placement decision (Azure OpenAI Service, Azure AI Foundry, third-party endpoints) sits one layer up and is covered separately in Azure AI enterprise architecture in 2026; Express is the runtime answer for the lightweight HTTP layer in between.
Region Availability and the EU Consequence
During public preview, Express is available only in West Central US and East Asia. Region expansion is on the roadmap, but the current list excludes every European region.
For EU-based organisations, that is a hard stop on production use. Data-residency policies, GDPR considerations, and the broader cloud sovereignty conversation all push EU workloads to EU regions. An Express deployment in West Central US is fine for a prototype hosted by a developer in the US time zone. It is not a viable production option for a Belgian or French organisation today, regardless of how compelling the cold-start numbers are.
Region availability is the simplest reminder that 2026 platform choices include “where does this run” as a primary architecture question. The Express region constraint will close, and when it does, region selection will still be the first procurement-defensible decision the architect makes.
Where This Fits in the Wider Container Hierarchy
The 2022 Container Apps vs AKS vs App Service framework still holds for the broader spectrum. Express adds a faster on-ramp inside the Container Apps family. It is another environment tier inside an existing platform category.
For the AKS side of the decision, including AKS Automatic and the operational reality of running a cluster as a platform product, the AKS in 2026 piece covers what changed and when AKS still wins. Express does not displace that decision. A workload that needs the Kubernetes API still needs the Kubernetes API.
The useful mental model is that the choice now runs along a longer continuum: from App Service for traditional web hosting, through Express for HTTP-first ephemeral and prototype workloads, to a standard Container Apps environment for production microservices with enterprise networking and identity, to AKS Automatic where the Kubernetes API is required but operational simplicity matters, to AKS Standard or Premium where the platform team owns the cluster. Each step adds capability and adds operational responsibility, and the right placement depends on which dimensions the workload actually requires.
The Migration Footnote
Microsoft is performing phased migrations of some existing Container Apps environments to Express. The criteria documented in the Express FAQ prioritise inactive environments with no running apps or jobs, environments that do not use advanced features such as VNet, Dapr, or dedicated workload profiles, and subscriptions with low Container Apps usage. Migration carries up to 15 minutes of downtime, with advance notification and an opt-out path for environments that would lose functionality.
Self-migration is available through the archive-and-restore mechanism for organisations that want to move on their own schedule. For most production Container Apps users with VNet-attached environments, managed identity, Dapr, or workload profiles in use, automatic migration will not fire and self-migration would require explicit reassessment of the supported feature list first.
Migration is a feature-compatibility review, and it deserves the same care as a runtime upgrade for Azure Functions Flex Consumption. A silent platform move can land as a loud production problem for the operator on call when a dependency breaks.
Where This Leaves Architects Today
Express is a real improvement on the developer experience for the workloads it covers. Subsecond cold starts, no environment provisioning step, scale-to-zero, and consumption pricing with the existing free grant make it the cleanest Azure-native option for HTTP-first prototypes, internal dashboards, and ephemeral agent endpoints.
The preview gap and the region constraint together rule out most enterprise production deployments today. A workload that needs VNet, managed identity, custom domains, Dapr, multi-revision, jobs, or simply an EU region cannot live on Express in mid-2026.
Use Express where it fits today, watch the supported-feature list closely as Microsoft ships against the gap, and reassess greenfield placements in three to six months. For everything else, the existing decision boundary still holds: standard Container Apps for production microservices that do not need the Kubernetes API, AKS Automatic when the API is required but operational simplicity matters, AKS Standard or Premium when the team owns the cluster as a product. Express adds a faster lane for the easy end of the spectrum without changing the placement rules for everything else.
If your team is weighing where a new workload should land across Container Apps Express, standard Container Apps, AKS Automatic, AKS Standard or Premium, App Service, or Azure Functions, we help Azure-first organisations run a structured runtime placement review and produce a written placement decision the team and procurement can both defend. Get in touch about an Azure runtime placement review.
Related: Azure Container Apps vs AKS Decision Framework the broader 2022 framework that Express now extends · AKS in 2026 and When It Still Wins the cluster-ownership end of the spectrum · AKS Production Lessons what running Kubernetes as a platform product actually costs · Dapr Graduates CNCF the building-block model Express does not yet support · KEDA Graduates CNCF the autoscaling foundation Express uses but does not yet expose for custom scalers · Azure AI Enterprise Architecture in 2026 the model-side placement layer above Express agent backends · Cloud Sovereignty Classification where runtime placement meets sovereignty tiering.
