How to Use an Existing Azure Container Registry and Container Apps Environment in .NET Aspire Instead of Creating New Ones?

I think that… Aspire just can’t re-use an existing ACR or ACA env yet — even AsExisting still sneaks in create ops. the only thing that’s held up for me is pulling them as real existing in a tiny bicep and wiring the ids back into apphost by hand. after that, Aspire finally stops being clever and just deploys where u tell it to.

Hi @Varghese Jiju Thomas (SEIT) ,

Currently, there is an open issue in the .NET Aspire repository (Issue #12977 and #9094) where using AsExisting() on an Azure Container App Environment ignores the instruction and generates underlying Bicep templates that still attempt to create a brand-new environment alongside its child resources (like the ACR, Log Analytics Workspace, etc.).

Because of this bug, azd up ends up either failing due to permission issues (trying to recreate existing resources) or silently creating duplicate infrastructure.

Workaround: Use Custom Bicep (AddBicepTemplate)

Until the Aspire team releases a fix for the ACA Environment Bicep generation, the most reliable workaround is to bypass Aspire's built-in AddAzureContainerAppEnvironment method and instead bring in your existing infrastructure using a custom Bicep template.

You can create a custom Bicep file that uses the existing keyword to reference your ACA environment and ACR:

existing-infra.bicep

param environmentName string
param acrName string
// Reference existing ACA Environment
resource existingEnv 'Microsoft.App/managedEnvironments@2023-05-01' existing = {
  name: environmentName
}
// Reference existing ACR
resource existingAcr 'Microsoft.ContainerRegistry/registries@2023-07-01-preview' existing = {
  name: acrName
}
// Output the IDs so Aspire/azd can use them
output environmentId string = existingEnv.id
output acrLoginServer string = existingAcr.properties.loginServer

Program.cs (AppHost)

var builder = DistributedApplication.CreateBuilder(args);
// Add the custom bicep template
var existingInfra = builder.AddBicepTemplate("existing-infra", "existing-infra.bicep")
       .WithParameter("environmentName", "your-existing-aca-env-name")
       .WithParameter("acrName", "your-existing-acr-name");
// ... continue deploying your apps

This bypasses the faulty Bicep generation of the built-in ACA extension and forces azd to deploy your application into the infrastructure that you have already provisioned.

Please let me know if it helps and any further assistance is needed.