Create Standard logic app workflows for hybrid deployment on your own infrastructure

Applies to: Azure Logic Apps (Standard)

For scenarios where you need to use, control, and manage your own infrastructure, create Standard logic app workflows by using the hybrid deployment model in Azure Logic Apps. This model provides capabilities for you to build and host integration solutions for partially connected environments that require local processing, storage, and network access. Your infrastructure can include on-premises systems, private clouds, and public clouds. By using the hybrid model, your Standard logic app workflow is powered by the Azure Logic Apps runtime, which is hosted on your infrastructure as part of an Azure Container Apps extension.

For an architectural overview that shows where Standard logic app workflows are hosted and run in a partially connected environment, see Set up infrastructure requirements for hybrid deployment for Standard logic apps.

This how-to guide shows how to create and deploy a Standard logic app workflow by using the hybrid deployment model after you set up the necessary resources for hosting your app.

Limitations

For the current supported Azure regions, supported Kubernetes clusters, and platform-wide limitations, see Limitations for hybrid deployment.

The following limitations apply when you create and operate hybrid logic apps:

Behavior during an Azure connectivity interruption

• Workflows might still continue running if the runtime and all required workflow dependencies stay locally available.
• Built-in operations run with the local runtime, but any external service called by an operation must remain reachable.
• Managed connector operations require connectivity to their Azure-hosted services.
• Azure portal management, Azure-based deployment, identity operations, and telemetry delivery might become unavailable or delayed.
• If the runtime stays disconnected after 24 hours, you might lose logging data generated after this time.

If your workloads require deployment, monitoring, alerting, run resubmission, or identity operations during an extended disconnection, validate the behavior for your specific configuration with your Microsoft account or product team.

Prerequisites

• An Azure account and subscription. If you don't have a subscription, sign up for a free Azure account.

• The following customer-managed resources, which must all exist within the same network for the required connectivity:

  • A supported Kubernetes cluster that is connected to Azure Arc
  • A SQL database to locally store workflow run history, inputs, and outputs for processing
  • A Server Message Block (SMB) file share to locally store artifacts used by your workflows

  To meet these requirements, set up these resources to support hybrid deployment for Standard workflows.

• To work in Visual Studio Code, you need the Azure Logic Apps (Standard) extension for Visual Studio Code with the related prerequisites.

  Tip

  If you have a new Visual Studio Code installation, confirm that you can locally run a basic Standard workflow before you try deploying to your own infrastructure. This test run helps isolate any errors that might exist in your Standard workflow project.

Create your Standard logic app

Versioning for hybrid deployments

A Standard logic app with the hybrid hosting option automatically creates a new revision, which is a versioning concept from Azure Container Apps, whenever you save changes to a child workflow. This revision might take a little time to activate, which means that after you save any changes, you might want to wait several moments before you test your workflow.

If your changes still haven't appeared in the workflow, you can check whether the revision exists:

1. In the Azure portal, open your resource. On the resource menu, under Revisions, select Revisions and replicas.

2. On the Revisions and replicas page, on the Active revisions tab, check whether a new revision appears on the list.

For more information, see the following resources:

• Update and deploy changes in Azure Container Apps

• Manage revisions in Azure Container Apps

Set up enhanced telemetry or OpenTelemetry for performance monitoring

You can set up enhanced telemetry collection in Application Insights for your Standard logic app and then view the collected data after your workflow finishes a run. This capability gives you a simpler experience to get insights about your workflows and more control over filtering events at the data source, which helps you reduce storage costs. These improvements focus on real-time performance metrics that provide insights into your system's health and behavior.

For partially connected and on-premises scenarios, you can set up your Standard logic app to emit telemetry based on the OpenTelemetry-supported app settings that you define for the specific environment. By default, this telemetry data is sent to Application Insights. For more information, see Enable enhanced telemetry in Application Insights for Standard workflows in Azure Logic Apps.

Application Insights requires Azure connectivity. During connectivity interruption, telemetry delivery might encounter delays, and you might lose logging data generated after 24 hours. Validate any requirement for local monitoring and alerting against the telemetry destination and configuration that you use.

Change vCPU and memory allocation in the Azure portal

You can edit the vCPU and memory settings for your Standard logic app resource. These changes affect the billing charge for your Standard logic app workloads.

1. In the Azure portal, open your Standard logic app resource.

2. On the resource menu, under Settings, select Containers.

3. On the Containers page toolbar, select Edit and deploy, which opens the Edit a container pane.

4. On the Properties tab, under Container resource allocation, change the following values to fit your scenario:

   Property	Value	Description
   CPU cores	- Default: 1 - Minimum: 0.25 - Maximum: 2	Determines the vCPU cores to assign to your container instance. You can increase this value by 0.25 cores up to the maximum value. The total number across all container instances for this logic app is limited to 2 cores.
   Memory	- Default: 2 - Minimum: 0.1 - Maximum: 4	Determines the memory capacity in gibibytes (GiB) to assign to your container instance. You can increase this value by 0.1 GiB up to the maximum value. The total capacity across all container instances for this logic app is limited to 4 GiB.

5. When you finish, select Save.

Change replica scaling in Azure portal

You can control the automatic scaling for the range of replicas that deploy in response to a trigger event. A replica is a new instance of a logic app resource revision or version. To change the minimum and maximum values for this range, you can modify the scale rules to determine the event types that trigger scaling. For more information, see Set scaling rules in Azure Container Apps.

1. In the Azure portal, open your Standard logic app resource.

2. On the resource menu, under Settings, select Scale.

3. On the Scale page, under Scale rule setting, change the following values to fit your scenario:

   Property	Value	Description
   Min replicas	- Default: 1 - Minimum: 0 - Maximum: 1000	Determines the minimum number of replicas allowed for the revision at any given time. This value overrides scale rules and must be less than the maximum number of replicas.
   Max replicas	- Default: 30 - Minimum: 0 - Maximum: 1000	Determines the maximum number of replicas allowed for the revision at any given time. This value overrides scale rules.

4. When you finish, select Save.

Control inbound traffic to your logic app in Azure portal

You can expose your logic app to the public web, your virtual network, and other logic apps in your environment by enabling ingress. Azure enforces ingress settings through a set of rules that control the routing of external and internal traffic to your logic app. When you enable ingress, you don't need to create an Azure Load Balancer, public IP address, or any other Azure resources to enable incoming HTTP requests or TCP traffic. For more information, see Ingress in Container Apps.

1. On the resource menu, under Settings, select Ingress.

2. On the Ingress page, next to Ingress, select the Enabled box.

3. Based on your scenario, configure the remaining options.

   For more information, see the following documentation:

   • Configure ingress for your app in Azure Container Apps
   • Set up IP ingress restrictions in Azure Container Apps

Set up authentication for managed API connections

Managed API connections don't currently support managed identity authentication in hybrid logic apps. To authenticate these connections, you must create your own app registration by using Microsoft Entra ID. You can then add this app registration's values as environment variables in your Standard logic app resource. This authentication model requires connectivity to Microsoft Entra ID.

Create an app registration with Microsoft Entra ID

Azure portal

1. In the Azure portal, follow Quickstart: Register an application with the Microsoft identity platform to create an app registration.

2. After creation completes, find your new app registration in the portal.

3. On the resource menu, select Overview, and save the following values, which you need later for connection authentication:

   • Client ID
   • Tenant ID

4. On the resource sidebar, select Certificates & secrets > Client secrets > New client secret.

5. Create the client secret, and immediately save the secret's Value. The value doesn't appear again after you leave the page.

6. For the object ID, follow these steps:

   1. On the Overview page, select Managed application in local directory link for your app registration as shown:

      

   2. On the page that opens, copy and save the Object ID value:

      

7. Now, add the saved values as environment variables to your Standard logic app resource.

Azure CLI

1. To create an app registration and its service principal without assigning an Azure role, run the following command:

   az ad sp create-for-rbac \
      --name <app-registration-name> \
      --skip-assignment
   

2. From the command output, save the appId, password, and tenant values as for the client ID, client secret, and tenant ID values. The client secret appears only in the command output.

3. Get the service principal object ID:

   az ad sp show \
      --id <client-ID> \
      --query id \
      --output tsv
   

4. Now, add the saved values as environment variables to your Standard logic app resource.

For more information, see:

• az ad sp create-for-rbac
• az ad sp show

Add app registration values to your Standard logic app

1. In the Azure portal, go to your Standard logic app resource.

2. On the resource menu, under Settings, select Containers, and then select the Environment variables tab.

   For more information about app settings and host settings, see Edit app settings and host settings.

3. On the toolbar, select Edit and deploy.

4. On the Edit a container pane, select Environment variables, and then select Add.

5. From the following table, add each environment variable with the specified value:

   Environment variable	Value
   WORKFLOWAPP_AAD_CLIENTID	<my-client-ID>
   WORKFLOWAPP_AAD_OBJECTID	<my-object-ID>
   WORKFLOWAPP_AAD_TENANTID	<my-tenant-ID>

6. When you finish, select Save.

Store and reference the client secret

Store the client secret as a secret in your logic app resource. Reference that secret from the WORKFLOWAPP_AAD_CLIENTSECRET environment variable.

1. In the Azure portal, go to your logic app resource.

2. On the logic app sidebar, under Settings, select Secrets.

3. On the toolbar, select Add.

4. On the Add secret pane, provide the following information, and then select Add:

   Key	Value
   WORKFLOWAPP_AAD_CLIENTSECRET	<my-client-secret>

5. On the logic app sidebar, under Settings, select Containers, and then select the Environment variables tab.

6. On the toolbar, select Edit and deploy.

7. Add the WORKFLOWAPP_AAD_CLIENTSECRET environment variable, select the option to reference a secret, and select the secret that you created.

8. When you finish, select Save.

Known issues and troubleshooting

The following section describes currently known issues and guidance for troubleshooting common problems.

General environment setup or portal deployment problems

To help you diagnose and debug problems with your environment configuration or portal deployment failures, you can try running the troubleshoot.ps1 PowerShell script provided for the hybrid deployment option.

1. Go to the Azure Logic Apps GitHub repository: scripts/hybrid folder.

2. Copy the troubleshoot.ps1 file to a folder in the same on-premises location as your logic app deployment.

3. Run the script using PowerShell.

Arc-enabled Kubernetes clusters

In rare scenarios, you might notice a high memory footprint in your cluster. To prevent this issue, either scale out or add autoscale for node pools.

Function host isn't running

After you deploy your Standard logic app, confirm that your app is running correctly.

1. In the Azure portal, open your logic app resource.

2. On the resource menu, select Overview.

3. On the Overview page, next to the Application Url field, select the resource URL.

   If your app is running correctly, a browser window opens and shows the following message:

   

   Otherwise, if your app has any failures, check that your Kubernetes pods are running correctly. Ensure that kubectl uses the context for your cluster, and then run the following commands:

   kubectl get ns
   kubectl get pods -n logicapps-aca-ns
   kubectl describe pod {logic-app-pod-name} -n logicapps-aca-ns 
   

   For more information, see the following documentation:

   • Command line tool (kubectl)

Cluster doesn't have enough capacity

If you ran the previous command and get a warning similar to the following example, your cluster doesn't have enough nodes for processing:

Warning: FailedScheduling  4m52s (x29 over 46m)  default-scheduler  0/2 nodes are available: 2 Too many pods. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod.

For AKS, increase the number of nodes, and set up autoscale by following these steps:

1. In the Azure portal, go to your Kubernetes service instance.

2. On the instance menu, under Settings, select Node pools.

3. On the Node tools page toolbar, select + Add node pool.

For more information, see the following documentation:

• Create node pools for a cluster in Azure Kubernetes Service (AKS)
• Manage node pools for a cluster in Azure Kubernetes Service (AKS)
• Cluster autoscaling in Azure Kubernetes Service (AKS) overview
• Use the cluster autoscaler in Azure Kubernetes Service (AKS)

For OpenShift or RKE2, use the supported procedure for your Kubernetes distribution to add capacity.

SMB Container Storage Interface (CSI) driver not installed

After you ran the earlier kubectl describe pod command, if the following warning appears, confirm whether the CSI driver for your SMB file share is installed correctly:

Warning FailedScheduling 5m16s (x2 over 5m27s)  default-scheduler 0/14 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/14 nodes are available: 14 Preemption is not helpful for scheduling.

Normal NotTriggerScaleUp 9m49s (x31 over 14m) cluster-autoscaler pod didn't trigger scale-up: 3 pod has unbound immediate PersistentVolumeClaims

To confirm, run the following command:

kubectl get csidrivers

If the results don't include smb.csi.k8s.io, follow the distribution-specific instructions to install the SMB driver.

To check the CSI SMB driver pod status, run the following command:

kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=csi-driver-smb" --watch

Related content

• Set up requirements for Standard logic app deployment on your own infrastructure
• Enable enhanced telemetry in Application Insights for Standard workflows in Azure Logic Apps
• Why migrate from BizTalk Server to Azure Logic Apps Standard?
• Migrate BizTalk Server with Azure Logic Apps Migration Agent