Forum Discussion
Unable to connect Microsoft Fabric Git Integration with Azure DevOps Server (On-Premises)
Hi Team,
I am trying to connect a Microsoft Fabric workspace to Azure DevOps Server 2020 Update 1.1 (On-Premises) using Git Integration.
Git Integration is enabled in the Fabric Admin Portal, and I have Workspace Admin access.
However, when I add the Azure DevOps Server URL (https://do.ideaentity.com/DefaultCollection), I get the error:
"The URL provided has an invalid format."
I have also tried:
but the same error occurs.
Could you please confirm:
1. Does Microsoft Fabric Git Integration support Azure DevOps Server (On-Premises)?
2. If yes, what is the correct Azure DevOps URL format?
3. If not, is Git Integration supported only for Azure DevOps Services (Cloud) and GitHub (Cloud)?
Thank you.
Hello S_Meghana ,
the “invalid format” error is most likely expected because https://do.ideaentity.com/DefaultCollection is an Azure DevOps Server URL, not an Azure DevOps Services/Azure Repos cloud organization. (learn.microsoft.com) - refer this link to understand more.
Thanks
Harish M
If I resolve your issue. Kindly give kudos to this post and accept it as a solution so other can refer this.Hi S_Meghana ,
Short answer to your three questions: no, on-premises Azure DevOps Server isn't supported — Fabric Git integration works only with the cloud services.
1. Supported providers. Fabric Git integration supports Azure DevOps Services (Azure Repos) and GitHub, both cloud only. The documentation is explicit on the GitHub side: only cloud versions of GitHub are supported, and on-premises isn't supported. The same has applied to Azure DevOps since the original limitations list, which stated plainly that Azure DevOps on-prem is not supported.
2. Why you get "invalid format" specifically. The field validates against the Azure DevOps Services URL patterns — https://dev.azure.com/{organization} or https://{organization}.visualstudio.com. Your https://do.ideaentity.com/DefaultCollection fails that format check before Fabric ever attempts to connect, which is why none of the three variations you tried made any difference. Nothing is misconfigured on your side.
3. The reason is architectural. The Fabric service itself has to reach the Git provider from the cloud, so a private endpoint behind your corporate network can't work by design. You can see the same principle applied elsewhere: GitHub Enterprise Server with a custom domain isn't supported even if the instance is publicly accessible, and GitHub Enterprise limitations also rule out IP allowlists and private networking. Public reachability alone isn't enough — it has to be a recognised cloud endpoint.
Options from here
- Migrate to Azure DevOps Services. Microsoft's Data Migration Tool handles ADO Server → Services and preserves history. Cleanest path if there's no hard requirement to stay on-prem.
- Use a cloud repo just for Fabric. Keep your Server as the corporate source of truth and add a small Azure Repos project used only for Fabric item definitions, mirrored one-way. Less tidy, but it unblocks you without a full migration.
- Skip Git integration and use the APIs instead. This is the realistic answer for on-prem-only environments: pull item definitions via the Fabric Item Definition APIs (getDefinition / updateDefinition) from a self-hosted agent inside your network, and commit them to your Azure DevOps Server repo yourself. The fabric-cicd Python library does most of the work. You get genuine source control and CI/CD — you just don't get the Git panel inside the portal.
- Deployment pipelines for dev → test → prod promotion. They work independently of Git and may cover part of what you need.
Two more things worth knowing while you plan: sovereign clouds aren't supported either, and only workspace admins can manage the Git connection.
If on-prem support matters to your organisation, raise it on the Fabric Ideas forum. GitHub support was added that way after enough votes, so it's worth doing rather than assuming it'll never change.
3 Replies
- ibarrau
Super User
Hi. I'm sorry but that's not possible. Onpremise is not compatible. I can't find a doc showing exactly that it's not possible but i'm pretty sure it only works with azure devops cloud and github (those two are the only configurations available at documentation)
You can read more here: https://learn.microsoft.com/en-us/fabric/cicd/git-integration/git-get-started?tabs=azure-devops%2CAzure%2Ccommit-to-git
I hope that helps,
- HarishKM
Hello S_Meghana ,
the “invalid format” error is most likely expected because https://do.ideaentity.com/DefaultCollection is an Azure DevOps Server URL, not an Azure DevOps Services/Azure Repos cloud organization. (learn.microsoft.com) - refer this link to understand more.
Thanks
Harish M
If I resolve your issue. Kindly give kudos to this post and accept it as a solution so other can refer this. Hi S_Meghana ,
Short answer to your three questions: no, on-premises Azure DevOps Server isn't supported — Fabric Git integration works only with the cloud services.
1. Supported providers. Fabric Git integration supports Azure DevOps Services (Azure Repos) and GitHub, both cloud only. The documentation is explicit on the GitHub side: only cloud versions of GitHub are supported, and on-premises isn't supported. The same has applied to Azure DevOps since the original limitations list, which stated plainly that Azure DevOps on-prem is not supported.
2. Why you get "invalid format" specifically. The field validates against the Azure DevOps Services URL patterns — https://dev.azure.com/{organization} or https://{organization}.visualstudio.com. Your https://do.ideaentity.com/DefaultCollection fails that format check before Fabric ever attempts to connect, which is why none of the three variations you tried made any difference. Nothing is misconfigured on your side.
3. The reason is architectural. The Fabric service itself has to reach the Git provider from the cloud, so a private endpoint behind your corporate network can't work by design. You can see the same principle applied elsewhere: GitHub Enterprise Server with a custom domain isn't supported even if the instance is publicly accessible, and GitHub Enterprise limitations also rule out IP allowlists and private networking. Public reachability alone isn't enough — it has to be a recognised cloud endpoint.
Options from here
- Migrate to Azure DevOps Services. Microsoft's Data Migration Tool handles ADO Server → Services and preserves history. Cleanest path if there's no hard requirement to stay on-prem.
- Use a cloud repo just for Fabric. Keep your Server as the corporate source of truth and add a small Azure Repos project used only for Fabric item definitions, mirrored one-way. Less tidy, but it unblocks you without a full migration.
- Skip Git integration and use the APIs instead. This is the realistic answer for on-prem-only environments: pull item definitions via the Fabric Item Definition APIs (getDefinition / updateDefinition) from a self-hosted agent inside your network, and commit them to your Azure DevOps Server repo yourself. The fabric-cicd Python library does most of the work. You get genuine source control and CI/CD — you just don't get the Git panel inside the portal.
- Deployment pipelines for dev → test → prod promotion. They work independently of Git and may cover part of what you need.
Two more things worth knowing while you plan: sovereign clouds aren't supported either, and only workspace admins can manage the Git connection.
If on-prem support matters to your organisation, raise it on the Fabric Ideas forum. GitHub support was added that way after enough votes, so it's worth doing rather than assuming it'll never change.
