{"meta":{"title":"GitHub-hosted runners","intro":"GitHub offers hosted virtual machines to run workflows. The virtual machine contains an environment of tools, packages, and settings available for GitHub Actions to use.","product":"GitHub Actions","breadcrumbs":[{"href":"/en/actions","title":"GitHub Actions"},{"href":"/en/actions/concepts","title":"Concepts"},{"href":"/en/actions/concepts/runners","title":"Runners"},{"href":"/en/actions/concepts/runners/github-hosted-runners","title":"GitHub-hosted runners"}],"documentType":"article"},"body":"# GitHub-hosted runners\n\nGitHub offers hosted virtual machines to run workflows. The virtual machine contains an environment of tools, packages, and settings available for GitHub Actions to use.\n\n## Overview of GitHub-hosted runners\n\nRunners are the machines that execute jobs in a GitHub Actions workflow. For example, a runner can clone your repository locally, install testing software, and then run commands that evaluate your code.\n\nGitHub provides runners that you can use to run your jobs, or you can [host your own runners](/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners). 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](/en/actions/reference/runners/github-hosted-runners#single-cpu-runners).\n\nEach runner comes with the runner application and other tools preinstalled. GitHub-hosted runners are available with Ubuntu Linux, Windows, or macOS operating systems. When you use a GitHub-hosted runner, machine maintenance and upgrades are taken care of for you.\n\nYou can choose one of the standard GitHub-hosted runner options or, if you are on the GitHub Team or GitHub Enterprise Cloud plan, you can provision a runner with more cores, or a runner that's powered by a GPU processor. These machines are referred to as \"larger runner.\" For more information, see [Larger runners](/en/enterprise-cloud@latest/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners).\n\nLarger runners also support custom images, which let you create and manage your own preconfigured VM images. For more information, see [Custom images](#custom-images).\n\nUsing GitHub-hosted runners requires network access with at least 70 kilobits per second upload and download speeds.\n\n## Runner images\n\nGitHub maintains our own set of VM images for our standard hosted runners. This includes the images for macOS, x64 linux and Windows images. The list of images and their included tools are managed in the [`actions/runner-images`](https://github.com/actions/runner-images) repository. Our arm64 images are partner images, and those are managed in the [`actions/partner-runner-images`](https://github.com/actions/partner-runner-images) repository.\n\n### Preinstalled software for GitHub-owned images\n\nThe software tools included in our GitHub-owned images are updated weekly. The update process takes several days, and the list of preinstalled software on the `main` branch is updated after the whole deployment ends.\n\nWorkflow logs include a link to the preinstalled tools on the exact runner. To find this information in the workflow log, expand the `Set up job` section. Under that section, expand the `Runner Image` section. The link following `Included Software` will describe the preinstalled tools on the runner that ran the workflow.\n\nFor more information, see [Viewing workflow run history](/en/actions/monitoring-and-troubleshooting-workflows/viewing-workflow-run-history).\n\nGitHub-hosted runners include the operating system's default built-in tools, in addition to the packages listed in the above references. For example, Ubuntu and macOS runners include `grep`, `find`, and `which`, among other default tools.\n\nYou can also view a software bill of materials (SBOM) for each build of the Windows and Ubuntu runner images. For more information, see [Secure use reference](/en/actions/security-guides/security-hardening-for-github-actions#reviewing-the-supply-chain-for-github-hosted-runners).\n\nWe recommend using actions to interact with the software installed on runners. This approach has several benefits:\n\n* Usually, actions provide more flexible functionality like version selection, ability to pass arguments, and parameters\n* It ensures the tool versions used in your workflow will remain the same regardless of software updates\n\nIf there is a tool that you'd like to request, please open an issue at [actions/runner-images](https://github.com/actions/runner-images). This repository also contains announcements about all major software updates on runners.\n\n> \\[!NOTE]\n>\n> * You can also install additional software on GitHub-hosted runners. See [Customizing GitHub-hosted runners](/en/actions/using-github-hosted-runners/customizing-github-hosted-runners).\n> * While nested virtualization is technically possible while using runners, it is not officially supported. Any use of nested VMs is experimental and done at your own risk, we offer no guarantees regarding stability, performance, or compatibility.\n\n### Custom images\n\nCustom images let you start with a GitHub-provided base image and build your own VM image that’s customized to your workflow needs. With custom images, you can:\n\n* Build custom VM images using existing workflow YAML syntax.\n* Pre-configure environments with approved tooling, security patches, and dependencies before workflows start.\n* Create consistent, validated base environments across all builds.\n\nCustom images can include repository code, container images, binaries, certificates, and other dependencies to create a consistent build environment across workflows. This helps you gain control over your supply chain. They help reduce setup time, improve build performance, and strengthen security by reducing the surface attack vector on your images. Administrators can also apply policies to manage image versions, retention, and age to meet organizational security and compliance requirements.\n\nCustom images can only be used with larger runners. Jobs that use custom images are billed at the same per-minute rates as those runners. Storage for custom images is billed and metered through GitHub Actions storage. For more information, see [GitHub Actions billing](/en/billing/concepts/product-billing/github-actions#custom-image-storage).\n\nTo get started with custom images, see [Using custom images](/en/actions/how-tos/manage-runners/larger-runners/use-custom-images).\n\n## Cloud hosts used by GitHub-hosted runners\n\nGitHub hosts Linux and Windows runners on virtual machines in Microsoft Azure with the GitHub Actions runner application installed. The GitHub-hosted runner application is a fork of the Azure Pipelines Agent. Inbound ICMP packets are blocked for all Azure virtual machines, so ping or traceroute commands might not work. GitHub hosts macOS runners in Azure data centers.\n\n## Workflow continuity\n\nIf GitHub Actions services are temporarily unavailable, then a workflow run is discarded if it has not been queued within 30 minutes of being triggered. For example, if a workflow is triggered and the GitHub Actions services are unavailable for 31 minutes or longer, then the workflow run will not be processed.\n\nIn addition, if the workflow run has been successfully queued, but has not been processed by a GitHub-hosted runner within 45 minutes, then the queued workflow run is discarded.\n\n## The `etc/hosts` file\n\nGitHub-hosted runners are provisioned with an `etc/hosts` file that blocks network access to various cryptocurrency mining pools and malicious sites. Hosts such as MiningMadness.com and cpu-pool.com are rerouted to localhost so that they do not present a significant security risk."}