Azure Container Apps: Fix Common Setup & Config Errors

Azure Container Apps can pull images from any registry, public or private, including Docker Hub and Azure Container Registry. But getting the authentication right is where most azure container apps first deployment failures happen.

If you're using Azure Container Registry, the cleanest approach is enabling the managed identity on your Container App and assigning it the AcrPull role on the registry. In the Azure portal, navigate to your Container App → Identity → enable System assigned managed identity. Then go to your ACR resource → Access control (IAM) → Add role assignment → select AcrPull → assign it to your container app's managed identity.

If you'd rather use admin credentials, you'll need to grab them from ACR and store them as a secret in your Container App. Go to your ACR → Access keys → enable Admin user. Copy the username and one of the passwords. Then in your Container App → Secrets, add two new secrets: one for the registry username, one for the password. Reference these when configuring your registry in the Container App settings.

For Docker Hub or other external registries with private images, navigate to your Container App → Containers → edit the container → under Image source, select Docker Hub or other registries → set Image type to Private → fill in the server URL, username, and password. The password field accepts a direct value or a reference to an existing secret (the secret reference format is secretref:YOUR_SECRET_NAME).

After saving, go to Revision management → Create new revision to force a fresh deployment that picks up the new credentials. Watch the replica status, if the image pull succeeds, you'll see replicas transition from Pending to Running within 60–90 seconds for most images.

If it still fails, run:

az containerapp revision show \
  --name YOUR_APP_NAME \
  --resource-group YOUR_RG \
  --revision YOUR_REVISION_NAME

Look for "provisioningState": "Failed" and a message field that will spell out the pull error verbatim.

One of the genuine advantages of Azure Container Apps is that it handles HTTPS termination and ingress without requiring you to manage certificates or load balancer rules yourself. But you have to configure it precisely, or traffic never reaches your container.

In the Azure portal, go to your Container App → Ingress in the left menu. You'll see these key settings:

• HTTP Ingress, toggle this on if your app serves HTTP/HTTPS traffic
• Ingress traffic, set to Accepting traffic from anywhere for public internet exposure, or Limited to Container Apps Environment for internal microservice communication only
• Target port, this must exactly match the port number your container process binds to
• Transport, choose HTTP/1, HTTP/2, or auto depending on your app's protocol

The target port is where things go wrong most often with azure container apps ingress not working. If your Node.js app does app.listen(3000), your target port must be 3000. If your ASP.NET app listens on 8080 (common in containers), set 8080. The platform doesn't inspect your container to figure this out, you have to tell it.

For TCP ingress (non-HTTP protocols), the setup is slightly different. You'll need to set Transport to TCP and specify the exposed port. This is useful for things like Redis, PostgreSQL proxies, or custom socket-based services.

Once ingress is configured, save the settings and your app gets an auto-generated FQDN in the format YOUR_APP_NAME.RANDOM_ID.REGION.azurecontainerapps.io. You'll find this URL on the Container App overview page under Application Url. Test it immediately with:

curl -I https://YOUR_APP_NAME.REGION.azurecontainerapps.io/health

A 200 response means ingress is working. A connection timeout means your target port is wrong. A 502 means the container is running but returning errors, check your application logs.

For internal service-to-service communication inside a Container Apps environment, you don't need external ingress at all. Azure Container Apps provides built-in DNS-based service discovery, so other apps in the same environment can reach your service at http://YOUR_APP_NAME directly.

Azure Container Apps scales dynamically based on a variety of signals: HTTP request volume, CPU load, memory pressure, or any KEDA-compatible event source like Azure Service Bus queue depth, Event Hub lag, or a custom metric. Understanding how these scaling dimensions interact prevents a whole category of azure container apps scaling problems.

Here's the rule that catches people off guard: apps that scale based on CPU or memory load cannot scale to zero. This is a platform constraint, not a bug. If you set your minimum replica count to 0 but your only scaling rule is CPU-based, the platform will reject or override your configuration. You need at least 1 minimum replica for CPU/memory-triggered scaling.

To view and edit scaling rules, go to your Container App → Scale and replicas in the left menu. Here you'll see:

• Min replicas, the floor. Set to 0 to allow scale-to-zero for HTTP/event-driven apps.
• Max replicas, the ceiling. Default is 10; increase this if you expect high concurrency bursts.
• Scale rules, the triggers that drive scaling decisions

For HTTP traffic scaling, click Add under scale rules → select HTTP scaling → set your concurrent requests threshold. A common starting point is 100 concurrent requests per replica, which tells the platform to spin up an additional replica for each additional 100 concurrent connections.

For KEDA-based scaling (Azure Service Bus, Storage Queue, Event Hubs, etc.), select Custom in the rule type dropdown. You'll need to provide the KEDA scaler name and metadata in JSON format. For example, for an Azure Storage Queue:

{
  "type": "azure-queue",
  "metadata": {
    "queueName": "my-queue",
    "queueLength": "5",
    "accountName": "mystorageaccount"
  },
  "auth": [
    {
      "secretRef": "azure-storage-connection-string",
      "triggerParameter": "connection"
    }
  ]
}

After saving new scaling rules, create a new revision to apply them. Monitor replica count over the next few minutes under Scale and replicas → Replicas to confirm the rules are firing as expected. If replicas aren't scaling up under load, check that your KEDA auth references point to valid secrets in the Container App.

Azure Container Apps gives you a built-in secret store that injects values into your container at runtime. No Key Vault required, though Key Vault integration is available if you want it. Getting this right means your app starts clean across every environment. Getting it wrong means startup crashes that look like application bugs but are actually missing configuration.

To add a secret, navigate to your Container App → Secrets in the left menu → Add. Give the secret a name (use lowercase with hyphens, like db-connection-string) and paste in the value. Secrets are stored encrypted and are not visible in plaintext after saving, even to admins in the portal.

Once a secret exists, you reference it in environment variables. Go to Containers → edit your container → scroll to Environment variables. Click Add. Set the Name to whatever your application expects (e.g., DATABASE_URL). For the Source, select Reference a secret and pick your secret from the dropdown. This binds the secret value to the environment variable at container startup.

A common azure container apps secrets error happens when developers add a new secret but forget to create a new revision. Secrets changes take effect only in new revisions, not in-place on the current running revision. After adding or changing secrets, always go to Revision management → Create new revision.

For environment-specific configuration (development vs. staging vs. production), the cleanest pattern is using separate Container Apps environments per stage. Each environment gets its own secrets with the appropriate values. This directly answers the question many developers have about managing settings between different deployment environments, the answer is separate environments, not complex naming conventions.

To verify your environment variables are being injected correctly, run a quick exec into the container:

az containerapp exec \
  --name YOUR_APP_NAME \
  --resource-group YOUR_RG \
  --command "/bin/sh -c 'echo $DATABASE_URL'"

If the variable is empty or missing, the secret reference isn't wired up properly. Double-check that the secret name in the binding exactly matches the secret name you created, these are case-sensitive.

One of the best features of Azure Container Apps is revision management. Every time you deploy a new container image or change configuration, the platform creates a new revision, a snapshot of that exact deployment state. If something breaks in production, you can switch traffic back to a previous revision in about 30 seconds. No redeployment required.

Go to your Container App → Revision management. You'll see a list of all revisions with their status, creation time, and traffic weight. Each revision shows how much of your incoming traffic is routed to it (as a percentage).

To roll back, find a previously working revision in the list. Click the three-dot menu next to it → Activate. Once it's active, set its traffic weight to 100% and set the broken revision's traffic weight to 0%. The platform routes all traffic to the working revision immediately, no downtime.

Azure Container Apps supports multiple active revisions simultaneously, which is what enables traffic splitting for blue/green deployments and A/B testing. You could run a new revision at 10% traffic weight, watch your error rate, and gradually shift to 100% if metrics look good. If something goes wrong, set it back to 0% without touching the stable revision at all.

To list all revisions via CLI:

az containerapp revision list \
  --name YOUR_APP_NAME \
  --resource-group YOUR_RG \
  --output table

To set traffic weights programmatically:

az containerapp ingress traffic set \
  --name YOUR_APP_NAME \
  --resource-group YOUR_RG \
  --revision-weight \
    STABLE_REVISION_NAME=100 \
    BROKEN_REVISION_NAME=0

After executing the rollback, immediately check Monitoring → Log stream to confirm the stable revision is receiving and handling requests correctly. You should see your application's normal startup log output and healthy request logs within 30–60 seconds of the traffic shift.

This revision system is one of the core answers to the question of how to reliably deploy your application, you never replace a working deployment, you add a new one alongside it and shift traffic only when you're confident.