Be careful setting up GitHub Enterprise for use with AL-Go

by Steve Endow

[This blog post was 100% human written. None of this post was drafted or written by an AI.]

A quick note for any Dynamics 365 Business Central developers looking to use AL-Go for GitHub.

Be very careful if you choose to upgrade to GitHub Enterprise.  There is a big catch.  (as of June 2026)

If you are an ISV or partner, or an organization that has multiple developers and multiple projects, you will likely want to use AL-Go, and also several features of GitHub to make your devops processes more efficient.  You will likely want to use templates and actions to streamline your project setup process and pipelines to streamline your builds.

We went down this rabbit hole and quickly found that in order to get the most out of GitHub, we would need to graduate from an Organization account to an Enterprise account.  The features we needed were not clearly listed on the GitHub subscription feature list, but when we dug into the settings in a repo, we found out that the features we wanted require the Enterprise subscription.  And we estimated that we would likely exceed the 3,000 CI/CD minutes per month under the Team subscription.

It was not obvious that we needed Enterprise 

Once you bump into feature limitations and decide to try the Enterprise subscription, be very careful at this first step in the sign up process.

As of June 2026, I was asked to choose an "enterprise type".  This dialog does not explain the significant implications of your choice. 

You might think that the "managed users" option sounds appealing.  Why wouldn't I want to manage my GitHub users through Entra and have Single Sign On?

In our case, this GitHub account would be used for customer PTEs and Business Central Marketplace apps only, so we will not have public repositories.  

So I chose "Enterprise with managed users".  This kicked off a strange process that I did not understand.

As of June 2026, if you choose the managed users option, a separate GitHub "tenant" is created.  And that tenant will have a ghe[.]com domain in the URL.

Not github[.]com.  This may not have always been the case--I'm told that some people do have a GitHub Enterprise subscription, with managed users, and have a github[.]com URL.  That appears to have changed.

This is significant.  

We learned that AL-Go for GitHub effectively won't work for an account hosted under ghe[.]com.  There are apparently hard coded references to github[.]com that prevent us from utilizing the AL-Go features that we need.

Someone shared this link that discusses the issue:

    Support for GitHub Enterprise with EU Data Residency (*.ghe.com)

    https://github.com/microsoft/AL-Go/discussions/1999

I spent hours of getting the GitHub Enterprise account setup with "managed users", connecting it to our Entra tenant, and then provisioning users.  Then my developer spent a day of figuring out that AL-Go for GitHub won't work with the ghe[.]com URL that we received for our Enterprise tenant, 

[Maybe you could create some elaborate custom solution to get AL-Go to work with a ghe[.]com URL, but that kinda defeats the purpose of AL-Go in my opinion]

So the lesson is that if you sign up for a new GitHub Enterprise subscription, and you also want to use AL-Go, you must choose "Enterprise with personal accounts".

If for some reason your organization has to use the ghe[.]com option due to Data Residency requirements, then expect to fight with AL-Go for GitHub.

Steve Endow is a Microsoft MVP in Los Angeles.  He works with Dynamics 365 Business Central and related technologies.

You can also find him on X and YouTube, or through these links:  links.steveendow.com 

You can send him a message from the Blue Dragonfly web site:  bluedragonflyllc.com/contact