Azure Container Apps frequently asked questions (FAQs)

A list can be generated by running the following Azure CLI command:

  az provider show \
  --namespace Microsoft.App \
  --query "resourceTypes[?resourceType=='managedEnvironments'].locations"

No, Azure Container Apps doesn't provide direct access to the Kubernetes API.

Yes, you can import an Azure Container Apps API from the context of API Management.

Billing is based on resource consumption, including CPU, memory, and request count. For more information, refer to the billing page.

Yes. You can configure GitHub Actions using either the Azure CLI or the Azure portal:

• Using Azure CLI, run az containerapp github-action -h to see the options.

• Using Azure portal, go to the "Continuous deployment" window under your container app.

Azure Container Apps decodes the URL to protect your app against URL confusion attacks. A request URL that has encoded portions, such as http://mysite.com/archive/http%3A%2F%2Fmysite.com%2Farchive%2F123, is sent to your app as http://mysite.com/archive/http%3A/mysite.com/archive/123.

Consumption-only environments have limited support for user-defined routes (UDRs). ExpressRoute isn't supported. Limited UDR support is available when configured as follows:

• A route must be defined using the Azure.<REGION_NAME> Service tag with Next Hop = "Internet".

• Network security group (NSG) rules must also be configured as described in the NSG documentation to ensure the environment operates correctly.

These limitations don't apply for workload profiles, and for full featured UDR and Express Route support, use workload profile environments.

Azure Container Apps doesn't move or store customer data out of the deployed region.

Request a quota increase in the Azure portal with Azure Container Apps selected as the provider.

Consider the following when submitting a quota increase request:

• Scaling apps vs environments: There are many different quotas available to increase. Use these descriptions to help identify your needs:

  • Increase apps and cores per environment: Allows you to run more apps within an environment and/or more intensive apps. Recommended if your workloads can deploy within the same network and security boundaries.
  • Increasing environments: Recommended if your workloads need network or security boundaries. Note: A detailed business context might be required if your request involves increasing environment-level quotas. When you request a change to your regional environment quota, you should request a corresponding change to your global environment quota.

• Regions: Approvals for increase requests vary based on compute capacity available in Azure regions.

• Specific compute requirements: The platform supports 4 GB per container app. Memory limits overrides are evaluated on a per-case basis.

• Business reasoning for scaling: You might be eligible for a quota increase request if the platform limits are blocking your workload demands. Scale limits overrides are evaluated on a per-case basis.

Each Dapr capability undergoes thorough evaluation to ensure it positively impacts customers running microservices in the Azure Container Apps environment, while providing the best possible experience.

The availability of Dapr's alpha APIs isn't guaranteed or Microsoft-supported.

While Tier 1 components are fully supported, Tier 2 components are supported with best effort. Learn more.

You can submit a feature request via the Azure Container Apps GitHub repository. Make sure to include "Dapr" in the feature request title.

As 1.13.6-msft.1 is being rolled out across production regions, you may still see earlier versions (like 1.12.5 or 1.12.5-msft.6). The -msft.<number> suffix indicates the specific customizations made for Azure Container Apps to enhance your experience.

Dapr versions are updated on a best-effort basis, with a strong focus on stability, thorough testing, and minimizing customer impact. The goal is to ensure updates are seamlessly integrated without introducing breaking changes.

Since Dapr version updates are applied automatically, you always benefit from the most secure version. However, Dapr in Azure Container Apps doesn't follow a fixed release schedule for new features. Instead, the release of new Dapr versions for new functionality depends on the prioritization and stability of the Dapr binaries.

Find updates and release announcements for Dapr in Azure Container Apps in GitHub.

Custom version selection is not supported. Instead, your environment is automatically upgraded, maintaining the integrity of Dapr's fully managed and serverless offering in Azure Container Apps.

A Docker-less deployment allows you to deploy your application without defining a Dockerfile in your code. Instead, the Container Apps cloud build functionality uses Buildpacks to turn source code on your local machine into a container image. This option uses the Azure Container Apps default registry.

You're experiencing a known issue with Docker-less deployments. Retrying might resolve this for you. If you run into this issue, open a GitHub issue so our team can investigate.

You need to enable data protection for all .NET apps on Azure Container Apps. See Deploying and scaling an ASP.NET Core app on Azure Container Apps for details.

Container Apps supports four LTS JDK versions: JDK 8, JDK 11, JDK 17 and JDK 21. For source code build, the default version is JDK 17. For a JAR file build, the JDK version is read from the file ___location META-INF\MANIFEST.MF in the JAR, but uses the default JDK version 17 if the specified version isn't available.

You can configure JDK version to override the default version via build environment variables.

Azure Container Apps currently supports Apache Maven as the Java build tool.

You can customize a Java image build via build environment variables.

When using containerapp up in combination with a Docker-less code base, use the --___location parameter so that application runs in a ___location other than US East.

Avoid using static tags like latest for container images. Using static tags can lead to caching problems and can make your app difficult to troubleshoot. Instead, use unique tags for each deployment, such as a Git hash or date and time to ensure that updates are properly tracked and deployed.

The managed agent only supports gRPC.