Manage your billing, licensing, and consumption-based services
The enterprise account is the central point for managing all billing and licensing within GitHub Enterprise Cloud (GHEC), including all organizations that are part of your enterprise. It is important to review your billing configuration as one of the first steps when setting up your enterprise account. Setting up a payment method and confirming your spending limit ensures that you are ready to begin using consumption-based services like GitHub Actions, Packages, and Codespaces immediately, in line with your budgets and policies. You’ll also want to familiarize yourself with the way that your enterprise account’s reporting on licensing consumption works so that you can understand how licenses for GitHub Enterprise and other separately-licensed services are used and presented to you.
In this guide, you will learn:
How GHEC determines user licensing for billing purposes
How to configure access and spending limits for consumption-based services like GitHub Actions, Packages, and Codespaces
How to manage policies and licensing for separately licensed services, such as GitHub Copilot and GitHub Advanced Security
User licenses
GHEC uses a unique-user licensing model, which means that GitHub counts each member or outside collaborator once for billing purposes, even if the user account has membership in multiple organizations in an enterprise or access to multiple repositories owned by your organization. GHEC user licenses are added to your enterprise upon purchase. You must have enough user licenses in your enterprise to continue inviting or provisioning additional users.
To be more specific, an account in each of the following scenarios counts as a billable unique user:
Enterprise owner who is a member or owner of at least one organization in the enterprise
Organization member, including owners
Outside collaborator on private or internal repositories owned by your organization, excluding forks (collaborators with access to only public repos do not consume licenses)
Anyone with a pending invitation to become an organization owner or member (only in enterprises not using Enterprise Managed Users (EMUs))
Anyone with a pending invitation to become an outside collaborator on private or internal repositories owned by your organization, excluding forks (only in enterprises not using EMUs)
Conversely, an account in each of the following types of usage does not count as a billable unique user:
Enterprise owner or billing manager who is not a member or owner of at least one organization in the enterprise
Billing manager for individual organizations who does not have any other usage
Anyone with a pending invitation to become a billing manager (only in enterprises not using EMUs)
Anyone with a pending invitation to become an outside collaborator on a public repository owned by your organization (only in enterprises not using EMUs)
Managed user account that is suspended (only in enterprises using EMUs)
Consumption-based services
Use of consumption-based services, such as GitHub-hosted Actions runners, shared storage for GitHub Actions and Packages, and Codespaces, are billed per unit consumed. Consumption across all of your enterprise’s organizations will be aggregated to a single invoice at the enterprise level.
For GitHub-hosted Actions runner minutes usage and shared storage for Actions and Packages, your GHEC plan includes a flat amount of storage and usage (entitlements) per month. For usage beyond included entitlements or for services that don’t include entitlements, you will need to set up a payment method for billing. You may also set up spending limits for each feature to control spending, or set unlimited spending limits to ensure service continuity.
Though organization charges are aggregated into a single enterprise invoice, a detailed report of all consumption services is available.
Included entitlements for consumption-based services
Entitlements are included for GitHub-hosted Actions runner minutes and shared Actions and Packages storage as part of GHEC plans. All GHEC enterprise accounts are given a default number of entitlements to be shared, regardless of company size or number of organizations or users. These included services are intended to help your company get started using GitHub Actions and Packages, such as by enabling simple workflow automations, supporting pilot activities, running tests of security scans, and other non-business-critical usage. If you intend to use GitHub Actions and/or Packages as part of your production DevSecOps pipelines, you should plan to set up payment and spending limits to ensure you can continue to use these services beyond the included entitlements each month.
Setting up payment for consumption-based services
You can connect an Azure Subscription ID to your enterprise account to pay for any GitHub consumption-based services overages beyond your enterprise’s entitlements. This option is now available to anyone who has an Azure subscription and is the preferred billing method over monthly invoices.
Any customer with an Azure subscription can connect an Azure Subscription ID to your enterprise account and have all charges managed via Azure invoicing. The Azure subscription will be used only for billing purposes. No resources will be created or used in your Azure subscription itself.
To connect your Azure subscription, you must have owner permissions to the Azure subscription and be an enterprise owner on GitHub.
Setting up spending limits for consumption-based services
Once you’ve set up payment for consumption-based services, you’ll also want to consider configuring spending limits for each service. Spending limits allow you to control costs for usage. A $0 spending limit prevents any additional charges for that service, but still allows use of that service until the included entitlements are used up. You can also set your spending limit to unlimited, which will keep a service running regardless of how much is spent. The default spending limit for invoiced customers is set to unlimited, so if you would prefer to set a specific spending limit, be sure to update it.
You can set up separate spending limits per service for Actions, Packages, and Codespaces.
Reporting on consumption-based services billing/usage
Insight into consumption services billing is provided at both the per-organization and aggregate enterprise levels. You can view monthly consumption in the user interface, or you can download granular usage reports in a CSV format. These reports are intended to be a starting point for your further analysis, chargebacks, or other more in-depth reporting and analysis.
Similar to spending limits, you can view independent usage details for Actions, Packages, and Codespaces.
GitHub Actions policies
You can enable or disable Actions by policy on all, some, or none of the organizations within the enterprise. If Actions are enabled, administrators can define which specific actions are available to their workflows. Three options are available:
Allow all actions and reusable workflows: This lets users run workflows containing any action from GitHub Marketplace or defined in any public repository. This is not appropriate for most companies, since it is very permissive. No review or approval is required to make use of any public action.
Allow enterprise actions and reusable workflows: This setting is highly restrictive compared to the above setting, but it is still not appropriate for most companies because it requires all actions that will be used to exist within your enterprise. That means developers won’t be able to use actions directly from GitHub Marketplace at all. You’ll also need to define a process to clone all desired actions into your enterprise, train your teams to reference those internal actions, and regularly check for and incorporate updates.
Allow enterprise actions, select non-enterprise actions, and reusable workflows: This is the sensible, manageable choice for most enterprises. This option presents an “allow” list that administrators can use to individually authorize GitHub-created actions, actions created by GitHub-verified creators, and specific third-party actions and reusable workflows.
Enterprises choosing the third option will need to create and maintain their own process for requesting access to Actions, and administrators will have the option to reference approved actions in four ways:
The simple owner/repo path to the action’s source code
A specific branch of the action, referenced as
owner/repo@branchA specific tag/release of the action, referenced as
owner/repo@tagA specific commit SHA of the action, referenced as
owner/repo@SHA
Companies performing their own security reviews of third-party actions should use the owner/repo@SHA syntax specific to the version of the action approved, as commit SHAs are immutable, while code referenced by branch names and tags can change.
You can also run actions on self-hosted runners instead of GitHub-hosted runners. Some customers would like to prevent the use of self-hosted runners at the repository level for security reasons, because unlike GitHub-hosted runners, there is no guarantee that self-hosted runners for GHEC will be hosted on ephemeral, clean virtual machines. As a result, they may be compromised by untrusted code in a workflow. Because of this possible security concern, you can set a policy to prevent the use of repository-level self-hosted runners. In an enterprise using the Enterprise Managed Users (EMU) model, you can also set a policy to restrict runner creation for repositories that are owned by EMU accounts, not organizations.
Codespaces policies
GitHub Codespaces is an instant, cloud-based development environment that provides developers with common languages, tools, and utilities for development, allowing them to get started with projects quickly, without needing to install lots of tools and dependencies locally to start contributing. You might want to roll out Codespaces gradually across your organizations, and GHEC gives you the controls to do this. You can enable Codespaces for all organizations, enable for specific organizations, or disable for all organizations.
Alternatively, if you need to comply with security regulations that require increased control over the private code in your enterprise, you might want to disable Codespaces for all organizations in your enterprise. You can set an enterprise policy to enable or disable Codespaces across organizations in your enterprise.
Separately licensed services
GitHub Copilot
Policies in this section govern the use of GitHub Copilot, GitHub’s AI pair programmer. GitHub Copilot is licensed separately from GHEC. If your enterprise is using this tool, you can use the settings here to manage which organizations’ users have access to use GitHub Copilot, and allow or prevent suggestions from GitHub Copilot that match public code.
Code security and analysis (GitHub Advanced Security)
GitHub Advanced Security provides additional application security features such as secret and code scanning for private repositories. It is licensed per active committer to repositories using the features. A committer is considered active if one of their commits has been pushed to the repository within the last 90 days, regardless of when it was originally authored.
The code security and analysis section of the enterprise policies tab also contains controls for Dependabot, which is an included feature of GHEC that helps you use open source dependencies in your code securely. Dependabot notifies you of vulnerabilities in dependencies you use, opens pull requests for security fixes as they become available, and even automatically reminds you to update your dependencies when new versions ship to stay ahead of any issues.
More information about licensing, enabling, and setting policies for security features and GitHub Advanced Security can be found in the Security learning pathway.
Up next: Manage your repository visibility, rules, and settings
Now that we’ve run through some core configuration concerns and set up some guardrails around our billing, we’ll examine how to configure repositories—the structural component below organizations—to provide more fine-grained controls around visibility and the ability to merge pull requests.