---
title: "Self-Hosted GitHub Actions Runners: Cost, Setup & Risks"
description: "Should you run your own GitHub Actions runners? What a self-hosted fleet really costs, the fork-code security risk, and when managed runners win instead."
url: https://starsling.dev/self-hosted-github-runners
canonicalUrl: https://starsling.dev/self-hosted-github-runners
dateModified: 2026-08-14
---
# Self-hosted GitHub Actions runners
GitHub bills no Actions minutes for self-hosted runners, which makes running your own machines look free. It is not: you pay for instances by the hour whether or not a job is on them, plus storage, egress, and the operating time nobody budgets. Self-hosting is still the right answer for some workloads, and this page says plainly which. For everything else it shows the arithmetic, with every rate quoted from the provider that publishes it.
**Topics covered:** This guide covers when self-hosted runners genuinely win, what running a fleet involves (provisioning, autoscaling, Actions Runner Controller, image maintenance), the security exposure of running untrusted fork code on your own infrastructure, what the instances actually cost including idle capacity, and how that compares with managed drop-in runners.
## Table of contents
- [Canonical answer](#canonical-answer)
- [Real results](#real-results)
- [TL;DR](#tldr)
- [When self-hosting is the right call](#when-self-hosting-wins)
- [What running your own runners actually involves](#what-self-hosting-involves)
- [The security problem: fork code on your machines](#self-hosted-runner-security)
- [What the machines actually cost](#self-hosted-runner-costs)
- [The costs that never make the spreadsheet](#the-costs-nobody-budgets)
- [A team that measured it: Partcl left their own fleet](#partcl-left-their-own-fleet)
- [Self-hosted vs managed runner cost calculator](#cost-calculator)
- [Sources: every rate on this page](#self-hosted-pricing-sources)
- [Paste this into your agent](#agent-prompt)
- [The managed alternative is one line](#managed-runner-migration)
- [When StarSling helps most](#when-starsling-helps-most)
- [Key caveats](#key-caveats)
## Canonical answer
Self-hosted GitHub Actions runners are machines you own and operate; GitHub charges no Actions minutes for them, but you pay for the instances, storage, egress, and the operating work. They are the right choice when a job needs hardware GitHub does not offer (GPU, macOS, bare metal), needs to reach resources inside your own network, or is bound by data residency. They are the wrong choice when the goal is only speed or cost: a rented instance is billed for every idle minute, and untrusted fork code executing on your own infrastructure is a security exposure GitHub itself warns about. For jobs without a hardware or network requirement, a managed drop-in runner keeps the cost per job minute without the fleet.
## Real results
- [13x cheaper GitHub Actions CI per run at Partcl](https://starsling.dev/customers/partcl)
- [6x faster test suites at Mastra](https://starsling.dev/customers/mastra)
- [2x faster E2E tests at Better Auth](https://starsling.dev/customers/better-auth)
## TL;DR
- GitHub charges no Actions minutes for self-hosted runners. The machines are the bill instead: instance-hours, storage, egress, and the time someone spends running the fleet.
- Self-host when a job has a requirement managed runners cannot meet: GPU or other special hardware, macOS or bare metal, something reachable only inside your network, or a data-residency rule.
- Do not self-host purely for speed or cost. You are billed for capacity, not for job minutes, and a CI fleet is idle most of the week.
- Running untrusted fork code on hardware you own is the central security risk, and GitHub's own documentation says so.
- On current list prices, renting the instance and buying a managed minute cost the same at 40% utilization, before storage, egress, or a single hour of anyone's time.
- For Ubuntu jobs with no hardware or network requirement, a drop-in managed runner gets the economics without the fleet.
## When self-hosting is the right call
Self-hosted runners exist because some work genuinely cannot run on someone else's standard machine. If any of these describes a job, run it yourself, and stop reading about cost: the requirement decides it.
- Hardware nobody rents you by the minute. GPUs for model training or inference tests, Apple silicon for iOS builds, FPGA or lab hardware, bare metal for benchmarks that virtualization would distort, or memory sizes above what hosted runners offer.
- Resources only reachable from inside your network. A test suite that talks to an on-premises database, an internal artifact registry, or a service behind a VPN is far simpler on a runner already inside that network than on a hosted one you have to tunnel into.
- Data residency and compliance boundaries. If source or test data may not leave a jurisdiction or a VPC you control, a runner you own in that boundary is the straightforward answer.
- Very large, sustained, predictable volume. Utilization is the whole argument. A fleet that genuinely stays busy, on reserved capacity or committed spend, can beat per-minute pricing on compute.
- Software already licensed to your hardware. Some toolchains are licensed per machine, and a hosted runner cannot carry the licence.
These are real, and they are why self-hosted runners exist. The rest of this page is about the other case: teams reaching for self-hosting to make CI faster or cheaper, where the arithmetic usually does not land where they expect.
## What running your own runners actually involves
Registering one runner takes minutes: download the agent, add a token, start the service. That machine is not a fleet. The work is everything that keeps a fleet correct while people are shipping through it:
- Provisioning and capacity. Someone decides how many machines exist, of what size, in which subnets, with what IAM and what network access. Too few and jobs queue; too many and you pay for idle.
- Autoscaling. A static pool is the expensive way to do this, so most teams end up autoscaling. GitHub's supported path is [Actions Runner Controller (ARC)](https://docs.github.com/en/actions/concepts/runners/actions-runner-controller), which GitHub describes as "a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions". That is the real commitment: a Kubernetes cluster, Helm releases, a controller to upgrade, and its failure modes on your on-call rota.
- Runner images. Hosted runners arrive with a large, maintained toolchain. Your image has to match what your workflows assume, then keep matching: language runtimes, Docker, build tools, certificates, and OS patches, rebuilt and rolled out on a schedule.
- Ephemerality and cleanup. A reused runner carries state between jobs, which is both a flaky-test source and a security problem. Ephemeral, one-job runners fix it and put more load on the scaling loop.
- Caching and storage. Hosted caching is a service you get; on your own fleet it is infrastructure you run, size, and pay for.
- Observability and on-call. When the fleet stops taking jobs, CI stops for everyone, and it is now your outage rather than your vendor's.
None of this is exotic, and plenty of teams do it well. It is simply a platform service, and it should be budgeted as one: recurring engineering time, not a one-off setup task.
## The security problem: fork code on your machines
This is the part that most often decides it, and it is not our opinion. GitHub's own documentation on adding a self-hosted runner carries this warning:
"We recommend that you only use self-hosted runners with private repositories. This is because forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow."
On a hosted runner, a pull request from a stranger runs on a clean machine that is destroyed afterwards, inside someone else's blast radius. On your runner it runs inside your network, on hardware that may hold credentials, caches, and a route to the rest of your infrastructure. The exposure to plan for:
- Persistence between jobs. A non-ephemeral runner lets one job leave something behind for the next one, including a job that came from a fork.
- Network position. The runner sits wherever you put it. Anything it can reach, code running on it can reach, including internal services that assume every caller is trusted.
- Credentials on the box. Cloud instance roles, registry logins, and cached tokens are all readable by whatever the job executes.
- Cache and artifact poisoning. A shared cache written by an untrusted job is consumed by a trusted one later.
- Actions you did not pin. A mutable tag resolves to whatever it points at today, which is why [pinning action SHAs](/best-practices/github-actions/pin-action-shas) matters more, not less, once the runner is yours.
- Over-broad tokens. A workflow that hands every job a write-scoped token widens the damage; [scope id-token and permissions per job](/best-practices/github-actions/scope-id-token-per-job).
If you self-host, treat it as production infrastructure exposed to untrusted input: private repositories only, ephemeral runners, isolated networks, no long-lived credentials on the instance, and required approval for workflows triggered by forks. The free [/ci-secure skill](/ci-secure) scans a repository for the exploit chains this exposes, including fork code executed with privileges and cache poisoning.
- [GitHub - Adding self-hosted runners (the fork-code warning, quoted above)](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners)
- [Pin action SHAs](https://starsling.dev/best-practices/github-actions/pin-action-shas)
- [Scope id-token per job](https://starsling.dev/best-practices/github-actions/scope-id-token-per-job)
## What the machines actually cost
GitHub is explicit that "GitHub Actions usage is free for self-hosted runners", so the whole bill moves to your cloud account. These are AWS On-Demand list prices for Linux in US East (N. Virginia), read from AWS's published price list on 2026-08-14. Each instance is matched to the StarSling size with the same vCPU count and memory, so the comparison is between equivalent machines. Both columns are quoted per hour because that is the unit AWS publishes; StarSling's rate card is per minute and converts exactly, so the 4 vCPU / 16 GB row below reads $0.008/min on the [pricing page](https://docs.starsling.dev/pricing).
| Runner size | EC2 On-Demand | StarSling | Break-even utilization | What it means |
| --- | --- | --- | --- | --- |
| 2 vCPU / 8 GB (`m6i.large`) | $0.096/hr | $0.240/hr | 40% | The shape of a standard hosted runner on a private repository; public repositories get a larger 4 vCPU / 16 GB runner free. Cheap per hour, which is exactly why idle instances go unnoticed until you count them by the month. |
| 4 vCPU / 16 GB (`m6i.xlarge`) | $0.192/hr | $0.480/hr | 40% | The common CI default. Both sides double with the vCPU count, so paying for idle capacity costs the same share of the bill at every size. |
| 8 vCPU / 32 GB (`m6i.2xlarge`) | $0.384/hr | $0.960/hr | 40% | Worth renting only if a job genuinely saturates eight cores. A half-used instance still bills in full. |
| 16 vCPU / 64 GB (`m6i.4xlarge`) | $0.768/hr | $1.920/hr | 40% | Fast, and unforgiving of idle. One of these left up all month is an expensive way to wait for someone to push. |
## The costs that never make the spreadsheet
The instance rate is the number people compare. It is not the bill. Four things get left out, and together they usually decide the answer:
- Idle capacity. You rent machines by the hour and use them by the job minute. CI demand is bursty and weekday-shaped, so a fleet sized for the morning peak is mostly idle by evening. This is what the break-even column above measures: below 40% utilization, a rented instance costs more per job minute than a managed one.
- Storage. Every runner needs a root volume, and images for real toolchains are not small. EBS gp3 is $0.08 per GB-month, so a 100 GB volume is $8.00 a month for every instance you keep warm, running jobs or not.
- Egress. Pulling images, dependencies, and caches out to the internet bills at $0.09 per GB. AWS gives every customer 100 GB of data transfer out free each month, but that allowance is aggregated across all services and regions in the account, not granted to the fleet: if anything else in the account already serves traffic, the runners bill from their first GB. A busy fleet pulling containers on every job finds this line faster than expected.
- Operating time. Someone maintains the images, upgrades the controller, and answers the page when the fleet stops accepting jobs. It is the largest cost in most honest models and the one that never appears in the comparison.
The calculator below counts instance time and ops time. Storage and egress are left out of it deliberately, which means it understates the self-hosted side rather than ours.
## A team that measured it: Partcl left their own fleet
Everything above is arithmetic. [Partcl](/customers/partcl) is the measured version of it: a chip-design startup that ran its own self-hosted runners on the most powerful machines it could get, precisely because CI was heavy and nobody had time to tune it.
Their CTO put it plainly: "We'd been throwing the most powerful machines we could get at our CI and we didn't have time to sit there and optimize it."
They moved those jobs onto managed StarSling runners. Each line of this page's argument shows up in what they measured afterwards:
- Capacity you pay for and do not get. Roughly one in four of their self-hosted jobs used to be cancelled and billed anyway. None of the 500+ StarSling jobs sampled were.
- A fixed fleet is a queue. Their self-hosted fleet allowed about 6 concurrent jobs, where the same CI matrix runs at roughly 35 on StarSling. The p95 wait for a runner fell from 9.5 minutes to 35 seconds, about 16x shorter, and the worst case from 18 minutes to about a minute.
- Machines sized for the worst job, billed on every job. They were running 64-core machines on jobs that did not need them, and right-sizing moved the heaviest jobs onto 8-core runners.
- What that did to the cost per run. On their heaviest CI jobs, like-for-like productive compute came out about 13x cheaper per run than on their old self-hosted runners, and their slowest shard fell from 59-89 minutes to 5-7 minutes, about 94x cheaper per shard.
- Nobody ran a migration project. The wins came from eight PRs StarSling's agents opened on their own over the first five weeks (build and artifact caching, test parallelization, right-sizing), which the team reviewed and merged.
These are one team's measured ratios on one workload, not a benchmark, and cost is compared as multipliers from GitHub Actions job timings rather than absolute spend. The full write-up, including how each figure was taken, is in their case study.
- [How Partcl cut GitHub Actions costs 13x and reduced queue time by 16x](https://starsling.dev/customers/partcl)
## Self-hosted vs managed runner cost calculator
Pick a size, set how much of the capacity you rent actually runs jobs, and the estimate updates as you type. The self-hosted side pays for every instance-minute it holds; the managed side pays only for job minutes. Set ops time to zero to compare compute alone.
| Runner | Self-hosted on EC2 | StarSling |
| --- | --- | --- |
| Linux 2 vCPU / 8 GB (m6i.large) | $0.096/hr | $0.240/hr |
| Linux 4 vCPU / 16 GB (m6i.xlarge) | $0.192/hr | $0.480/hr |
| Linux 8 vCPU / 32 GB (m6i.2xlarge) | $0.384/hr | $0.960/hr |
| Linux 16 vCPU / 64 GB (m6i.4xlarge) | $0.768/hr | $1.920/hr |
Worked example: 100,000 Linux minutes per month on 4 vCPU / 16 GB (m6i.xlarge) with 40% fleet utilization, 4 h ($600) of ops time. Self-hosted on EC2 pays for 250,000 instance-minutes and $600.00 of ops time, for $1,400.00; StarSling prices all 100,000 minutes at $800.00.
Ops time is converted at an assumed $150.00 per engineer-hour, which is our assumption and not a published rate. Storage and egress are not counted, so the self-hosted figure is a floor. AWS prices are On-Demand list rates in US East (N. Virginia), checked 2026-08-14; StarSling rates are the [published rate card](https://docs.starsling.dev/pricing).
## Sources: every rate on this page
AWS figures are AWS's published list prices, read on 2026-08-14; GitHub's claims are quoted from GitHub's documentation; StarSling's rates are our published rate card. Each is linked here so you can check it:
- [AWS - EC2 On-Demand pricing (instance rates, and data transfer out)](https://aws.amazon.com/ec2/pricing/on-demand/)
- [AWS - EBS pricing (gp3 per GB-month)](https://aws.amazon.com/ebs/pricing/)
- [GitHub - GitHub-hosted runner specifications (standard runner sizes: 2 vCPU / 8 GB on private repositories, 4 vCPU / 16 GB free on public ones)](https://docs.github.com/en/actions/reference/runners/github-hosted-runners)
- [GitHub - Actions billing concepts ("GitHub Actions usage is free for self-hosted runners")](https://docs.github.com/en/billing/concepts/product-billing/github-actions)
- [GitHub - Adding self-hosted runners (the fork-code security warning)](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners)
- [GitHub - Actions Runner Controller (the Kubernetes autoscaling path)](https://docs.github.com/en/actions/concepts/runners/actions-runner-controller)
- [StarSling - published runner pricing](https://docs.starsling.dev/pricing)
## Paste this into your agent
This prompt runs the decision against your own repository: which jobs have a genuine self-hosting requirement, what self-hosting each workflow would expose, and what a fleet would have to cost.
Decide whether this repository should run GitHub Actions jobs on self-hosted runners. Inspect .github/workflows/*.yml and .github/workflows/*.yaml and report four things. First, any job with a genuine self-hosting requirement: GPU or other special hardware, macOS or bare metal, a dependency reachable only inside a private network, or a data-residency constraint. Second, the security exposure of self-hosting each workflow: which are triggered by pull_request from forks, which use pull_request_target, and which hold secrets or a write-scoped GITHUB_TOKEN, since untrusted fork code executing on a runner you own is the central risk. Third, the operating surface a fleet would need: peak concurrent jobs, the runner image and its dependencies, and whether autoscaling would need Actions Runner Controller on Kubernetes. Fourth, the monthly job minutes by runner size, so instance time can be priced against a managed per-minute runner. Recommend self-hosting only for the jobs with a requirement the first check found, and say plainly which jobs should stay on managed runners.
## The managed alternative is one line
For Ubuntu jobs with no hardware or network requirement, the alternative to building a fleet is a label change. Keep GitHub Actions syntax and every existing action; point Ubuntu/Linux jobs at a [supported StarSling instance type](https://docs.starsling.dev/runners/instance-types).
### Self-hosted
```yaml
runs-on: [self-hosted, linux, x64]
```
### Managed drop-in
```yaml
runs-on: starsling-ubuntu-24.04
```
- No fleet to size, patch, autoscale, or wake up for.
- Ephemeral by construction, so no state carries between jobs.
- Queue time is never billed, and idle capacity is not yours to pay for.
- Checks, branch protections, and PR review flow stay in GitHub Actions.
## When StarSling helps most
StarSling is a managed drop-in runner, not a way to run your own hardware. It is the better answer than a self-hosted fleet when:
- Your jobs run on `ubuntu-latest` or `ubuntu-24.04` and need no GPU, no macOS, and no bare metal.
- Nothing in the job has to reach inside your private network, and no data-residency rule pins where it runs.
- Your CI load is bursty, so a fleet you own would spend most of the week idle at your expense.
- You would rather not add a Kubernetes controller, a runner image pipeline, and a fleet outage to the platform team's rota.
- You want the cost per job minute to fall without GitHub Actions syntax, checks, or branch protections changing at all.
If a job genuinely needs hardware we do not offer or a network we cannot reach, self-host that job. Most teams find it is a handful of jobs, not the whole pipeline, and the rest moves with a label change.
- [GitHub Actions pricing](https://starsling.dev/github-actions-pricing)
- [GitHub Actions alternatives](https://starsling.dev/github-actions-alternatives)
- [GitHub Actions CI best-practices catalog](https://starsling.dev/best-practices/github-actions)
## Key caveats
- AWS list prices quoted here are On-Demand Linux rates in US East (N. Virginia), read from AWS's published price list on 2026-08-14; your region, commitments, and Savings Plans will differ.
- The ops-time cost is an assumption, not a published rate. The calculator offers zero ops time so you can price compute alone.
- Self-hosting genuinely wins for GPU, macOS, bare-metal, network-isolated, and data-residency workloads. StarSling does not replace those.
- StarSling runners are Ubuntu/Linux only; macOS and Windows jobs stay on GitHub-hosted runners.
- StarSling keeps GitHub Actions syntax, checks, and branch protections. It is not a replacement CI platform.
## FAQ
### Are self-hosted GitHub Actions runners free?
GitHub charges no Actions minutes for them: GitHub's billing documentation states that GitHub Actions usage is free for self-hosted runners. The machines are not free. You pay for instance-hours whether or not a job is running, plus storage, data transfer, and the engineering time to run the fleet.
### Should I run my own GitHub Actions runners?
Yes, if a job needs something managed runners cannot give it: GPU or other special hardware, macOS or bare metal, a resource reachable only inside your network, or a data-residency rule. Probably not, if the goal is speed or cost alone. You rent capacity by the hour but use it by the job minute, and CI load is bursty, so much of what you pay for runs nothing.
### Are self-hosted runners cheaper than managed runners?
Only above a utilization threshold. At AWS On-Demand list prices in US East (N. Virginia), checked 2026-08-14, an EC2 instance and the equivalent StarSling runner cost the same per job minute at 40% utilization. Below that the managed minute is cheaper on compute alone, before storage, egress, or any operating time.
### What is the security risk of self-hosted runners?
Untrusted code running on infrastructure you own. GitHub recommends using self-hosted runners only with private repositories, because forks of a public repository can run dangerous code on your runner by opening a pull request that executes it in a workflow. On your own machine that code sits inside your network, next to your credentials and caches.
### What is Actions Runner Controller (ARC)?
GitHub describes ARC as a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions. It is the supported way to autoscale a fleet, and it is also the real cost of self-hosting: a Kubernetes cluster, Helm releases, a controller to keep upgraded, and its failure modes on your on-call rota.
### What does it cost to run a self-hosted GitHub Actions runner on AWS?
On AWS On-Demand list prices for Linux in US East (N. Virginia), checked 2026-08-14, a 4 vCPU / 16 GB instance (m6i.xlarge) is $0.192/hr, billed for every hour the machine is up. Add EBS gp3 storage at $0.08 per GB-month, data transfer out at $0.09 per GB (AWS's 100 GB of free monthly egress is aggregated across the whole account, not per fleet, so an account that serves anything else has usually spent it), and the engineering time to operate the fleet.
### Do self-hosted runners make CI faster?
Not by themselves. They can remove queue time if the fleet is over-provisioned, which you pay for, and they let you pick faster hardware than a standard hosted runner. Neither requires owning the machines: a managed drop-in runner offers larger sizes and does not bill queue time, without a fleet to operate.
### Can I move off self-hosted runners without rewriting my workflows?
For Ubuntu/Linux jobs with no hardware or network requirement, yes. Change the `runs-on` label from your self-hosted labels to a supported StarSling instance type. Workflow syntax, existing actions, checks, and branch protections all stay in GitHub Actions. Jobs with a genuine hardware or network requirement stay self-hosted.
## Related resources
- [GitHub Actions pricing](https://starsling.dev/github-actions-pricing)
- [Fast GitHub Actions](https://starsling.dev/fast-github-actions)
- [Diagnose why GitHub Actions is too slow](https://starsling.dev/github-actions-too-slow)
- [GitHub Actions alternatives](https://starsling.dev/github-actions-alternatives)
- [StarSling vs GitHub Actions](https://starsling.dev/compare/github-actions)
- [GitHub Actions CI best practices](https://starsling.dev/best-practices/github-actions)
- [Pin action SHAs](https://starsling.dev/best-practices/github-actions/pin-action-shas)
- [Scope id-token per job](https://starsling.dev/best-practices/github-actions/scope-id-token-per-job)
- [Cut queue time](https://starsling.dev/best-practices/github-actions/cut-queue-time)
- [How Partcl cut GitHub Actions cost 13x](https://starsling.dev/customers/partcl)
- [How Mastra got 6x faster GitHub Actions tests](https://starsling.dev/customers/mastra)
- [Install the /ci-secure skill to close critical attack vectors in GitHub Actions](https://starsling.dev/ci-secure)
- [Install the free /ci-speedup skill to fix slow GitHub Actions](https://starsling.dev/ci-speedup)
- [Install the free /ci-score skill to improve your GitHub Actions setup](https://starsling.dev/ci-score)
## Get started
- [Get the cost of self-hosting without the fleet](https://github.com/apps/starslingdev)
- [See GitHub Actions pricing](https://starsling.dev/github-actions-pricing)
- [Install the free /ci-speedup skill to fix slow GitHub Actions](https://starsling.dev/ci-speedup). Install with `npx skills add starslingdev/skills`.