Microsoft recently made Azure Container Apps Express generally available, a deployment model that removes the environment provisioning step and replaces most configuration with opinionated defaults. It ships alongside the general availability of Azure Container Apps Sandboxes, the isolated compute layer Express runs on. The pairing follows the same shape Google shipped in Kubernetes Engine this year.
Express takes a container image, a region, and whatever configuration the app needs, then provisions the compute, ingress, and scaling itself. Apps run on consumption CPU with per-second billing, scale to zero when idle, and carry no environment provisioning fee. Microsoft describes Express as developer-first and agent-first, and makes the second part explicit:
AI-assisted workflows can create and update apps far faster than anyone can configure infrastructure by hand.
The speed comes from underneath. Microsoft's documentation states that Express is built entirely on Container Apps Sandboxes, a platform primitive that provisions from prewarmed pools for subsecond startup, isolates each workload in its own hardware-isolated microVM boundary, and bursts to thousands of concurrent sandboxes. Sandboxes also support suspend and resume, snapshotting full state including memory and disk, with sub-second restore.
Developers can use Sandboxes directly rather than through Express, which Microsoft positions for agent platforms and secure code-execution services. The top-level ARM resource is Microsoft.App/SandboxGroups, described as a management boundary for sandboxes sharing configuration, comparable to a Container Apps environment.
Reaction on Reddit suggests the primitive was in use well before the announcement. Commenter MuhBlockchain offered a detail Microsoft's own material does not state:
ACA Sandboxes actually underpin a lot of core Azure services including Foundry Hosted Agents.
Others described their own deployments. Commenter tankerkiller125real wrote that his team uses them for Python sandboxes for a customer facing agent harness. Commenter Minute_Passion_8077 described deploying them for clients through Bicep:
Just point it to an image and off you go. Dont need it? Scale to 0.
Asked how Sandboxes differ from Container Apps jobs, commenter brianveldman drew the line at lifecycle:
ACA Jobs are designed for run to completion tasks and batch processing (start to run to complete), while Sandboxes provide programmable, isolated compute environments with lifecycle control.
Not everyone was convinced by the isolation claim. Commenter RustOnTheEdge responded to the hardware-isolated microVM description with open skepticism, though without elaborating. One question went unanswered: commenter HgnX asked whether the same capability is available in Azure Kubernetes Service, noting that his team runs AKS because of requirements Container Apps does not meet.
That combination is recognizable. Google Kubernetes Engine pairs Pod snapshots, which checkpoint CPU and GPU memory through gVisor, with GKE Agent Sandbox for running untrusted agent code. Microsoft now pairs microVM isolation with snapshot-based suspend and resume, aimed at the same workloads. Both vendors are answering the same question: how to give an agent an isolated environment that costs nothing while idle and returns in under a second.
Express itself is the opinionated application layer on top, offering a focused subset of Container Apps capabilities: scale to zero, multiple replicas, HTTP ingress on a Microsoft-managed domain, environment variables, manual secrets, IP restrictions, log streaming, and autoscaling on HTTP, CPU, or memory rules.
The exclusions define where it stops. Express does not support custom domains, zone redundancy, Key Vault secret references, Easy Auth, OpenTelemetry, Dapr, jobs, workload profiles, GPU workloads, multiple revisions and traffic splitting, or system-assigned managed identities. Service discovery is absent, so apps communicate through their public URLs, and ingress is HTTP only. Microsoft's documentation carries the full list, along with constraints on outbound subnets, which cannot be changed once set, and on per-replica storage.
Microsoft is direct about the boundary, advising a standard environment where teams need greater control over networking, GPU compute, advanced configuration, or environment-level capabilities such as Dapr. The documentation nonetheless also lists rapid prototyping as a case where teams build quickly and then keep running in production without replatforming. For a workload needing a custom domain, zone redundancy, or Key Vault-backed secrets, those two statements pull in different directions.
Access is also narrower than standard Container Apps. Express requires a Microsoft Entra ID-backed account, and personal Microsoft accounts are not supported. Management happens through specialist interfaces rather than the Azure portal: containerapps.azure.com for Container Apps and sandboxes.azure.com for Sandboxes. Asked whether those replace the portal, MuhBlockchain said they do not:
It's just a separate view, though with a lot more detail. You'll still be able to manage them through the regular portal experience to.
Teams already running standard environments have a migration path, and a nudge. Self-migration works through archive and restore: archive the existing environment, then restore it as an Express environment. Microsoft says the process preserves app and environment configuration, takes about 15 minutes, and does not change the consumption-free grant. The FAQ also mentions an opt-out form in the migration notice for organizations needing additional approval or coordination, and notes that inactive environments, meaning those with no running apps or jobs and no recent activity, may be archived and put to sleep.
At general availability, Express reaches more than 40 Azure regions, covering almost every public region where Container Apps is offered. Microsoft says thousands of Express apps were created during public preview, and that customer feedback set the priorities for this release.