On this page
Overview
GitHub Actions Runner is the application that executes jobs from GitHub Actions workflows. The runner powers GitHub-hosted environments and can also be registered on Linux, macOS, or Windows machines you operate, giving workflows access to private networks, specialized hardware, and custom toolchains.
Features and best fit
Based on official documentation; not hands-on tested · Content checked:
Key features
Register your own machine as a GitHub Actions execution target
A runner can be registered at repository, organization, or enterprise scope and receives jobs whose runs-on labels match its operating system, architecture, and custom labels.
Use private networks and specialized hardware from CI jobs
Because a self-hosted runner executes on infrastructure you provide, workflows can reach internal services, GPUs, specialized SDKs, devices, or architectures that are not available in a standard hosted runner.
Sources: [5]
Best fit
Fits teams that need CI on controlled networks, hardware, or operating systems
It is useful for on-premise resources, private endpoints, GPUs, special architectures, persistent caches, and other environments teams need to manage themselves.
Sources: [5]
Before adoption
Do not expose public-repository pull requests to trusted self-hosted machines
GitHub recommends self-hosted runners only with private repositories because a fork of a public repository can potentially submit a pull request that executes dangerous code on the runner machine. Runner groups and access policies should narrow who can use the runner.
Sources: [6]
Disabled automatic updates still require an update within 30 days
Runners normally auto-update. If automatic updates are disabled, the runner must be updated within 30 days of a new version becoming available, and critical security updates can block job queueing sooner.
Sources: [5]
Prefer the repository settings download instructions over a globally newest release number
The v2.337.0 release notes describe a progressive release policy, so the newest release may not yet be the version offered to a particular enterprise, organization, or repository. Use the version and commands shown by the runner registration UI.
Official sources
- [1]GitHub Actions Runner README(2026-10-03)
- [2]GitHub Actions Runner v2.337.0 release(2026-10-03)
- [3]Runner authentication and authorization design(2026-10-03)
- [4]GitHub Docs — Adding self-hosted runners(2026-10-03)
- [5]GitHub Docs — Self-hosted runners reference(2026-10-03)
- [6]GitHub Docs — Managing access to self-hosted runners(2026-10-03)
- [7]GitHub Actions Runner MIT license(2026-10-03)
Supplemental curator note
Self-hosted runners are useful when CI needs GPUs, private network access, specialized operating systems, or other infrastructure not covered by hosted runners. They also execute workflow code on your own machine, so the trust boundary—especially for public repositories—must be designed much more carefully.
Try it in 3 steps
- 1
Open GitHub's runner registration page
Add a runner at the target repository or organization and choose its operating system and architecture.
Open Settings > Actions > Runners > New self-hosted runner - 2
Run the generated download and configuration commands
Use the version shown in the UI and register with the time-limited token. The registration token expires after one hour and should not be stored for reuse.
Run the download, extract, and ./config.sh commands shown by GitHub - 3
Start the runner and target it from a workflow
Start the runner and use self-hosted plus any required labels in runs-on. For persistent use, also design service operation and runner access policies.
./run.sh
Growth
Growth trends · Last 30 days
6,306 Stars
Trend data is still being collected.
Development activity
Last 90 days · weekly
- Commits (last 30 days)
- 35
- Open PRs
- 114
Development activity is still being collected.
Built with
Categories and tags
Categories
GitHub data
GitHub dataView detailed GitHub data
Related information
Write a related articleShare a guide or use case for this OSS in Markdown. Articles are published after administrator approval.
Explore next
- Changesets12,466 Stars
2 shared tag(s) · 3 shared category(s)
record SemVer bump intent and changelog notes with each change, then coordinate version updates and package publishing across monorepos
TypeScript - Allure Report5,548 Stars
2 shared tag(s) · 2 shared category(s)
turn results from multiple languages and test frameworks into unified reports with history, steps, and attachments
HTML - n8n206,530 Stars
2 shared tag(s) · 1 shared category(s)
Connect visual workflows, code, AI agents, and human approvals in one automation runtime
TypeScript - Dify157,734 Stars
2 shared tag(s) · 1 shared category(s)
design and publish AI workflows, retrieval, and agents on one platform
TypeScript - Home Assistant91,238 Stars
2 shared tag(s) · 1 shared category(s)
Unify lights, sensors, appliances, and services into a local-first entity and automation engine
Python - Docker Compose38,280 Stars
2 shared tag(s) · 1 shared category(s)
Define services, networks, volumes, and builds in compose.yaml and run them as one multi-container Docker application
Go
Report incorrect information
Tell us if any listing information is incorrect or outdated.