How to resolve the Azure LinuxDynamicWorkersNotAllowedInResourceGroup Error

 A few weeks ago, I started to fix some issues on an existing Azure pipeline for deploying cloud resources. It’s an enterprise system which was running since a year without problems. After some changes I decided to redeploy the infrastructure. What can happen? Nothing has bee changed except of a naming. But then I ran in an error

”code”: “LinuxDynamicWorkersNotAllowedInResourceGroup”, “message”: “Linux dynamic workers are not available in resource group [name of our resource group].”

Why is this happen? We did not change much in the infrastructure. The deployment script was running very well. But now one year later, this error appears suddenly.

After googeling I found this gitHub issue. Which actually just redirects to a long list of announcements of the Azure App Service. Okay, but this is not a solution. I need one.

A short discussion with my colleagues and the dev community, I learned that error is more or less a glitch and can be fixed by some workarounds. But I don’t like workarounds, I need a fix for my deployment script.

What does it mean, this error?

At the moment, it’s not possible to deploy a Y1 Dynamic App Service Plan type Linux in a resource group, where already an App Service Plan was deployed. I did not test any configuration, maybe with a Windows Plan anything works well. But in my case, I tried to create an App Service Plan S1 Standard Linux and an Azure Function App, hosted in a consumption (Y1 Dynamic) Linux plan, into one resource group.

The deployment is developed as an Infrastructure as Code (IaC) solution in Bicep. Here I set up the resources I need in a very simple way. I describe and list the resources and at execution the resources will be created in a specific order. In my case, I found out the order of App Service Plan creation is important. Usually it is not.

So my solution now is to set the App Service Plans in dependency. First the Y1 Dynamic Plan needs to be created and then the S1 Plan. In Bicep, it is very simple.

The keyword in Bicep is dependsOn.

 A Bicep module provides a parameter, a list of resources on what this module depends. First the depended resource needs to be created, then the module will be created.

After this small change in my deployment script the Linux… Error disappeared.

I hope it helps you too.