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 may be eligible for migration to express. Migration is performed in phases, starting with environments that are inactive, empty (no running apps or jobs), and belong to subscriptions with low Azure Container Apps usage. The criteria are designed to minimize disruption.
If your environment is selected for migration, you are notified in advance with details about the timeline and any action required. You can opt-out of any migration if you choose.
What criteria are used to select environments for migration?
Migration candidates are selected based on multiple factors:
- Activity level: Environments with no running applications or jobs are prioritized.
- Feature usage: Environments that don't use advanced features (such as VNet integration, Dapr, dedicated workload profiles, or session pools) are considered first.
- Subscription with low usage: Low-usage subscriptions are migrated before high-usage ones to minimize revenue risk.
Environments that use advanced features not yet available in express, or that belong to high-usage subscriptions, aren't auto-migrated.
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.
Can I opt out of automatic migration?
If you receive a migration notification and your environment relies on features not yet available in express, or if migration would disrupt your workloads, you can reach out to Azure support to discuss your options. Environments using advanced features that aren't supported in express aren't auto-migrated. You also have the option to self-migrate at a time that works for you using the archive and restore workflow.
Will I lose any functionality if my environment is migrated to express?
Automatic migration is only performed for environments where express supports all the features currently in use. If your environment uses features not available in express, such as VNet integration, Dapr, dedicated workload profiles, or custom domains, the app isn't a candidate for automatic migration.
If you self-migrate using archive and restore, review the express feature support matrix to confirm that all features your application depends on are available before proceeding.
What happens to my apps and data during migration?
During migration, expect up to 15 minutes of downtime. The migration process is designed to be transparent and without data loss. You'll receive advance notification before any automatic migration takes place. If you self-migrate using archive and restore, you control the process and timing directly.
Production readiness
Is express ready for production workloads?
Express is currently in preview. While it provides production-ready defaults (ingress, scaling, secrets, observability), preview services do not come with an SLA guarantee. Express is suitable for development, testing, prototyping, and production workloads that don't require features only available in Azure Container Apps with workload profiles (such as VNet integration or managed identity).
Does express have an SLA?
Express is in preview and doesn't currently have an SLA. SLA commitments are emerging as express moves toward General Availability. For workloads that require an SLA today, use Azure Container Apps with workload profiles.
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.