You can configure larger runners for your organization or enterprise.
Adding a larger runner to an organization
Organization owners can add a larger runner to an organization and control which repositories can use it. When you create a new runner for an organization, by default, all repositories in the organization have access to the runner. To limit which repositories can use the runner, assign it to a runner group with access to specific repositories. For more information, see Allowing repositories to access larger runners.
You can choose an operating system and a hardware configuration from the list of available options. When new instances of this runner are deployed through autoscaling, they'll use the same operating system and hardware configuration you've defined here.
New runners are automatically assigned to the default group, or you can choose which group the runners must join during the runner creation process. In addition, you can modify the runner's group membership after you've registered the runner. For more information, see Controlling access to larger runners.
On GitHub, navigate to the main page of the organization.
Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
In the left sidebar, click Actions, then click Runners.
Click New runner, then click New GitHub-hosted runner.
Complete the required details to configure your new runner:
Name: Enter a name for your new runner. For easier identification, this should indicate its hardware and operating configuration, such as ubuntu-24.04-16core.
Platform: Choose a platform from the available options. Once you've selected a platform, you will be able to choose a specific image.
If you are building a custom image, the platform that you select for your runner must match the platform of the image you want to build. The platform of the runner can be one of the following:
Linux x64
Linux ARM64
Windows x64
Image: Choose an image from the available options. Once you've selected an image, you will be able to choose a specific size.
GitHub-owned: For images managed by GitHub, select an image under this tab.
Partner: For images managed by a partner, select an image under this tab. ex: Base Windows 11 desktop, GPU-optimized, and arm64 images are located under this tab.
Custom: For images that are created by your organization or enterprise, select an image under this tab. Custom images are created by running a workflow on an image-building runner that you, your organization, or your enterprise have set up. For more information, see Installing custom images.
Size: Choose a hardware configuration from the list of available options. The available sizes depend on the image that you selected in a previous step. For GPU runners, select a size under the GPU-powered tab.
Maximum concurrency: Choose the maximum number of jobs that can be active at any time.
Runner group: Choose the group that your runner will be a member of. This group will host multiple instances of your runner, as they scale up and down to suit demand.
Note
The names of larger runners can dictate their functionality. For example, to use a larger runner for code scanning default setup, the runner must be named code-scanning. For more information on code scanning with larger runners, see Configuring larger runners for default setup.
Repositories are granted access to larger runners through runner groups. Enterprise administrators can choose which organizations are granted access to enterprise-level runner groups, and organization owners control repository-level access to all larger runners.
Organization owners can use and configure enterprise-level runner groups for the repositories in their organization, or they can create organization-level runner groups to control access.
For enterprise-level runner groups: By default, repositories in an organization do not have access to enterprise-level runner groups. To give repositories access to enterprise runner groups, organization owners must configure each enterprise runner group and choose which repositories have access.
For organization-level runner groups: By default, all repositories in an organization are granted access to organization-level runner groups. To restrict which repositories have access, organization owners must configure organization runner groups and choose which repositories have access.
Once a repository has access to larger runners, the larger runners can be added to workflow files. For more information, see Running jobs on larger runners.
Navigate to the main page of the organization where your runner groups are located.
Click Settings.
In the left sidebar, click Actions, then click Runner groups.
Select a runner group from either list on the page. Organization-level runner groups are listed at the top of the page, and enterprise-level runner groups are listed under "Shared by the Enterprise."
On the runner group page, under "Repository access," select All repositories or Selected repositories. If you choose to grant access to specific repositories, click , then select the repositories you would like to grant access to from the list.
Warning
If you are using a Fixed IP range, we recommend that you only use larger runners with private repositories. Forks of your repository can potentially run dangerous code on your larger runner by creating a pull request that executes the code in a workflow.
For more information, see Controlling access to larger runners.
The names of larger runners can dictate their functionality. For example, to use a larger runner for code scanning default setup, the runner must be named code-scanning. For more information on code scanning with larger runners, see Configuring larger runners for default setup.
On GitHub, navigate to the main page of the organization.
Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
In the left sidebar, click Actions, then click Runners.
In the list of runners, select the runner you would like to edit.
Enter a new name for the runner in the text field under "Name."
Click Save.
Changing the size of a larger runner
On GitHub, navigate to the main page of the organization.
Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
In the left sidebar, click Actions, then click Runners.
In the list of runners, select the runner you would like to edit.
Select a new size for the runner from the list of available options under "Size." The available sizes depend on the image that is installed on the runner.
Click Save.
Changing the image of a larger runner
On GitHub, navigate to the main page of the organization.
Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
In the left sidebar, click Actions, then click Runners.
In the list of runners, select the runner you would like to edit.
Select a new image for the runner from the list of available options under "Image." The available images are limited to GitHub-owned images.
Click Save.
Configuring autoscaling for larger runners
You can control the maximum number of jobs allowed to run concurrently for specific runner sets. Setting this field to a higher value can help prevent workflows being blocked due to parallelism.
On GitHub, navigate to the main page of the organization.
Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
In the left sidebar, click Actions, then click Runners.
In the list of runners, select the runner you would like to edit.
In the "Capacity" section, under "Maximum concurrency", enter the maximum number of jobs you would like to allow to run at the same time.
Click Save.
Creating static IP addresses for larger runners
Note
To use static IP addresses, your organization must use GitHub Enterprise Cloud. For more information about how you can try GitHub Enterprise Cloud for free, see Setting up a trial of GitHub Enterprise Cloud.
macOS larger runners do not support static IP addresses.
You can enable static IP addresses for larger runners. When you do this, the larger runners are assigned static IP address ranges. All IP addresses in the range assigned are usable. By default, you can configure up to 10 larger runner pools with static IP address ranges for your account. If you would like to use more than 10 larger runner pools with static IP address ranges, please contact us through the GitHub Support portal.
Each larger runner you create is not a single machine. It is a pool of runners that automatically scales out to handle concurrent jobs, up to the maximum concurrency you set when creating the runner. All jobs in the pool share the same static IP address range. This means a single larger runner with one static IP range can handle many jobs running at the same time without requiring additional runners.
The number of available IP addresses in the assigned ranges does not restrict the number of concurrent jobs. Within a runner pool, there is a load balancer which allows for high reuse of the IP addresses in the assigned ranges. This ensures your workflows can run concurrently at scale while each machine is assigned a static IP address.
On GitHub, navigate to the main page of the organization.
Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
In the left sidebar, click Actions, then click Runners.
In the list of runners, select the runner you would like to edit.
To assign static IP addresses to the runner, under "Networking," check Assign unique & static public IP address ranges for this runner.
Click Save.
Azure Storage firewall considerations
Virtual machines and storage accounts in the same region
If you use Azure Storage accounts protected by network rules, be aware that traffic from larger runners' VMs to storage accounts in the same Azure region uses private Azure IP addresses rather than the larger runners' public IP range.
As a result, Azure Storage firewall rules that rely only on runner public IP allowlists might not work as expected. This can cause connectivity failures that appear as 403 (AuthorizationFailure) responses, with an error message similar to:
The request may be blocked by network rules of storage account. Please check network rule set using 'az storage account show -n accountname --query networkRuleSet'.
If you want to change the default action to apply when no rule matches, please use 'az storage account update'.
We don't recommend configuring Azure Storage firewall network rules for larger runners unless you use either static public IP ranges or an Azure VNet.
Public IP ranges can be dynamic, so allowlist-based rules may break and cause intermittent connectivity failures.
See Larger runners reference
Use Static IP Ranges and Service Endpoints
One option for safely enabling Storage Account network rules is to use runners with static IPs and request support for configuring Azure Storage service endpoints for the virtual network hosting those static IPs. See Azure virtual network service endpoints for more information.
Contact GitHub Support to set up this configuration through the GitHub Support portal.
Configure Azure VNET
Another option to safely connect to Azure Storage accounts is to enable Azure VNET with GitHub-hosted runners.
