Container Apps — environments, ingress, revisions, scale, probes, secrets and registry identity
How a container app is shaped and what its defaults are — workload-profiles versus legacy Consumption-only environments and their subnet rules, external and internal ingress at two levels, targetPort and automatic port detection, transport and allowInsecure, single and multiple revision modes, scale limits and rules, the default TCP probes and their timings, secrets from Key Vault through a managed identity, and pulling from Container Registry with an identity.
markdownreferencev1H8X2-B6V7stage: designtrust: officialservice: container-appsinterface: iacinterface: cliContainer Apps environment workload profilesConsumption-only environment legacysubnet /27 delegated Microsoft.App/environmentssubnet /23 not delegated--internal-only environmentingress external internaltargetPortautomatic port detectiontransport auto http http2 tcpexposedPortallowInsecure default falsesingle revision mode defaultmultiple revision mode traffic splittingminReplicas 0 defaultmaxReplicas 10 default1000 replicasscale rules http tcp custom KEDAdefault startup probe failure threshold 240readiness probe defaultsecretrefkeyVaultUrl secretKey Vault Secrets User container appregistries identity--registry-identity systemacrpull automatic
Container Apps — environments, ingress, revisions, scale
Environments
| Type | Status | VNet subnet |
|---|---|---|
| Workload profiles (v2) | The default; Consumption and Dedicated profiles | /27 or larger, delegated to Microsoft.App/environments. Supports user-defined routes, NAT gateway egress and private endpoints |
| Consumption-only (v1) | Legacy | /23 or larger, not delegated to anything. No UDRs, NAT gateway or custom egress |
An environment created with --internal-only has no public endpoint: it's reachable only through an internal load balancer in your VNet. Subnet planning and DNS for internal environments: networking family.
Ingress
Two levels decide who can reach an app. The environment is external or internal; the app's ingress is external ("accepting traffic from anywhere", which on an internal environment means the VNet, not the internet) or internal (other apps in the same environment only).
| Property | Default and rules |
|---|---|
external | false |
targetPort | The port the container listens on. HTTP ingress is always served on 443. If unset with HTTP ingress, Container Apps scans listening ports and uses the only one it finds |
transport | auto (HTTP/1 or HTTP/2), http, http2, tcp (with exposedPort, not 80 or 443) |
allowInsecure | false: HTTP on 80 is redirected to HTTPS |
ipSecurityRestrictions, stickySessions.affinity | Optional; affinity none by default |
Revisions and scale
- Single revision mode (default): a new revision replaces the old one once it's ready, without downtime. Multiple revision mode: you choose activation and traffic weights; wait for readiness before shifting traffic. Changing
properties.template(containers, images, scale rules, revision suffix) creates a revision; changingproperties.configuration(secrets, ingress, traffic, registry credentials, revision mode) applies to all revisions without one. New secret values need a revision restart to be seen. - Scale limits:
minReplicas0 (scale to zero) andmaxReplicas10 by default; up to 1,000. Rules are HTTP, TCP or custom (KEDA scalers); a custom rule needs the scaler's own auth (secret or identity) and network path. SetminReplicas: 1when cold starts matter.
Default probes
With ingress enabled and no probes defined, TCP probes on the target port are added to the main container (not to sidecars or GPU profiles):
| Probe | Defaults |
|---|---|
| Startup | TCP, timeout 3 s, period 1 s, initial delay 1 s, failure threshold 240 |
| Liveness | TCP on the target port |
| Readiness | TCP, timeout 5 s, period 5 s, initial delay 3 s, failure threshold 48 |
A revision shows unhealthy when any replica fails readiness. For slow starts, define your own startup probe rather than stretching liveness. HTTP probes on ports 80 or 443 can confuse automatic port detection.
Secrets and identity
- Secrets are name/value pairs referenced from environment variables as
secretref:<name>. In production, store a Key Vault reference instead of the value (keyVaultUrlplusidentity); the app's managed identity needs Key Vault Secrets User. - Pulling from Container Registry with an identity: in
configuration.registries, setserverandidentity(a user-assigned identity's resource ID, orsystem).az containerapp create … --registry-identity <id>tries to create the AcrPull assignment for you. Prefer a user-assigned identity with AcrPull granted before the first deployment (patterns/github-actions-to-container-apps.md). - Calling other Azure services from the app:
DefaultAzureCredentialwithAZURE_CLIENT_IDset to the user-assigned identity's client ID (reference/azure-identity/credential-chain.md).
Errors: reference/container-apps/errors.md. Function apps as container apps: reference/functions/functions-on-container-apps.md.