Azure Logic Apps CI/CD using GitHub

Question

Azure Logic Apps CI/CD using GitHub

Christopher Fryett 145

We are building out the CI/CD pipeline for Azure Logic Apps and Function Apps using GitHub. The connections seems to be the greatest challenges and to overcome the Function Apps we are using parameters and Azure Key Vault. Is there a simplified already cookie cutter set of GitHub scripts with recommendations on building out a fully automated pipeline? Is anyone using parameters for pre-built connectors like the SQL Server? Is ADO a better option and simplified? Any insight is appreciated.

Anurag Rohikar 3,110 Reputation points Microsoft External Staff Moderator

2025-11-27T10:20:02.9033333+00:00
Hello Christopher Fryett,

Thank you for posting this question on the Microsoft Q&A portal. I understand you're working on building a streamlined CI/CD pipeline for Logic Apps and Function Apps using GitHub, and much of the complexity revolves around managing connections and parameterizing prebuilt connectors like SQL Server.

There are some good starting points you can look at. Microsoft provides deployment examples for Logic Apps Standard that show how to structure your workflows, connections.json, parameters, and environment-based overrides. You can review those samples here: Azure-Samples/azure-logic-apps-deployment-samples

There is also another community-supported sample that demonstrates end-to-end GitHub deployment patterns: Logic-App-Standard-Deployment

For official guidance on how Logic Apps Standard should be deployed using GitHub or Azure DevOps pipelines, the documentation here is accurate and up to date: Set up DevOps deployment for Standard logic apps in single-tenant Azure Logic Apps

Regarding your question about SQL Server connectors: yes, parameterizing connection details and securing secrets in Key Vault is the recommended approach. Logic Apps support parameterization of connection strings or managed identities per environment. This approach is covered here: Automate build and deployment for Standard logic app workflows with Azure DevOps

Regarding GitHub vs Azure DevOps, both works. GitHub Actions is perfectly fine if your team already lives in GitHub and wants lightweight pipelines. Azure DevOps may be simpler if you prefer structured multi-stage pipelines and tighter control over parameter overrides. It really depends on how your team manages environments and secrets today.

To help provide more tailored advice:

Are you deploying Logic Apps in Standard or Consumption mode?

Do you expect connections to be created automatically per environment?

Do your SQL connectors authenticate using managed identities or connection strings?

How do you currently manage secrets via Key Vault references within Logic Apps or injected through pipeline variables?

I hope the above helps. Please do let us know if you have any further questions on this. Thank you!
Anurag Rohikar 3,110 Reputation points Microsoft External Staff Moderator

2025-11-28T08:57:05.3+00:00

Hello Christopher Fryett, following up to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this. Thank you!
Anurag Rohikar 3,110 Reputation points Microsoft External Staff Moderator

2025-12-01T08:53:27.7533333+00:00

Hello Christopher Fryett, just checking to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this. Thank you!
Christopher Fryett 145 Reputation points

2025-12-02T01:06:55.2+00:00

@Anurag Rohikar Thank you for the information. We currently use Windows authentication for our on-premises SQL servers through a data gateway because the built-in connector does not support on-premises SQL servers.

The issue we are encountering now is that when we try to parameterize the server name, authentication fails and returns a 401 error. If I deploy from Visual Studio Code using the ZIP file exported from our development environment and deploy it to QA, the “Connect to server-amount-db” setting appears correctly, but the server name remains the development one instead of QA.

To resolve this, I have to manually update the server name in each flow that uses a SQL connector. To overcome this in the pipeline, we created a parameter that points to the appropriate server name. However, when running the workflow, it returns an “Unauthorized” error.

Do you have any suggestions? If the connector does not reside within our VNET, using managed identities is likely not a viable option.
Christopher Fryett 145 Reputation points

2025-12-02T15:29:29.0333333+00:00

Thank you for the response. I made sure I stayed consistent when creating the API connections for each environment the names were the same. As a result what I see during deployment is the right db server in the connection but the server name stays the same. Using parameters for the server name in the connector it does not seem to bind the value. If I take the workflow from GitHub during the deployment to the development environment it doesn’t even work. It seems the shared sql server connector needs a level of binding manually as a parameter in the server name isn’t working. It was also mentioned to use Azure Arc which will allow using managed identities for the onprem sql server. Would this resolve the issue or will the binding still be an issue at the connector level?
Gordon 11 Reputation points

2025-12-02T18:28:59.03+00:00

@Anurag Rohikar Per some of the documentation you shared (https://learn.microsoft.com/en-us/azure/logic-apps/authenticate-with-managed-identity?tabs=standard#where-you-can-use-a-managed-identity) connecting to a SQL Server with Azure Arc enabled via standard logic app system assigned managed identity is also supported. Does that sound accurate? I understand there is some additional configuration that needs to be done on the DB side.
Anurag Rohikar 3,110 Reputation points Microsoft External Staff Moderator

2025-12-03T10:30:33.95+00:00
Hello Gordon,

You’re right. For Standard logic apps, connecting to SQL Server using the SQL built‑in connector and a system‑assigned (or user‑assigned) managed identity is supported, provided the SQL Server endpoint itself is configured to accept Microsoft Entra authentication, which is possible for Azure Arc–enabled SQL Server. There is some extra setup on the SQL side to enable Entra authentication and map the managed identity to a contained database user with the right permissions, but once that’s done, the Logic App’s managed identity can authenticate directly without storing SQL credentials. Microsoft’s documentation confirming this is here: Where you can use a managed identity
Additional References:

SQL Server - Connector

Managed identity for SQL Server enabled by Azure Arc

I hope this helps. If the above previous comments helped kindly upvote. Thank you!

Answer accepted by question author

0 additional answers

Your answer

Anurag Rohikar 3,110 Reputation points Microsoft External Staff Moderator

2025-11-28T08:57:05.3+00:00

Hello Christopher Fryett, following up to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this. Thank you!
Anurag Rohikar 3,110 Reputation points Microsoft External Staff Moderator

2025-12-01T08:53:27.7533333+00:00

Hello Christopher Fryett, just checking to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this. Thank you!
Christopher Fryett 145 Reputation points

2025-12-02T01:06:55.2+00:00

@Anurag Rohikar Thank you for the information. We currently use Windows authentication for our on-premises SQL servers through a data gateway because the built-in connector does not support on-premises SQL servers.

The issue we are encountering now is that when we try to parameterize the server name, authentication fails and returns a 401 error. If I deploy from Visual Studio Code using the ZIP file exported from our development environment and deploy it to QA, the “Connect to server-amount-db” setting appears correctly, but the server name remains the development one instead of QA.

To resolve this, I have to manually update the server name in each flow that uses a SQL connector. To overcome this in the pipeline, we created a parameter that points to the appropriate server name. However, when running the workflow, it returns an “Unauthorized” error.

Do you have any suggestions? If the connector does not reside within our VNET, using managed identities is likely not a viable option.
Christopher Fryett 145 Reputation points

2025-12-02T15:29:29.0333333+00:00

Thank you for the response. I made sure I stayed consistent when creating the API connections for each environment the names were the same. As a result what I see during deployment is the right db server in the connection but the server name stays the same. Using parameters for the server name in the connector it does not seem to bind the value. If I take the workflow from GitHub during the deployment to the development environment it doesn’t even work. It seems the shared sql server connector needs a level of binding manually as a parameter in the server name isn’t working. It was also mentioned to use Azure Arc which will allow using managed identities for the onprem sql server. Would this resolve the issue or will the binding still be an issue at the connector level?
Gordon 11 Reputation points

2025-12-02T18:28:59.03+00:00

@Anurag Rohikar Per some of the documentation you shared (https://learn.microsoft.com/en-us/azure/logic-apps/authenticate-with-managed-identity?tabs=standard#where-you-can-use-a-managed-identity) connecting to a SQL Server with Azure Arc enabled via standard logic app system assigned managed identity is also supported. Does that sound accurate? I understand there is some additional configuration that needs to be done on the DB side.
Anurag Rohikar 3,110 Reputation points Microsoft External Staff Moderator

2025-12-03T10:30:33.95+00:00

Hello Gordon,

You’re right. For Standard logic apps, connecting to SQL Server using the SQL built‑in connector and a system‑assigned (or user‑assigned) managed identity is supported, provided the SQL Server endpoint itself is configured to accept Microsoft Entra authentication, which is possible for Azure Arc–enabled SQL Server. There is some extra setup on the SQL side to enable Entra authentication and map the managed identity to a contained database user with the right permissions, but once that’s done, the Logic App’s managed identity can authenticate directly without storing SQL credentials. Microsoft’s documentation confirming this is here: Where you can use a managed identity
Additional References:

SQL Server - Connector

Managed identity for SQL Server enabled by Azure Arc

I hope this helps. If the above previous comments helped kindly upvote. Thank you!

Answer 1

Hello Christopher Fryett,

Thank you for the update and for explaining how your SQL connection is configured. I understand the challenge now: since you're using Windows authentication through an on-premises Data Gateway, the SQL connector binds the gateway connection, stored Windows credentials, and target SQL server together when the connection is first created. When that connection definition is effectively reused against a different server by only changing the server's name at runtime, the authentication fails and results in 401 in QA.

With Logic Apps + On-Premises Gateway, the connection resource (in connections.json) stores a static mapping of: Connection → Gateway → On-Prem SQL server → Auth method.

The gateway uses the stored credential and connection metadata to reach your on-prem SQL server; it does not dynamically re‑negotiate against arbitrary servers at runtime. Because of this, when you deploy a ZIP from Dev to QA, QA is still using the Dev connection definition and credential, which is why it continues to reference the Dev server until you manually recreate or rebind the connection.

For this setup, the connector must be recreated per environment, and the gateway mapping needs to match the server's name used in that environment. In other words, the SQL connection resource in QA cannot reuse Dev’s server name or Dev’s connection definition.

A couple of things that may help:

Create a separate SQL connector connection per environment (Dev/QA/Prod), each created in that environment and authorized once against the correct gateway and server. Then reference the appropriate connection in your workflow for that environment but avoid parameterizing only the server's name inside the SQL action. The server and gateway pairing should match what the connection was created with.
References: Install on-premises data gateway for workflows in Azure Logic Apps,
If your pipelines are overwriting connections.json or similar artifacts, ensure that the connectionId and backend details in that file map to an existing QA SQL connection that you created and authorized in QA. The connection resource should exist and be valid in QA before you deploy or update the workflows so that the actions can bind cleanly to it. References: Connect to on-premises data sources from Azure Logic Apps
Unfortunately, managed identities can’t help here because the on-prem SQL + gateway connector doesn’t support MI. Windows auth through gateway strictly binds to the gateway connection resource.
References: Authenticate access and connections to Azure resources with managed identities in Azure Logic Apps, Connect to SQL databases from workflows in Azure Logic Apps

I hope the above helps. Please do let us know if you have further questions on this. Thank you!

Share via

Azure Logic Apps CI/CD using GitHub

0 additional answers

Your answer