- Published on
Container Apps Express Reaches GA on a Newly Generally Available Sandbox Layer
- Authors
- Name
- DeepHorus
Microsoft has 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 an 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, arguing that 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 Express is built entirely on Container Apps Sandboxes, a primitive that provisions from prewarmed pools for subsecond startup and isolates each workload in its own hardware-isolated microVM boundary. Sandboxes can burst to thousands of concurrent instances and support suspend and resume, snapshotting full state including memory and disk with sub-second restore. The top-level ARM resource is Microsoft.App/SandboxGroups, described as a management boundary for sandboxes sharing configuration, comparable to a Container Apps environment.
Developers can use Sandboxes directly rather than through Express, which Microsoft positions for agent platforms and secure code-execution services. Reaction on Reddit suggested the primitive was in use well before the announcement: commenter MuhBlockchain claimed ACA Sandboxes underpin much of core Azure, including Foundry Hosted Agents. Others reported live deployments, with tankerkiller125real describing Python sandboxes for a customer-facing agent harness and Minute_Passion_8077 deploying them for clients through Bicep.
Commenter brianveldman drew a lifecycle line between Sandboxes and Container Apps jobs, noting jobs handle run-to-completion tasks while Sandboxes provide programmable, isolated environments with lifecycle control. Skepticism surfaced as well: commenter RustOnTheEdge responded to the microVM isolation claim with open doubt, without elaborating. Commenter HgnX asked whether the same capability exists in Azure Kubernetes Service, noting his team runs AKS because of requirements Container Apps does not meet, and the question went unanswered.
The 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. 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 layer on top, offering 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. Its exclusions define where it stops: no custom domains, zone redundancy, Key Vault references, Easy Auth, OpenTelemetry, Dapr, jobs, workload profiles, GPU workloads, multiple revisions, traffic splitting, or system-assigned managed identities. Service discovery is also absent, leaving apps communicating through their public endpoints.
