GitHub-hosted runners reference

Find information about GitHub-hosted runners, including their specifications and customization options.

Supported runners and hardware resources

Ranges of GitHub-hosted runners are available for use in public and private repositories.

For lists of available runners, see:

• Standard runners for public repositories
• Standard runners for private repositories

GitHub-hosted Linux runners support hardware acceleration for Android SDK tools, which 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.

Standard GitHub-hosted runners for public repositories

For public repositories, jobs using the workflow labels shown in the table below will run with the associated specifications. With the exception of single-CPU runners, each GitHub-hosted runner is a new virtual machine (VM) hosted by GitHub. Single-CPU runners are hosted in a container on a shared VM—see GitHub-hosted runners reference. Use of the standard GitHub-hosted runners is free and unlimited on public repositories.

Standard GitHub-hosted runners for private repositories

For private repositories, jobs using the workflow labels shown in the table below will run on virtual machines with the associated specifications. These runners use your GitHub account's allotment of free minutes, and are then charged at the per minute rates. See Actions runner pricing.

Workflow logs list the runner used to run a job. For more information, see Viewing workflow run history.

Limitations for arm64 macOS runners

• All actions provided by GitHub are compatible with arm64 GitHub-hosted runners. However, community actions may not be compatible with arm64 and need to be manually installed at runtime.
• Nested-virtualization is not supported due to the limitation of Apple's Virtualization Framework.
• Networking capabilities such as Azure private networking and assigning static IPs are not currently available for macOS larger runners.
• The arm64 macOS runners do not have a static UUID/UDID assigned to them because Apple does not support this feature. However, Intel MacOS runners are assigned a static UDID, specifically 4203018E-580F-C1B5-9525-B745CECA79EB. If you are building and signing on the same host you plan to test the build on, you can sign with a development provisioning profile. If you do require a static UDID, you can use Intel runners and add their UDID to your Apple Developer account.

Single-CPU runners

Single-CPU GitHub-hosted runners are available in both public and private repositories. These runners—specified using the workflow label ubuntu-slim—offer a lower-cost option for running lightweight operations. This type of runner is optimized for automation tasks, issue operations and short-running jobs. They are not suitable for typical heavyweight CI/CD builds.

ubuntu-slim runners execute Actions workflows in Ubuntu Linux, inside a container rather than a full VM instance. When the job begins, GitHub automatically provisions a new container for that job. All steps in the job execute in the container, allowing the steps in that job to share information using the runner's file system. When the job has finished, the container is automatically decommissioned. Each container provides hypervisor level 2 isolation.

A minimal set of tools is installed on the ubuntu-slim runner image, appropriate for lightweight tasks. For details on what software is installed on the ubuntu-slim image, see the README file in the actions/runner-images repository.

Usage limits

Single-CPU runners follow the same concurrency model as other GitHub-hosted standard runners. See Actions limits. The concurrency for the runners is determined by your plan.

The job timeout for single-CPU runners is 15 minutes. If a job reaches this limit, the job is terminated and fails.

Larger runners

Customers on GitHub Team and GitHub Enterprise Cloud plans can choose from a range of managed virtual machines that have more resources than the standard GitHub-hosted runners. These machines are referred to as "larger runners." They offer the following advanced features:

• More RAM, CPU, and disk space
• Static IP addresses
• Azure private networking
• The ability to group runners
• Autoscaling to support concurrent workflows
• GPU-powered runners

These larger runners are hosted by GitHub and have the runner application and other tools preinstalled.

For more information, see Using larger runners.

Administrative privileges

The Linux and macOS virtual machines both run using passwordless sudo. When you need to execute commands or install tools that require more privileges than the current user, you can use sudo without needing to provide a password. For more information, see the Sudo Manual.

Windows virtual machines are configured to run as administrators with User Account Control (UAC) disabled. For more information, see How User Account Control works in the Windows documentation.

IP addresses

To get a list of IP address ranges that GitHub Actions uses for GitHub-hosted runners, you can use the GitHub REST API. For more information, see the actions key in the response of the GET /meta endpoint. For more information, see REST API endpoints for meta data.

Windows and Ubuntu runners are hosted in Azure and subsequently have the same IP address ranges as the Azure datacenters. macOS runners are hosted in GitHub's own macOS cloud.

Since there are so many IP address ranges for GitHub-hosted runners, we do not recommend that you use these as allowlists for your internal resources. Instead, we recommend you use larger runners with a static IP address range, or self-hosted runners. For more information, see Using larger runners or Self-hosted runners.

The list of GitHub Actions IP addresses returned by the API is updated once a week.

Communication requirements for GitHub-hosted runners

A GitHub-hosted runner must establish connections to GitHub-owned endpoints to perform essential communication operations. In addition, your runner may require access to additional networks that you specify or utilize within an action.

To ensure proper communications for GitHub-hosted runners between networks within your configuration, ensure that the following communications are allowed.

Needed for essential operations:

github.com
api.github.com
*.actions.githubusercontent.com

Needed for downloading actions:

codeload.github.com

Needed for uploading/downloading job summaries, logs, workflow artifacts, and caches:

results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

Needed for runner version updates:

objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

Needed for retrieving OIDC tokens:

*.actions.githubusercontent.com

Needed for downloading or publishing packages or containers to GitHub Packages:

*.pkg.github.com
pkg-containers.githubusercontent.com
ghcr.io

Needed for Git Large File Storage

github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

Needed for jobs for Dependabot updates

dependabot-actions.githubapp.com

Needed for downloading release assets:

release-assets.githubusercontent.com

Needed for VNet:

api.snapcraft.io

File systems

GitHub executes actions and shell commands in specific directories on the virtual machine. The file paths on virtual machines are not static. Use the environment variables GitHub provides to construct file paths for the home, workspace, and workflow directories.

For a list of the environment variables GitHub creates for each workflow, see Store information in variables.

Docker container filesystem

Actions that run in Docker containers have static directories under the /github path. However, we strongly recommend using the default environment variables to construct file paths in Docker containers.

GitHub reserves the /github path prefix and creates three directories for actions.

• /github/home
• /github/workspace - Note: GitHub Actions must be run by the default Docker user (root). Ensure your Dockerfile does not set the USER instruction, otherwise you will not be able to access GITHUB_WORKSPACE.
• /github/workflow