GitHub Copilot user management and provisioning

Whether you’re launching a proof-of-concept or rolling out an enterprise-wide deployment of GitHub Copilot, you’ll need a strategy for managing who gets access, to ensure the right users are able to benefit.

GitHub Copilot access is seat based. Each user you grant access to adds another seat to your subscription. Each month, you’re charged for the number of seats you’re using. You can add or remove seats at any time, and don’t need to buy a set number upfront.

In this guide, you will learn:

• The different ways you can manage GitHub Copilot seats

• Automation strategies that can be used for efficient seat allocation

We’ll also hear from ASOS Lead Principal Engineer Dylan Morley about the custom seat provisioning system they’ve built.

Provisioning and revoking GitHub Copilot seats

There are several approaches to provisioning and revoking GitHub Copilot seats, and deciding between them is largely a matter of weighing your priorities. 

Do you want to reduce friction and enable as many developers as possible to use GitHub Copilot? Or would you rather control costs and ensure efficient seat allocation? 

If you want to reduce friction, assigning seats to an entire organization or identity provider (IdP) group might be best. But if you’re looking to prioritize efficiency, a more granular approach may be necessary. Copilot seats can be assigned through organization settings. Additionally, the GitHub Copilot Business API allows for creating custom solutions with just the right balance of your organization’s priorities.

Common methods for managing GitHub Copilot seats

Manually: Assign a GitHub Copilot seat to individual developers one-by-one in your GitHub organization’s settings. This is one of the more basic approaches, and it might work well if you're running a small proof-of-concept with only a few developers.

Organization-based: Grant access to members of entire GitHub organizations. This is another simple approach, but it might not be efficient if the organizations have many members who won't be using GitHub Copilot.

Identity Provider Provisioning: If your organization is linked with an IdP for single sign-on, such as Microsoft Entra ID (formerly Azure Active Directory) or Okta, you can manage access to GitHub Copilot at the team level with team synchronization or System for Cross-domain Identity Management (SCIM). With this approach, Copilot seats can be assigned to dedicated teams within an organization, or to an organization which has Copilot seats fully assigned to all members, and then membership to these teams or organizations can be provisioned from an external IdP. 

API Automation: Using the GitHub Copilot Business API, you have the ability to add and remove seats via custom GitHub Actions workflows or automation scripts. For example, you could use GitHub Actions to kick off a workflow when a developer opens an issue in a particular repository to request access. This is a good way to create a highly customized management system, as ASOS has done.

Automation with the GitHub Copilot Business API

In addition to provisioning or revoking accounts, the GitHub Copilot Business API provides access to other information, such as seat allocation details for users in an organization This includes activity details for seat assignees, including the date of assignment, the last date of access, and the last code editor used. For example, you can use usage data to check the last activity date of all your seats, with individual seat assignment details, to discover potentially unused seats.

Let’s hear from Dylan on how ASOS uses the GitHub Copilot Business API to manage seats.

We built an automated seat provisioning and management system to meet our specific needs. We wanted any developer at ASOS who wants to use GitHub Copilot to be able to with as little friction as possible. But we didn't want to turn it on for everyone at the organization level as that would be a pretty inefficient use of resources. So we built our own self-service system.

We have an internal website where every employee has a profile. To receive a GitHub Copilot seat, all they have to do is click a single button on their profile. Behind the scenes, that kicks off a Microsoft Azure Functions process that validates the developer's Azure token and calls the GitHub Copilot Business API to provision a seat. Developers can even do this from the command line, if they prefer.

At the same time, we have an Azure function that checks for inactive accounts nightly by pulling the seat usage data. If a seat hasn't been used for 30 days, we mark it for deletion before the next billing period begins. We check one last time for activity before deletion and then send an email to all developers whose seats are revoked. If they want a seat again, they can just click that button and start the process over again.

Dylan Morley // Lead Principal Engineer // ASOS

As you can see, there’s no one-size-fits-all approach to user seat management for GitHub Copilot. You’ll need to weigh your organization’s priorities and make your own plan. To start, you might want to opt for a simple approach and then move towards a more custom solution as you gather adoption data. Then, as your use cases grow more complex, use the GitHub Copilot Business API and IdP integrations to build customized solutions to meet your needs.

You should now have a good idea of how you might provision GitHub Copilot seats in your organization. Now let’s take a look at how billing works.