Find answers to frequently asked questions about Azure Container Apps express.
Important
Azure Container Apps express is currently in preview. Preview features are provided without a Service Level Agreement (SLA) and aren't recommended for production workloads. Some features may not be supported or may have limited capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
General
What is Azure Container Apps express?
Azure Container Apps express is a streamlined environment tier currently in preview, purpose-built for web applications. It delivers the fastest provisioning, instant scale-from-zero, and the simplest developer experience in Azure Container Apps. Express removes infrastructure decisions: no environment to manually provision, no networking to configure, and no scaling rules to write. You bring a container image, and express handles everything else.
How is Azure Container Apps express different from Azure Container Apps?
Azure Container Apps requires you to create and configure a managed environment before deploying apps. Express eliminates that step entirely. Key differences include:
- Provisioning: Express apps are running in seconds, not minutes.
- Cold starts: Express delivers subsecond scale-from-zero startup times.
- Configuration: Express provides production-ready defaults with no infrastructure decisions required.
- Environments: Express environments are fully managed and shared, so you don't provision or configure the underlying infrastructure.
For workloads that need VNet isolation, dedicated compute, GPU, or advanced networking, Azure Container Apps continues to offer the full spectrum of compute options through workload profiles.
If express is meant to simplify Azure Container Apps, why does the environment construct still exist?
In express, the environment's role is different. It's now a lightweight, fully managed grouping for your apps, closer to an app group than an infrastructure boundary. Setup time shrinks to nearly zero.
Express preserves it for a few reasons:
- Consistency: Existing IaC, Software Development Kits (SDKs), and CLI commands continue to work unchanged.
- Future features: Some upcoming capabilities bind apps in an environment together (for example, VNet attachment).
- Smooth path between tiers: A shared model makes it easier to move between express and standard Azure Container Apps.
Who is express designed for?
Express is purpose-built for two audiences:
- Developers who want to ship fast: SaaS apps, APIs, web dashboards, prototypes, and startups that go from idea to production in minutes.
- Agents that deploy on demand: Model Context Protocol (MCP) servers, tool-use endpoints, multi-step workflow APIs, and human-in-the-loop UIs that need instant provisioning and teardown.
What is the relationship between express and Azure Container Apps Sandboxes?
Under the hood, express is built entirely on Azure Container Apps Sandboxes, a foundational platform primitive that delivers subsecond startup from prewarmed pools, strong isolation, and massive scale-out. You don't need to understand Sandboxes to use express. Express is the opinionated, developer-friendly experience built on top of Sandboxes.
How does express compare to Azure Container Instances (ACI)?
Azure Container Instances (ACI) is a low-level primitive for running a single container or container group with no built-in HTTP ingress, scaling, revisions, or app lifecycle management. Azure Container Apps express is a full application platform: it gives you a public HTTPS endpoint, automatic scale to and from zero, multi-replica scale-out, secrets, environment variables, log streaming, and exec access, without requiring you to provision an environment. ACI gives you a container; express gives you a production-ready app. If you're running a web app, API, MCP server, or agent endpoint, express is the better fit.
Will the cold start and provisioning improvements in express be brought back to standard Azure Container Apps?
The provisioning and cold start gains in express come from a new architecture (pre-provisioned capacity and a streamlined data plane) that is specific to the express tier. Standard Azure Container Apps environments continue to receive ongoing improvements, but the subsecond cold starts and instant provisioning available in express aren't planned to be replicated in standard Azure Container Apps environments. Customers who need those characteristics should use express.
Getting started
How do I create an express app?
You can create an express app using the Azure CLI or the new Azure Container Apps portal at containerapps.azure.com.
Using the Azure CLI, first create an express environment, then deploy your app:
az containerapp env create \
--name <ENVIRONMENT_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--environment-mode express \
--logs-destination none
az containerapp create \
--name <APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--environment <ENVIRONMENT_NAME> \
--image docker.io/nginx \
--target-port 80 \
--ingress external \
--min-replicas 0 \
--max-replicas 1
Your app is live in seconds.
Do I need to create a managed environment before deploying an express app?
When using the Azure CLI, you first create an express environment using az containerapp env create --environment-mode express, then deploy your app into it. When using the Azure Container Apps portal, the environment is created and managed for you automatically.
What identity and account requirements are needed to use express?
Express requires a Microsoft Entra ID-backed account. Personal Microsoft accounts and non-Entra-backed accounts aren't supported. Your subscription must also be registered for the Azure Container Apps resource provider. If you encounter a tenant_not_allowed error when accessing the portal, verify that your account is backed by a Microsoft Entra tenant.
Can I use both the Azure CLI and the portal to manage express apps?
Yes. You can create express apps through both the Azure CLI and the Azure Container Apps portal at containerapps.azure.com.
Features and capabilities
What features are available in express today?
Express is in preview. The following features are available:
- Deploy container images from any registry (anonymous or token-based pull)
- Automatic scale from zero with no configuration required
- Multi-replica scaling for production traffic
- Default ingress domain with an immediate public URL
- Environment variables and secrets management
- Real-time log streaming
- Exec access to shell into running containers for debugging
- New portal experience at containerapps.azure.com
For the most current list of supported features, see the express documentation.
What features aren't yet available in express?
Express is in preview with a meaningful feature gap compared to Azure Container Apps. Features not yet available include:
- VNet integration
- Custom domains
- Managed identity
- Health probes
- Autoscaling
- GPU compute
New features are being shipped on a rapid cadence throughout the preview. The express documentation includes a current list of supported and upcoming features, updated frequently.
Are there any requirements for the container image I deploy to express?
During preview, express supports Linux containers built for the linux/amd64 architecture. Images can be pulled from any registry that supports anonymous or token-based pull (for example, Docker Hub, Azure Container Registry, or GitHub Container Registry). There's no special base-image requirement. You bring a standard Open Container Initiative (OCI) container image that listens on the port you declare with --target-port.
Can I use private (virtual network) inbound or outbound networking with express?
No. Express apps run with a public default ingress domain and don't support VNet integration for inbound traffic, private endpoints, or VNet-routed outbound traffic. If your workload requires private networking, use Azure Container Apps with workload profiles. VNet support is on the express roadmap. For the latest status, see the express documentation.
When will express reach feature parity with Azure Container Apps?
Express is shipping new features on a rapid cadence throughout the preview. The express documentation includes a current feature support matrix that is updated frequently.
Regions
Which Azure regions support express?
Express is available in the following regions during preview:
- East Asia
- West Central US
Region availability is expanding throughout the preview period.
Why can't I create an express environment in my preferred region?
During preview, express is available in a specific set of regions. The portal and CLI may display regions where express isn't yet supported. If you receive an ExpressEnvironmentNotAvailableInRegion error, that region isn't yet supported. Region availability is expanding as the preview progresses.
Pricing and billing
How is express billed?
Express uses the existing Azure Container Apps consumption pricing model: per-second vCPU and memory billing with scale-to-zero. There's no environment provisioning fee. You benefit from the same free grant that applies to consumption workloads today. Express is the most cost-effective way to run web applications and APIs on Azure Container Apps. For detailed pricing, see the Azure Container Apps pricing page.
Is there a free tier for express?
Yes. Express includes the same generous free grant that applies to Azure Container Apps consumption workloads. You aren't charged until your usage exceeds the free grant thresholds. Combined with scale-to-zero, express ensures you only pay for what you use.
Is there a cost for image caching or image pulls in express?
No. Express doesn't charge a separate fee for image caching or registry pulls. You only pay the standard Azure Container Apps consumption rates for vCPU and memory while your app is running. Any registry-side egress or storage costs are billed by your container registry, not by express.
Migration
Do my existing Azure Container Apps environments automatically migrate to express?
Some existing environments are selected for automatic migration. If your environment is selected, you receive a notice 25 to 30 days before the migration. The environment is migrated automatically unless you opt out.
Why was my environment selected for automatic migration?
Your environment was selected because the features it uses are supported by express. Express provides faster provisioning and faster scale from zero.
How does Microsoft determine whether my environment is compatible with express before an automatic migration?
Only environments that use features supported by express are selected. Eligibility is assessed when the migration notice is sent.
If you change the environment or an app after receiving the notice and it no longer meets the eligibility criteria, submit the opt-out form.
Can an environment that uses features not available in express be automatically migrated?
Express doesn't yet support the full Azure Container Apps feature set. Migration notices are sent only for apps and environments whose detected features are supported by express.
Are non-HTTP workloads eligible for automatic migration?
No. Jobs, TCP services, MQTT consumers, and other long-running workloads aren't currently in scope for automatic migration.
Are related development, staging, and production environments migrated together?
No. Only the environments listed in the migration notice are migrated.
How much notice will I receive before an automatic migration?
Migration notices are sent 25 to 30 days before the migration.
Do I need to approve an automatic migration before it starts?
No. Environments listed in the migration notice are migrated automatically unless you opt out.
How do I opt out of or defer an automatic migration?
The migration notice includes an opt-out form. Submit the environment's full resource URI to exclude it from automatic migration.
Can I choose the date and time of an automatic migration?
No. Automatic migrations can't be scheduled. To control the timing, opt out and self-migrate.
What should I do if migration requires internal change approval or coordination with a vendor or partner?
Migration preserves the existing app and environment configuration. If you need additional approval or coordination, use the opt-out form in the migration notice.
What is environment archiving?
Environments that are inactive (no running apps or jobs and no recent activity) may be archived. An archived environment is put to sleep. If you need your environment again, you can restore it.
Can I self-migrate my environment to express?
Yes. Self-migration is available so you can move to express on your own terms without contacting support. You can use the archive and restore mechanism to migrate your environment: archive your existing environment, then restore it as an express environment. This process gives you full control over the migration process and timing.
What benefit does migration provide if my app is already stable?
Migration provides faster provisioning and faster scale from zero. It doesn't change the Azure Container Apps consumption free grant.
How much downtime should I expect during an automatic migration?
The migration is expected to take about 15 minutes. Your app may be unavailable for only part of that time.
Does automatic migration change my app configuration or data?
No data is affected. App configuration, URLs, and resource URIs remain unchanged.
Migration sets EnvironmentMode = Express on the environment. Existing infrastructure-as-code deployments that target the same environment don't need to set this property. The property is required only when creating a new express environment.
Does automatic migration change my app's URL or Azure resource IDs?
No. Automatic migration preserves app URLs and Azure resource IDs.
Does automatic migration change minimum replicas, maximum replicas, or other scaling settings?
No. App configuration, including replica and scaling settings, is preserved.
Will automatic migration break my infrastructure-as-code deployment or create state drift?
No change is required when your infrastructure-as-code deployment continues to target the same environment.
Templates that create a new environment create a standard Azure Container Apps environment by default. To create a new express environment, set EnvironmentMode = Express on the environment.
Does automatic migration move my environment to another Azure region?
No. Automatic migration keeps the environment in its current Azure region.
Can my environment be automatically migrated if express isn't publicly available in its region?
Only environments that can remain in their current region are selected. If you receive a migration notice before the public region list is updated, the documentation may be lagging behind the service rollout.
What happens if an automatic migration fails?
The product team investigates and fixes the issue, then retries the migration. The team has completed thousands of migrations without issues.
Do I need to validate my app after an automatic migration?
No additional validation is required. The automated process includes post-migration checks.
What should I do if the environment is no longer needed or will be deleted soon?
You can delete the environment before migration. Otherwise, no action is required and it will be migrated as scheduled.
Production readiness
Can production environments be automatically migrated while express is in preview?
Yes. Express is in public preview, and general availability is planned within the next few months. Express builds on Azure Container Apps consumption, and Microsoft may migrate production apps that meet the eligibility criteria.
You can opt out before migration or self-migrate at any time.
Is express ready for production workloads?
Express is in preview and has no SLA. It can run production workloads that use supported features, but support is provided on a best-effort basis during preview.
What SLA and support apply to express during preview?
Express has no SLA during preview. Microsoft provides best-effort support, which doesn't match production-level support.
How do I provide feedback or report issues?
You can provide feedback, report issues, and request features through the Azure Container Apps GitHub repository. You can also reach out to Azure support for production issues.