Container App is replaced after a bicep redeploy

[abouroubi]

I'm using Bicep to deploy an app into Azure Container Apps, the Container App is initialized with a dummy hello-world container.

Here is my code:

// Parameters
param location string = resourceGroup().location

@description('ACR scope')
param acrScope string

@description('ACR Name')
param acrName string

@description('URL to default hello world Container App image')
param acrDefaultImage string



resource appInsightWorkspace 'Microsoft.OperationalInsights/workspaces@2020-10-01' = {
  name: 'appinsightworkspace-myapp'
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
}

resource appInsight 'Microsoft.Insights/components@2020-02-02' = {
  name: 'appinsight-myapp'
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: appInsightWorkspace.id
    publicNetworkAccessForIngestion: 'Enabled'
    publicNetworkAccessForQuery: 'Enabled'
  }
}

resource uai 'Microsoft.ManagedIdentity/userAssignedIdentities@2022-01-31-preview' = {
  name: 'id-myapp'
  location: location
}

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2022-12-01' existing = {
  scope: resourceGroup(acrScope)
  name: acrName
}

var acrPullRole = resourceId('Microsoft.Authorization/roleDefinitions', '7f951dda-4ed3-4680-a7ca-43fe172d538d')


resource storageRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(resourceGroup().id, uai.id, acrPullRole)
  properties: {
    roleDefinitionId: acrPullRole
    principalId: uai.properties.principalId
    principalType: 'ServicePrincipal'
  }
}

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2022-09-01' = {
  name: 'vnet-myapp'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'subnet-myapp'
        properties: {
          addressPrefix: '10.0.0.0/23'
        }
      }
    ]
  }
}

resource containerAppsEnvironment 'Microsoft.App/managedEnvironments@2022-10-01' = {
  name: 'cae-myapp'
  location: location
  sku: {
    name: 'Consumption'
  }
  properties: {
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: appInsightWorkspace.properties.customerId
        sharedKey: appInsightWorkspace.listKeys().primarySharedKey
      }
    }
    vnetConfiguration: {
      infrastructureSubnetId: virtualNetwork.properties.subnets[0].id
    }
    zoneRedundant: false
  }
}

resource myContainerApps 'Microsoft.App/containerApps@2023-05-01' = {
  name: 'ca-myapp'
  location: location
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${uai.id}': {}
    }
  }
  properties: {
    managedEnvironmentId: containerAppsEnvironment.id
    configuration: {
      ingress: {
        external: false
        targetPort: 8888
        allowInsecure: false
        traffic: [
          {
            latestRevision: true
            weight: 100
          }
        ]
      }
      registries: [
        {
          identity: uai.id
          server: containerRegistry.properties.loginServer
        }
      ]
    }
    template: {
      containers: [
        {
          name: 'ca-myapp'
          image: acrDefaultImage
          resources: {
            cpu: json('.25')
            memory: '.5Gi'
          }
        }
      ]
      scale: {
        minReplicas: 1
        maxReplicas: 10
        rules: [
          {
            name: 'http-requests'
            http: {
              metadata: {
                concurrentRequests: '10'
              }
            }
          }
        ]
      }
    }
  }
}

output endPoint string = myContainerApps.properties.configuration.ingress.fqdn

After the creation of the container app, the next versions are deployed using GitHub actions.

But the issue is that if I want to redeploy my bicep template, it will remove the last version of my app deployed via GitHub Actions, and put the hello-wolrd container instead, which breaks my app.

Is there a way, to tell bicep not to replace my container if it already exists ? Or maybe create a container without setting an image ?

[ahelland]

Your container environment and your containers are most likely on different life cycles. As in "apps are deployed multiple times a day, the environment not so much".

The cleaner and probably easier solution is to split these tasks:

• Deploy an empty container app environment along with supporting components.
• Have a separate Bicep file for deploying the container with a reference to which environment it should go into.

This also scales better when you have multiple containers and you get GitHub Actions to loop through all of them and deploy.

[abouroubi]

I need to deploy them both at the same time, as the output of my container apps is needed in another part of the deployment.

Also to add a precision, the GitHub deployment is not using Bicep, it's using the official Container App action.

[ahelland]

Conditionals in Bicep are currently a compile time constraint. So, you can feed in a bool as true or false from a param file, and then only deploy a resource if the param is true.

You can't dynamically have Bicep query the Azure APIs and branch off accordingly in real time.

You don't have to provision a working image for a container app, but haven't tried creating it with a null value. Either way those would be hackish workarounds.

Which output from the container do you need somwhere else in the deployment? The endpoint/fqdn as shown above?

You can work with implicit and expllicit dependencies when in the same Bicep file - like in your instance that the app understands that the environment needs to be created first.

But you can also "import" the resource by using the existing key word:

resource myContainerApps 'Microsoft.App/containerApps@2023-05-01' existing = { ... }

resource record 'Microsoft.Network/dnsZones/A@2018-05-01' = {
  name: '${dnsZone.name}/${myContainerApps.endpoint}'
  properties: {
    TTL: 3600
    ARecords: [
      {
        ipv4Address: ipAddress
      }
    ]
  }
}

You'll fairly quickly be "forced" to use modules as well so might as well restructure things.

I haven't tried the Container App action - that obviously adds some abstraction on top of the lower level details.

[Azure-Dotnet-Dev]

This issue is still valid and the use case is too.
Deployment Stacks allow you to define your entire application state in one place.
It makes sense for a container app to live with the environment when using stacks, especially when you're also defining RBAC in the same stack.
containerApp identity hooks into DB, Redis, Blob, ServiceBus.

Let's say I have an infrastructure repo and pipeline, that creates my Azure stack.
I then have a simple application pipeline that deploys the binaries to one of the stack components.
By not being able to define the container app in the stack too, this pipeline must now also manage some of the infrastructure.

This problem could be solved if the container image could be a child resource of containerApp (e.g. Microsoft.App/containerApps/containerImage@2025-07-01) and then using the fairly new but GA decorator onlyIfNotExists()

Example usage could be:

resource myContainerApps 'Microsoft.App/containerApps@2025-01-01' = {
  name: 'ca-myapp'
  location: location
  properties: {
    managedEnvironmentId: containerAppsEnvironment.id
    configuration: {}
  }
}

@onlyIfNotExists()
resource myContainerImage 'Microsoft.App/containerApps/containerImage@2025-01-01' = {
  name: 'ca-myapp'
  parent: myContainerApps
  properties: {
    containers: [
      {
        name: 'ca-myapp'
        image: acrDefaultImage
        resources: {
          cpu: json('.25')
          memory: '.5Gi'
        }
      }
    ]
  }
}