jobs.<job_id>.runs-on to define the type of machine to run the job on.
- The destination machine can be either a GitHub-hosted runner, larger runner, or a self-hosted runner.
- You can target runners based on the labels assigned to them, or their group membership, or a combination of these.
- You can provide
runs-onas a single string or as an array of strings.
- If you specify an array of strings, your workflow will execute on any runner that matches all of the specified
- If you would like to run your workflow on multiple machines, use
If you use a GitHub-hosted runner, each job runs in a fresh instance of a runner image specified by
Available GitHub-hosted runner types are:
|Runner image||YAML workflow label||Notes|
|Windows Server 2022||
|Windows Server 2019||
|Ubuntu 18.04 [deprecated]||
|macOS Monterey 12||
|macOS Big Sur 11||
|macOS Catalina 10.15 [deprecated]||
-latest runner images are the latest stable images that GitHub provides, and might not be the most recent version of the operating system available from the operating system vendor.
Warning: Beta and Deprecated Images are provided "as-is", "with all faults" and "as available" and are excluded from the service level agreement and warranty. Beta Images may not be covered by customer support.
For more information, see "About GitHub-hosted runners."
To specify a self-hosted runner for your job, configure
runs-on in your workflow file with self-hosted runner labels.
All self-hosted runners have the
self-hosted label. Using only this label will select any self-hosted runner. To select runners that meet certain criteria, such as operating system or architecture, we recommend providing an array of labels that begins with
self-hosted (this must be listed first) and then includes additional labels as needed. When you specify an array of labels, jobs will be queued on runners that have all the labels that you specify.
self-hosted label is not required, we strongly recommend specifying it when using self-hosted runners to ensure that your job does not unintentionally specify any current or future GitHub-hosted runners.
runs-on: [self-hosted, linux]
You can use
runs-on to target runner groups, so that the job will execute on any runner that is a member of that group. For more granular control, you can also combine runner groups with labels.
In this example, Ubuntu runners have been added to a group called
runs-on key sends the job to any available runner in the
name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: group: ubuntu-runners steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: '14' - run: npm install -g bats - run: bats -v
When you combine groups and labels, the runner must meet both requirements to be eligible to run the job.
In this example, a runner group called
ubuntu-runners is populated with Ubuntu runners, which have also been assigned the label
runs-on key combines
labels so that the job is routed to any available runner within the group that also has a matching label:
name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: group: ubuntu-runners labels: ubuntu-20.04-16core steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: '14' - run: npm install -g bats - run: bats -v