Run a Logic App in a container.

This article serves as a proof of concept to test the Logic App (Standard) “run anywhere” Microsoft statement.
Here we describe the necessary steps to make a Logic App (Standard) run in a containerized way, avoiding extra costs of having the App service running even when the workflow is not being called. By the end of this article, you will be able to also containerize your workflows, not only run and test them locally but also publish them to the cloud and see them running on Microsoft serverless container services (Azure Container Instances and/or Azure Container Apps).


Tools required to download and install locally (dev)


Local Run and Testing

  • 1. Start a Stateful logic app (standard) project with VS Code.
  • 2. Build a logic app flow in VS Code:
  • 3. Save your project and convert it to a NuGet project (.NET)
    • a. Right-Click on any of the empty space of the project files and select “Convert to NuGet-based Logic App project“.
    • b. This will generate .NET specific files and libraries and will also add a .csproj file to your project.

(This is a IREVERSIBLE change, so use it carefully if you really want to convert your project.)

  • 4. Next, we will add a “Dockerfile” to the project, this file contains instructions to build your container image.
    • a. Example for this project:
  • b. Some notes on the above “Dockerfile“:
    • – Filename must be exactly as spelled above, building the image will throw and error if it is not.
    • – Base of the image using Node.js
    • – Update environment variable “AzureWebJobsStorage” with storage account connection string.
    • –  For every different connector used in your application that needs a connection string, these have to be added as an ENV variables (i.e. service bus, blob storage & SQL server).
    • –  ENV variables cannot have spaces on their values or connection strings, these can be escaped by encapsulating the value between double quotes (“).
    • – WEBSITE_SITE_NAME is the name by which entries are created in Storage Account by the Logic App while caching its state.
    • – If we want to run based on .NET functions runtime, use “FROM“.
  • 5. At this stage we are ready to start building and testing our project; we will start by building and publishing our .NET project.
    • a. Open your Terminal in Visual Studio Code and type these 2 commands (one at a time):
  • 6. Once the last step is finished, we will (on the same terminal) create our container image with the following command:”docker build -tag <containerName> <pathToStoreContainer>
  • 7. With this you can run your container containing your built image, just typing this command in your terminal window.
  • 8. If everything is gone as planned your app is now running locally and waiting for something to trigger the workflow, in this case a message on a topic of the service bus.
  • 10. As a side note, the created image and running container can be checked also in the Docker Desktop application.
  • 11. Once the workflow is triggered you can see all steps running in the terminal log.

Cloud Run and Testing

After you have your project finished and tested locally you can now deploy it to the cloud services:

(Docker Desktop should be running for all these steps)

  • 2. Back on our VS Code project Terminal we need to login into our Azure environment (if you are not logged in), and login to our recently created Azure Container registry.
  • 3. Also in the VS code terminal, we are going to update the name of our container image to match the Azure container registry just created:
  • 4. We will now deploy our local image to Azure Container registry, push it to the cloud with this command in the terminal:
    • a. After the push you can delete it locally if you wish with this terminal command (don’t worry, won’t remove from the registry, just locally)
    • b. Another curiosity, if the image is deleted locally and we try to run it locally, docker first checks if the image is present locally, if not, he gets it from the registry online.
    • c. If another colleague developer wants to work locally with an image he can also do so by pulling it from the docker server or from azure container services.

Azure Container Instances (OLD)

  • – Better for 1 or multiple containers that do not need too much communication between each other.
    • ο Applications that are just a single container, Azure Container Instances is a great fit.
  • – This is great for running certain processes that are not a web application or background worker.
  • – Not scalable to 0 instances, so a cost is always associated, always running.
  • 1. Create an Azure Container Instance on azure portal based on your container registry image previously deployed.
  • 2. Once it is deployed, you Logic app should up and running:
  • 3. You can now Test it and check the logs of your Logic App run within the container Log:

Azure Container Apps (NEW)

  • – Underneath is Kubernetes, we can call it a “Kubernetes to Go”.
  • – Use it when you do not need all that Kubernetes has to offer and all the maintenance attached with it.
  • – When we need to have multiple containers communicating within an environment (frontend/backend/database) this is the better solution.
  • – Great with CICD integration, direct connection to GitHub.
  • – Less Maintenance and higher scalability since it uses Kubernetes event-driven auto scale (rules to be set).


  • – Managed identities is currently not yet supported to connect to other resources (databases, queues, …)
  • – Linux Based images only.
  • – (Specific for Logic app or function) Logs needs to be built in the app, currently there is no REST api to retrieve the logs or a way to see the logic app run.
  • 1. Enabling Admin user and password in the container registry; this will allow the container app to be created using an image that is stored on the registry:

Want to know more about working at

Let’s get in touch!

    Yes, I would like to receive the newsletter

    Yes, I agree with the terms & conditions