The GitHub for Microsoft Teams integration comes in two flavours, and only one of them is self-hosted

Two integrations, one of which needs thirteen setup steps

The repository's own title is GitHub + Microsoft Teams Integration, and the description says it brings your code and work to the conversations you care about.

The README splits the subject into two, using collapsible sections. The first is GHEC, the hosted GitHub Enterprise Cloud. The second is GHES, GitHub Enterprise Server. The split is not cosmetic, because the two have completely different setup paths.

For GHEC there is essentially nothing to do. The data residency version of the Microsoft Teams app can be installed from AppSource, and the README links that listing. The hosted path is an app you install, and the README says to refer to the GitHub docs for how to install and use it.

For GHES the README announces general availability for the integration with GHES 3.8, and then spends the bulk of the document on configuration.

So the real content of this repository is a single long numbered procedure for a GitHub Enterprise Server administrator, and the interesting engineering in it is not code but topology: where the ChatOps service runs, where the Azure Bot runs, and what has to be reachable from what.

The primary language is not recorded and the licence is not stated in the repository metadata. The default branch is master, the repository is not archived, and the last push was on 2026-04-13. There are no GitHub releases. The top-level entries are .github/, Readme.md, docs/, ghes/ and images/, which is the shape of a documentation repository rather than a code one.

What the integration gives you inside a Teams channel

The README describes the capability set in one paragraph, and it is worth separating what it says from what it implies.

With this integration, you can subscribe to your repositories in your GHES instance and get live updates about your Issues, PRs, Commits and Deployments in your MS teams channels and personal app. And you can also take actions like commenting, open or close issues and approve your deployments directly from chat.

The four event types cover the whole software delivery loop: an issue is opened, a pull request moves, a commit lands, a deployment happens. The action verbs matter as much as the notifications, because they turn the channel from a read-only feed into a place where you can respond. Commenting on a pull request from the same message that announced it is the thing that removes a round trip to the browser.

Approving deployments from chat is the one that changes a risk profile, and it is worth being explicit about that. A deployment approval is a privileged action, and putting it in a chat client means it happens in a surface where there is no diff to look at and no second confirmation dialog. Whether that is a good idea depends on your deployment pipeline, not on the integration.

The README closes the GHES section by saying that all the features available in the hosted GitHub integration for GHEC will be available in the GHES integration. So the GHES path is not a reduced version. It is the same feature set with a different plumbing, and that is the entire point of the exercise, because the plumbing is what an enterprise cannot borrow.

The personal app, mentioned alongside the channels, is the same integration delivered as a one-to-one app rather than a channel subscription, which is how you would follow a single repository without adding a bot to a busy team channel.

The data residency argument, and where the ChatOps service actually runs

The architecture section is where the reason for the GHES variant becomes clear.

Starting with GHES 3.8, a dedicated ChatOps service is shipped alongside the GHES server, and you can choose to integrate with Microsoft Teams. The README then gives two properties.

The first is that all your subscriptions information and any other metadata stays within your GHES setup, so you do not have to worry about data flowing to any external service. That is the headline benefit, and it is a real one for an organisation whose repository metadata, issue content or commit messages are not meant to leave the network.

The second property qualifies the first in an important way. Connectivity between GHES and the Azure Bot: the integration is not just a notification service, and it also enables you to perform actions directly from chat, so the only prerequisite you need is to ensure your GHES instance is accessible from the Azure Bot that is deployed when the Microsoft Teams integration is set up on GHES.

So the ChatOps service is inside your network, and the Azure Bot is not. The bot is the component that has to reach the GitHub instance, because it is the bot that receives the command from the chat message, forwards it to the ChatOps service on the GHES side, and relays the answer back.

That topology explains the entire configuration procedure, including the two contradictory-looking settings later in the README. If your GHES instance is on the public internet, the bot connects directly and you leave the path suffix option checked. If it is not, something has to forward the traffic, and the GHES instance has to be told the public address that leads back to it.

The README also says the existing GitHub app you see in the app store can only be used for the hosted GitHub integration. To integrate a GHES instance you need to configure a private GHES app. That is the first real difference in the procedure, and it is why the steps start inside your own instance rather than in an app marketplace.

The configuration procedure, from the GHES settings page to the Teams upload

The procedure is long, which is itself information: it crosses two admin surfaces, Azure and GitHub Enterprise Server, and then a third, the Teams app manifest.

The first steps happen inside GHES. Navigate to your-ghes-url:8443 and go to the section called Chat Integrations, then select the checkbox Enable GitHub Chat Integration, then select the MS teams tab. Then the work moves to Azure: register an application on the Azure portal by going to the link mentioned, enter your application registration name, and for account type select Multi-tenant before clicking Register. Take note of the application ID and the tenant ID, then click on Certificates & secret and generate a new client secret, and take note of the client secret too.

Then back on the GHES instance, the Deploy to Azure button is where the bot gets created. You select the subscription and resource group for the Azure bot, enter the GHES hostname along with the app ID and tenant ID you generated, and click Review + create.

The public internet question is decided at this step, and the README gives both branches explicitly. If your GitHub Enterprise instance is reachable on the public internet, make sure the Append '_msteams' to path option is checked. If it is not reachable and requires a proxy, make sure that option is unchecked, and also enter the URL that will forward the traffic to the instance in GHES Instance Host Name.

After the bot is provisioned, you return to the settings page and enter the app ID, tenant ID and client secret. If the GHES endpoint is not reachable on the public internet and the traffic is going to be forwarded, you enter that URL in Public Endpoint URL, then click Save client settings.

Then you download the manifest from the generate manifest button and click the green Save settings to persist the settings on the instance, and the README warns that once settings are applied this could take 5 to 15 minutes depending on the configuration. The final step is uploading the manifest to the Microsoft Teams app, with a link to the Teams documentation for the upload procedure.

Two operational notes fall out of this. The client secret is generated in Azure and pasted into your GHES instance, so it exists in two places and in whatever ticket or chat you used to move it. And the 5 to 15 minute apply window means an impatient administrator will click Save more than once.

Where this integration is the wrong tool

Three limits, and the first is about who can use it at all.

The first is that the GHES path requires GHES 3.8 or newer, and the README announces general availability specifically for that version. The ChatOps service that makes the whole thing work ships with the server from that release, so there is no backport to an older instance. A large organisation running an older GHES has three options and none of them are pleasant: upgrade the server, keep using the hosted integration and accept that repository metadata leaves the network, or build something themselves. The README does not mention any of those, so the practical reading is that the version requirement is a hard floor.

The second is that there is no configuration without an Azure subscription. Every step from the app registration onwards happens in an Azure portal, in a subscription and resource group you select, and it deploys an Azure Bot. For an organisation whose constraint is that nothing leaves the network, deploying a bot into a public cloud is a contradiction, and the README's answer is that the metadata stays inside GHES while the bot does not. Whether that satisfies a data residency review is an organisational question the documentation does not address, and the README does not describe what data crosses that boundary in either direction beyond the subscription information and metadata staying put.

The third is the age of the instructions. The screenshots are hosted externally, the GHES instance URL is described as your-ghes-url:8443, and the flow walks through an Azure portal that changes its navigation regularly. The steps are described in terms of labels rather than stable identifiers, so a renamed menu item breaks the procedure. The README also points general questions at a GitHub support form rather than at a maintained troubleshooting document.

The alternative approach for a team that wants GitHub activity in a chat tool without an Azure dependency is to build a small service of their own: subscribe to the GHES webhooks, post into the channel with a bot token, and accept that the actions from chat, commenting and approving deployments, are the part you would have to write yourself. The difference in approach is that the official integration gives you the full action set and the metadata boundary, at the cost of an Azure deployment and a version floor, while a webhook bot gives you notifications only, costs one small service, and lets you decide exactly what leaves the network.

And for many teams the honest answer is to do neither, because the primary language is not even recorded in the repository metadata and the licence is not stated. This is documentation for a service that other organisations run, not a project you would vendor.

Editorial conclusion

Adopt the GHES path if you run GitHub Enterprise Server 3.8 or newer and need Issues, pull requests, commits and deployment notifications in Teams without sending repository metadata to an external service. Do not adopt it if you are on hosted GitHub Enterprise Cloud, because the README is explicit that the existing GitHub app from the app store can only be used for the GHEC integration, and the repository is not the place to configure it. Verify first that your GHES instance is on 3.8 or later, since that is the version where the bundled ChatOps service starts, that the instance is reachable from the Azure Bot or that you have a proxy URL and the right Append '_msteams' to path setting, and that your Azure application registration is multi-tenant, as the README instructs.

Frequently asked questions

Official sources

1. integrations/microsoft-teams on GitHub
2. Issues
3. README