10 posts tagged with "Azure Container Apps"

In the world of computing, slash commands have a proud and noble history. They are a way to interact with a system by typing a command into a chat or terminal, usually with a / preceding the command; hence the name "slash commands". GitHub has its own slash commands that you can use in issues and pull requests to add code blocks and tables etc. The slash commands are, in truth, quite limited.

However, through clever use of the GitHub Actions platform, it's possible to build something quite powerful which is "slash-command-shaped". In this post, we'll look at how to implement a /deploy slash command which, when invoked in a pull request, will deploy an Azure Container App with GitHub Actions.

The technique we'll use is covering a deployment usecase, as we'll see, it could be adapted to many other scenarios.

When deploying Azure Container Apps from Azure DevOps, you can use the azd command to speed up deployments that do not affect infrastructure. Given that when you're deploying, it's far more common to be making a code and / or content change and not an infrastructure one, this can be a significant time saver.

If you're looking for information on how to use azd to speed up deployments of Azure Static Web Apps in GitHub Actions, then you might want to read this post.

Imagine you're deploying a solution to Azure. It'll feature some resources like a database or a storage account. How do can you configure your application with access to these resources? One approach would be using Managed Identity. Another approach is configuring the connection strings and access keys in our application's configuration store as the Bicep templates are deployed. This is a common approach when working with Azure Functions, Azure Static Web Apps, Azure Container Apps and similar.

A wonderful aspect of this approach is that no human need ever get to see the connection strings / access keys. They'll be discovered and consumed by Azure during a deployment, and known to your application at runtime, but untrustworthy humans need never get to see them. This is secure, and therefore good.

Azure Container Apps supports custom domains via certificates. If you're looking to make use of the managed certificates in Azure Container Apps using Bicep, then you might want to take a look at this post on the topic.

This post will instead look at how we can use the "bring your own certificates" approach in Azure Container Apps using Bicep. Well, as much as that is possible; there appear to be limitations in what can be achieved with Bicep at the time of writing.

Azure Container Apps support managed certificates and custom domains. However, deploying them with Bicep is not straightforward - although it is possible. It seems likely there's a bug in the implementation in Azure, but I'm not sure. Either way, it's possible to deploy managed certificates and custom domains using Bicep. You just need to know how.

If, instead, you're looking to make use of the "bring your own certificates" approach in Azure Container Apps using Bicep, then you might want to take a look at this post on the topic.

Updated 08/11/2025 - with bindingType: 'Auto' you can deploy in one go​

Since originally writing this post, the need to use multiple pipeline runs to deploy has been resolved. It is now possible to deploy managed certificates and custom domains to Azure Container Apps using a single Bicep deployment. To do that you'll need to use the Microsoft.App containerApps 2025-07-01 API version (or newer).

That API version introduced the ability to create a managed certificate resource without needing to first create a disabled custom domain on the container app. This means you can now do it all in one go. This is achieved with the use of a new bindingType value of Auto on the customDomains property.

Using the new approach, the Bicep required to create a managed certificate and custom domain looks like this:

resource containerApp 'Microsoft.App/containerApps@2025-07-01' = {
  //...
  properties: {
    configuration: {
      //...
      ingress: {
        //...
        customDomains: empty(customDomainName) ? [] : [
          {
            name: customDomainName
            bindingType: 'Auto'
          }
        ]
        //...
      }
      //...
    }
    //...
  }
  //...
}

resource managedEnvironmentManagedCertificate 'Microsoft.App/managedEnvironments/managedCertificates@2025-07-01' = if (!empty(customDomainName)) {
  parent: managedEnvironment
  name: '${managedEnvironment.name}-cert'
  location: location
  tags: tags
  properties: {
    subjectName: customDomainName
    domainControlValidation: 'CNAME'
  }
  dependsOn: [
    containerApp
  ]
}

azd deploy with Microsoft.App containerApps 2025-07-01​

If you're using Azure Developer CLI (azd) to deploy your Azure Container Apps, as described in this post, then you'll find that an issue can present when you try to deploy the custom domain and managed certificate using the Microsoft.App/containerApps@2025-07-01 API version.

The following error shows up when using azd deploy:

ERROR: failed deploying service 'app': updating container app service: getting container app: getting container app: unmarshalling type *armappcontainers.ContainerApp: unmarshalling type *armappcontainers.ContainerApp: struct field Properties: unmarshalling type *armappcontainers.ContainerAppProperties: struct field Configuration: unmarshalling type *armappcontainers.Configuration: struct field Ingress: unmarshalling type *armappcontainers.Ingress: struct field CustomDomains: unmarshalling type *armappcontainers.CustomDomain: struct field BindingType: json: cannot unmarshal number into Go value of type armappcontainers.BindingType
Suggestion: set 'apiVersion' on your service in azure.yaml to match the API version in your IaC:

services:
  your-service:
    apiVersion: 2025-02-02-preview

In fairness, this is a quite helpful error message. It suggests that you can resolve it by specifying the API version in your azure.yaml file like so:

# yaml-language-server: $schema=https://raw.githubusercontent.com/Azure/azure-dev/main/schemas/v1.0/azure.yaml.json

name: my-container-app
metadata:
  template: azd-init@1.9.4
services:
  app:
    image: myregistry.azurecr.io/${CONTAINER_IMAGE_NAME}:${APP_VERSION_TAG}
    host: containerapp
    resourceName: ${CONTAINER_APP_NAME}
    apiVersion: 2025-07-01

With this in place, azd deploy will work as expected. Hopefully one day, supplying the API version in azure.yaml won't be necessary. I've raised an issue about this here.

Anyway, if for some reason you can't use the Microsoft.App/containerApps@2025-07-01 API version, then you can still use the three pipeline approach described below. Back to the original post...

The dreaded message​

I've facetiously subtitled this post "a three pipe(line) problem" because it took three Azure Pipelines to get it working. This is not Azure Pipelines specific though, it's just that I was using Azure Pipelines to deploy the Bicep. Really, this applies to any way of deploying Bicep. GitHub Actions, Azure CLI or whatever.

If you're here because you've encountered the dreaded message:

Creating managed certificate requires hostname '....' added as a custom hostname to a container app in environment 'caenv-appname-dev'

Then you're in the right place. I'm going to explain how to get past that error message and get your custom domain working with your Azure Container App whilst still using Bicep. It's going to get ugly. But it will work.

Easy Auth is a great way to authenticate your users. However, when used in the context of Azure Container Apps, .NET applications do not, by default, recognise that Easy Auth is in place. You might be authenticated but .NET will still act as if you aren't. builder.Services.AddAuthentication() and app.UseAuthentication() doesn't change that. This post explains the issue and solves it through the implementation of an AuthenticationHandler.

This post shows how to build and deploy two Azure Container Apps using Bicep and GitHub Actions. These apps will communicate using dapr's publish & subscribe (pubsub) building block.

This post shows how to build and deploy two Azure Container Apps using Bicep and GitHub Actions. These apps will communicate using dapr, be built in VS Code using a devcontainer. It will be possible to debug in VS Code and run with docker-compose.

This follows on from the previous post which built and deployed a simple web application to Azure Container Apps using Bicep and GitHub Actions using the GitHub container registry.

This post shows how to build and deploy a simple web application to Azure Container Apps using Bicep and GitHub Actions. This includes the configuration and deployment of secrets.

This post follows on from the previous post which deployed infrastructure and a "hello world" container, this time introducing the building of an image and storing it in the GitHub container registry so it can be deployed.

If you'd like to learn more about using dapr with Azure Container Apps then you might want to read this post.

Azure Container Apps are an exciting way to deploy containers to Azure. This post shows how to deploy the infrastructure for an Azure Container App to Azure using Bicep and GitHub Actions. The Azure Container App documentation features quickstarts for deploying your first container app using both the Azure Portal and the Azure CLI. These are great, but there's a gap if you prefer to deploy using Bicep and you'd like to get your CI/CD setup right from the beginning. This post aims to fill that gap.

If you're interested in building your own containers as well, it's worth looking at this follow up post.