Harri JaakkonenCloudpartner Microsoft MVPMicrosoft MVP Fortytwofortytwo.io
❯Azure Container Apps·Express·Sandboxes·Cloud Security▋
./blog › Azure Container Apps Express: The Fast Application Tier Built on Sandboxes
PS HarriJaakkonen :~/Blog/Posts> cat ./azure-container-apps-express-built-on-sandboxes.html

Azure Container Apps Express: The Fast Application Tier Built on Sandboxes

19/10/2026 · 14 min read · Post #19046
Azure Container Apps AI Security
Azure Container Apps Express application tier running on isolated Sandbox compute

Azure Container Apps now has an Express environment tier. The promise is easy to understand: give Azure a Linux container image, get an HTTPS application in seconds, and let the service handle scaling and most environment decisions. That is a useful option for APIs, SaaS frontends, AI gateways, MCP servers, and agent backends that spend part of the day idle.

The part that caught my attention sits in the Express FAQ. Microsoft says Express is "built entirely on Azure Container Apps Sandboxes." That is a strong architectural statement. It links the simplified application tier to the prewarmed pools and isolation model Microsoft introduced for direct Sandbox workloads. It does not mean an Express app gives you a Sandbox resource to control, though. You get the application platform built on that foundation, not snapshots, suspend and resume, or direct Sandbox lifecycle management.

Cost is also part of the appeal. Express uses the existing Container Apps consumption model with per-second vCPU and memory billing, the consumption free grant, and scale to zero. There is no separate environment provisioning fee. Registry storage and egress can still produce their own charges, and a minimum replica above zero keeps compute running. Scale to zero is a billing tool, not a promise that every architecture becomes free.

Current documentation: Microsoft dated the Express overview and FAQ September 21, 2026. The feature matrix is changing quickly, so check it before making a production design or approving an automatic environment migration.

What Express changes

A standard Container Apps deployment starts with a managed environment. You choose the environment model, networking, workload profiles, logging destination, and other controls before the first app arrives. Express keeps the environment resource for compatibility, but changes its role. In the portal it behaves more like a lightweight application group than an infrastructure boundary you spend time designing.

The Azure Container Apps portal at containerapps.azure.com creates and manages that Express environment for you. The CLI remains explicit: you create an environment with --environment-mode express, then place the app in it. Existing Container Apps resource types, CLI commands, SDKs, and infrastructure code still have a familiar shape.

Decision Express environment Standard workload profile environment
Primary workload HTTP web app, REST API, SaaS frontend, AI gateway, MCP endpoint HTTP or TCP services, microservices, jobs, GPU, and mixed workload types
Provisioning model Lightweight managed environment and pre-provisioned capacity Environment infrastructure is provisioned before apps
Compute Consumption CPU Consumption, dedicated profiles, and supported GPU profiles
Scaling HTTP, CPU, or memory rules; scale to zero; no custom KEDA scaler Wider scaling controls, including event-driven KEDA scenarios
Application rollout Single revision with rolling replacement Multiple revisions and traffic splitting are available
Network and identity Focused controls with user-assigned identity and selected VNet features Broader networking, identity, certificate, and environment controls
Billing Consumption billing with no environment provisioning fee Consumption or dedicated workload profile charges, depending on design

The difference is not "developer tier versus production tier." Microsoft says Express can run production workloads that fit its supported feature set. The real choice is between a focused HTTP application tier and the broader Container Apps control surface.

What the Sandbox foundation actually means

The current FAQ uses precise wording: "Under the hood, express is built entirely on Azure Container Apps Sandboxes." It describes Sandboxes as the platform primitive providing subsecond startup from prewarmed pools, strong isolation, and large-scale expansion. A later answer says Express cold-start gains also come from pre-provisioned capacity and a streamlined data plane specific to the Express tier.

I would read those statements together. Sandboxes provide the underlying isolated compute foundation. Express adds the HTTP application data plane, ingress, scaling, revisions, secrets, logs, and application lifecycle. Microsoft does not expose the backing Sandbox resource in the Express resource model, so there is nothing for an application team to snapshot or resume directly. This is a documented service implementation detail, not a boundary we can inspect from our own subscription.

Request flow through Container Apps Express to the Sandbox foundation A deployment agent sends a container image and configuration to Container Apps Express. HTTPS traffic passes through managed ingress to application replicas. The replicas run on a prewarmed pool of isolated Sandbox compute managed by Microsoft. How an Express app reaches isolated compute Application controls above the line, Microsoft-managed foundation below it Developer or agent Image + configuration DEPLOY EXPRESS APP You configure this layer HTTPS URL Managed ingress REPLICA 1 REPLICA N 0 TO N, REQUEST DRIVEN Identity | secrets | rolling revision | logs | CPU and memory scaling MANAGED BOUNDARY Container Apps Sandbox foundation Microsoft manages this layer PREWARMED POOL ISOLATION FAST START SCALE-OUT CAPACITY
Requests enter through the Express HTTPS endpoint and managed ingress, then reach application replicas running on Microsoft-managed Sandbox capacity. Express exposes application controls, not direct Sandbox snapshots, suspend and resume, or per-Sandbox lifecycle management.
Capability Express app Direct Sandbox
Primary purpose Host an HTTP application or endpoint Run isolated code or an interactive execution environment
Lifecycle Start, stop, scale, and update the application Create, stop, suspend, resume, snapshot, and delete a Sandbox
State Application replicas are replaceable; use external durable storage Memory and disk state can follow explicit Sandbox lifecycle policies
Isolation control Microsoft manages the backing implementation You choose image, network policy, files, ports, identity, and cleanup
Best fit Web APIs, agent endpoints, SaaS frontends, and MCP servers Untrusted code, agent tools, interactive sessions, and controlled execution

If an agent exposes a stable API, Express may be the right place for that API. If the agent executes generated code, installs packages, manipulates files, or needs explicit egress policy for each execution boundary, call a direct Sandbox from the API. The shared technology underneath does not remove the need to separate trusted orchestration from unpredictable execution.

The security controls you still own

A short configuration form does not shorten the security review. Express supplies defaults, but the application team still controls the image, secrets, runtime identity, ingress exposure, replica limits, dependencies, and data flows. Those are the controls attackers interact with.

Pin the image and protect the registry path

Express supports public images and private registry pulls. For Azure Container Registry, a user-assigned managed identity can authenticate the pull. System-assigned managed identity is not supported. In production, deploy an image digest, scan it before release, retain the software bill of materials, and restrict who can update the deployment.

Use the runtime identity for one job

Express supports user-assigned managed identities for the running app. It does not support system-assigned identities. That can be a good governance model because the identity exists independently and can be reviewed before deployment. It can also become a shared blast radius if several apps reuse an identity with broad roles. Give each trust boundary its own identity and grant data-plane roles at the narrowest useful scope.

Plan around the Key Vault limitation

Manual application secrets are supported. Key Vault secret references are not. An app can use its runtime identity to retrieve a secret through code, but that changes startup behavior and failure handling. If your standard requires platform-managed Key Vault references with no secret value in the Container Apps configuration, Express does not currently meet that requirement.

Read the networking details, not the headline

The FAQ says Express removes networking decisions, but the feature matrix still contains meaningful choices. Express supports internal or external HTTP ingress, IP restrictions, CORS, VNet egress, and environment private endpoints when public network access is disabled. It does not support TCP ingress, additional ingress ports, client certificates, session affinity, custom domains, or built-in service discovery.

There is no contradiction once you separate defaults from capabilities. You can start without network design, but a private production workload still needs subnet planning, DNS, private endpoint policy, outbound dependency review, and proof that public access is disabled.

Security review gate: record the image digest, user-assigned identity, RBAC assignments, ingress mode, IP restrictions, VNet route, private endpoint state, secrets handling, maximum replicas, logging destination, and rollback method. Fast provisioning should make the evidence easier to collect, not optional.

Where the fast path stops

The current unsupported list is long enough that I would treat the feature matrix as an architecture gate. Express does not support sidecars, init containers, Dapr, jobs, custom KEDA scalers, custom domains, Easy Auth, Azure Files, OpenTelemetry agents, workload profiles, zone redundancy, multiple revisions, or traffic splitting. It is not suitable for TCP services, GPU workloads, or microservices that rely on internal service discovery.

Some limits affect deployment convenience. Others change the risk model:

  • No multiple revisions or traffic splitting means you cannot use a native canary rollout.
  • No zone redundancy matters for workloads with strict regional availability requirements.
  • No custom domains blocks the normal public production hostname pattern for many SaaS apps.
  • No client certificates removes one common service-to-service authentication option.
  • No Key Vault references may conflict with an existing secret governance standard.
  • No Dapr or internal service discovery makes Express a poor fit for tightly connected microservices.

Rolling updates are supported, and the active revision is replaced automatically. That is enough for many small services. It is not equivalent to controlling two revisions and shifting five percent of traffic while you watch error rates.

Portal caveat: Microsoft's overview currently warns that some Azure portal windows for Express environments are not functional. The dedicated Container Apps experience is the intended management interface. Keep CLI and infrastructure code available for repeatable work.

A small CLI deployment

The CLI makes the lightweight environment visible. The example below creates an Express environment without a logging destination, then deploys an external HTTP app that can scale to zero. For production, decide on Log Analytics, identity, private networking, image authentication, resource limits, and health probes before copying this pattern.

# Create the resource group
az group create `
  --name rg-aca-express-demo `
  --location westeurope

# Create an Express environment
az containerapp env create `
  --name cae-express-demo `
  --resource-group rg-aca-express-demo `
  --location westeurope `
  --environment-mode express `
  --logs-destination none

# Deploy a public HTTP image
az containerapp create `
  --name app-express-demo `
  --resource-group rg-aca-express-demo `
  --environment cae-express-demo `
  --image docker.io/nginx:stable `
  --target-port 80 `
  --ingress external `
  --min-replicas 0 `
  --max-replicas 3

# Read the generated hostname
az containerapp show `
  --name app-express-demo `
  --resource-group rg-aca-express-demo `
  --query properties.configuration.ingress.fqdn `
  --output tsv

Two details are easy to miss. Express accepts Linux amd64 OCI images, and target-port auto-detection is not supported. State the port. Also verify that the selected Azure region appears in the current region list. The portal and CLI may show a region where Express is not available, resulting in ExpressEnvironmentNotAvailableInRegion.

What scale to zero does and does not save

Express uses the Container Apps consumption price model. Azure bills active vCPU and memory by the second, applies the existing consumption free grant, and charges no separate fee to provision the Express environment. Microsoft also says there is no Express charge for image caching or registry pulls.

The complete bill can include more:

  • Container registry storage and registry-side egress
  • Log Analytics ingestion and retention
  • Private endpoint and networking components
  • Key Vault, database, storage, messaging, and AI service requests
  • Compute kept active by minimum replicas or steady request traffic

For a sporadic internal API, scale to zero can cut idle compute charges. For a public API receiving a constant health check, synthetic probe, or queue of requests, it may never reach zero. Measure the request pattern and cold-start tolerance rather than assuming the product name determines cost.

Where I would use Express

I would start with Express for an HTTP service that has one container, a generated Azure hostname, straightforward identity needs, replaceable local state, and uneven traffic. A small MCP server or agent tool endpoint is a good example. The service can wake when called, use a narrowly scoped identity, write durable state to an external store, and return to zero replicas when idle.

I would choose a standard workload profile environment when the design needs a custom domain, blue-green or canary traffic control, zone redundancy, TCP, GPU, Dapr, jobs, sidecars, custom KEDA scaling, client certificates, or deeper network control. I would choose direct Sandboxes when the workload is the execution environment itself and requires snapshots, suspend and resume, explicit egress policy, or control over files and lifecycle.

Workload Better starting point Reason
Low-traffic REST API or MCP endpoint Express HTTP-first, fast deployment, scale to zero
Public SaaS application needing its own domain Standard environment Express does not currently support custom domains
Event-driven worker using a custom KEDA scaler Standard app or Container Apps job Express supports HTTP, CPU, and memory scaling only
GPU-backed inference endpoint GPU workload profile Express is consumption CPU only
Agent API that dispatches generated code Express API plus direct Sandboxes Keep the stable endpoint separate from untrusted execution
Interactive isolated coding environment Direct Sandbox Needs direct state, snapshot, and lifecycle control

Express is an interesting addition because it changes the waiting time and the number of early decisions without inventing a new application resource. The Sandbox foundation helps explain the startup and isolation claims, but it should not be used as shorthand for features the Express resource does not expose.

My practical rule is simple: use Express when the supported matrix already matches the application. Do not force an application into Express because the first deployment is fast. The missing feature usually becomes expensive after the service has users, DNS dependencies, audit requirements, and an availability target.

References

Archives