About larger runners

Overview of より大きなランナーs

標準の GitHub ホステッド ランナーに加えて、GitHub では、GitHub Team と GitHub Enterprise Cloud プランのお客様には、より多くの RAM、CPU、ディスク領域を備えたさまざまなマネージド仮想マシンが用意されています。 これらのランナーは、GitHub によってホストされ、ランナー アプリケーションとその他のツールをプレインストールしています。

When you add a より大きなランナー to an organization, you are defining a type of machine from a selection of available hardware specifications and operating system images. GitHub will then create multiple instances of this runner that scale up and down to match the job demands of your organization, based on the autoscaling limits you define.

Understanding billing

Compared to standard GitHub-hosted runners, より大きなランナーs are billed differently. より大きなランナーには、ワークフローが実行された時間に対してのみ、分単位で課金されます。 ワークフローで使われていないより大きなランナーの作成に関連付けられたコストはありません。 For more information, see "GitHub Actions の課金について."

Machine sizes for より大きなランナーs

Processor (CPU)	Memory (RAM)	Storage (SSD)	Operating system (OS)
4	16 GB	150 GB	Ubuntu
8	32 GB	300 GB	Ubuntu, Windows
16	64 GB	600 GB	Ubuntu, Windows
32	128 GB	1200 GB	Ubuntu, Windows
64	256 GB	2040 GB	Ubuntu, Windows

Additional features for より大きなランナーs

Compared to standard GitHub-hosted runners, より大きなランナーs have the following additional features:

• For Ubuntu runners, hardware acceleration for the Android SDK tools is enabled. This makes running Android tests much faster and consumes fewer minutes. For more information on Android hardware acceleration, see Configure hardware acceleration for the Android Emulator in the Android Developers documentation.
• より大きなランナーs can be assigned static IP addresses from specific ranges, which enables you to use the ranges to configure a firewall allowlist. For more information, see "Networking for より大きなランナーs."
• より大きなランナーs can automatically scale up to a maximum limit set by you, so your workflows can run concurrently. For more information, see "Autoscaling より大きなランナーs."
• Runner groups allow you to control access to より大きなランナーs for your organizations, repositories, and workflows. For more information, see "Controlling access to larger runners."

For a full list of included tools for each runner operating system, see the GitHub Actions Runner Images repository.

About runner groups

Runner groups enable administrators to control access to runners at the organization and enterprise levels. With runner groups, you can collect sets of runners and create a security boundary around them. You can then decide which organizations or repositories are permitted to run jobs on those sets of machines. During the より大きなランナー deployment process, the runner can be added to an existing group, otherwise it will join a default group. You can create a group by following the steps in "Controlling access to larger runners."

Architectural overview of より大きなランナーs

より大きなランナーs are managed at the organization level, where they are arranged into groups that can contain multiple instances of the runner. They can also be created at the enterprise level and shared with organizations in the hierarchy. Once you've created a group, you can then add a runner to the group and update your workflows to target either the group name or the label assigned to the より大きなランナー. You can also control which repositories are permitted to send jobs to the group for processing. For more information about groups, see "Controlling access to larger runners."

In the following diagram, a class of hosted runner named ubuntu-20.04-16core has been defined with customized hardware and operating system configuration.

1. Instances of this runner are automatically created and added to a group called grp-ubuntu-20.04-16core.
2. The runners have been assigned the label ubuntu-20.04-16core.
3. Workflow jobs use the ubuntu-20.04-16core label in their runs-on key to indicate the type of runner they need to execute the job.
4. GitHub Actions checks the runner group to see if your repository is authorized to send jobs to the runner.
5. The job runs on the next available instance of the ubuntu-20.04-16core runner.

Autoscaling より大きなランナーs

より大きなランナーs can automatically scale to suit your needs. You can provision machines to run a specified maximum number of jobs when jobs are submitted for processing. Each machine only handles one job at a time, so these settings effectively determine the number of jobs that can be run concurrently.

You can configure the maximum job concurrency, which allows you to control your costs by setting the maximum parallel number of jobs that can be run using this set. A higher value here can help avoid workflows being blocked due to parallelism. For more information, see "Managing larger runners."

Networking for より大きなランナーs

By default, より大きなランナーs receive a dynamic IP address that changes for each job run. Optionally, GitHub Enterprise Cloud customers can configure their より大きなランナーs to receive static IP addresses from GitHub's IP address pool. For more information, see "GitHubのIPアドレスについて."

When enabled, instances of the より大きなランナー will receive IP addresses from specific ranges that are unique to the runner, allowing you to use the ranges to configure a firewall allowlist. You can use up to 10 より大きなランナーs with static IP address ranges for the より大きなランナーs created at the enterprise level. In addition, you can use up to 10 より大きなランナーs with static IP address ranges for the より大きなランナーs created at the organization level, for each organization in your enterprise. For more information, see "Managing larger runners."

静的IPアドレス範囲で10以上の大きなランナーを使用したい場合は、GitHub Supportまでご連絡ください。