OpsRunway Talk to an engineer

GitHub Actions pricing in 2026: what changed, and when self-hosted runners on AWS pay off.

GitHub Actions pricing changed on 1 January 2026: hosted runners got up to 39% cheaper, so a standard Linux runner now costs $0.006 a minute. The $0.002 a minute charge GitHub announced for self-hosted runners was postponed within days and has not come back. Below: the cost per minute, the free minutes in each plan, an illustrative 8-engineer team priced on GitHub and on AWS, and the break-even in minutes per month.

Checked: 31 Oct 2026, against GitHub's billing docs, changelog and roadmap, and AWS price lists for us-east-1

01Short answer

How much does GitHub Actions cost in 2026?

On private repositories, GitHub Actions costs $0.006 a minute on a standard Linux runner once your plan's free allowance is used up. Public repositories on standard runners, and self-hosted runners, cost nothing in GitHub fees.

QuestionAnswer on 31 Oct 2026
Cost per minute, standard Linux runner (2-core x64)$0.006, down from $0.008 before 1 Jan 2026
Cost per minute, Linux arm64 (2-core)$0.005
Cost per minute, Windows / macOS$0.010 / $0.062
Public repositoriesStandard hosted runners are free. Larger runners are billed.
Free usage on Team$18 of compute a month, which is 3,000 standard Linux minutes
Self-hosted runnersFree. The $0.002 a minute platform charge planned for 1 Mar 2026 was postponed and has no new date.
Do self-hosted runners on AWS pay off?On 2-core runners, usually not below about 100,000 minutes a month once you count upkeep. On 4-core and 8-core runners, much sooner.

If your bill is a few hundred dollars a month, the cheapest fix is almost always in the workflow files, not in a new runner fleet. Section 11 shows a 41% cut on the example bill without moving anything.

What changed in GitHub Actions pricing in 2025 and 2026?

Three GitHub Actions cost changes: hosted runners got up to 39% cheaper on 1 January 2026, the self-hosted runner charge announced for March 2026 was postponed, and on 28 October 2026 the free allowance became a dollar amount instead of minutes. Here they are in order.

  1. Two changes announced together.

    Hosted runner prices would drop by up to 39% on 1 January 2026. From 1 March 2026, a new "Actions cloud platform charge" of $0.002 a minute would apply to self-hosted runner jobs in private repositories, drawing from the minutes included in your plan. Public repositories would stay free.

  2. The self-hosted charge is postponed.

    GitHub added an update to the same changelog post: it was "postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach". The roadmap issue for the charge was closed as not planned that day, with a GitHub comment saying it had "missed the mark" by not involving more customers.

  3. The hosted price cut goes live.

    Linux 2-core went from $0.008 to $0.006 a minute, Windows from $0.016 to $0.010, macOS from $0.080 to $0.062. The roadmap issue was marked shipped on 10 April 2026.

  4. Free usage becomes a dollar amount.

    Included usage is now "one shared, dollar-based pool" instead of a count of minutes. It covers standard hosted runners and Copilot cloud sandboxes on every plan, and larger runners on Team and Enterprise Cloud. Sandbox billing starts in November 2026, so heavy Copilot users will see the pool shrink faster.

  5. Some hosted jobs now run on AWS.

    Standard 2-core and 4-core Linux jobs may now run on AWS as well as Azure: automatically on Free, Pro and Team, opt-in on Enterprise Cloud. The announcement mentions no price change. These runners use new outbound IPs, so update any allowlist that only trusts Azure ranges.

So the self-hosted charge you may have read about in December 2025 is not in force. GitHub's billing docs, checked today, say self-hosted runners are free and don't reduce your included compute.

What is the GitHub Actions cost per minute?

A standard Linux 2-core runner costs $0.006 a minute on a private repository, Linux arm64 $0.005, Windows $0.010 and macOS $0.062. Larger Linux runners start at $0.012 a minute for 4 cores. Here are the rates before and after 1 January 2026.

Runner (private repos)vCPU / RAMBeforeNowPer hour now
Linux 1-core x64 (slim)1 / 5 GB$0.002$0.002$0.12
Linux 2-core x64 (standard)2 / 8 GB$0.008$0.006$0.36
Linux 2-core arm64 (standard)2 / 8 GB$0.005$0.005$0.30
Windows 2-core x642 / 8 GB$0.016$0.010$0.60
macOS 3 or 4-coreM1 or Intel$0.080$0.062$3.72
Larger: Linux 4-core x644 / 16 GB$0.016$0.012$0.72
Larger: Linux 4-core arm644 / 16 GB$0.010$0.008$0.48
Larger: Linux 8-core x648 / 32 GB$0.032$0.022$1.32
Larger: Linux 8-core arm648 / 32 GB$0.020$0.014$0.84
Larger: Linux 16-core x6416 / 64 GB$0.064$0.042$2.52
Larger: Linux 4-core GPU4 cores, 1 T4$0.070$0.052$3.12

Per-hour figures are our arithmetic (rate × 60). The full list, including Windows and 32 to 96-core sizes, is on GitHub's pricing reference.

Three billing rules matter more than the rate itself:

  • Every job is rounded up to a whole minute. A 10-second lint job costs a full minute. Ten small jobs cost at least ten minutes, even if together they ran for two.
  • Failed runs cost money too. GitHub's own example: a 10-minute workflow that fails at minute 5 and is re-run costs 15 minutes.
  • arm64 is cheaper at every size. At 2 cores the saving is 17% ($0.005 against $0.006). At 4 and 8 cores it is 33% and 36%.

How many free GitHub Actions minutes do you get on a private repo?

Between 2,000 and 50,000 standard Linux minutes a month, depending on the plan: $12 of compute on Free, $18 on Pro and Team, $300 on Enterprise Cloud. Past that, a private repo pays the per-minute rate.

Public repositories run on standard hosted runners for free and don't touch your allowance. Private repositories draw from a monthly allowance that GitHub now states in dollars. GitHub's pricing page still lists 2,000, 3,000 and 50,000 minutes for Free, Team and Enterprise, which is the dollar figure divided by $0.006 a minute.

PlanIncluded compute / monthStandard Linux minutesArtifact + Packages storageCache per repo
Free (personal or organisation)$122,000500 MB10 GB
Pro$183,0001 GB10 GB
Team ($4 per user a month)$183,0002 GB10 GB
Enterprise Cloud ($21 per user a month)$30050,00050 GB10 GB

Because the allowance is money, not minutes, it goes further on cheap runners and runs out faster on expensive ones. $18 buys 3,000 minutes of Linux x64, 3,600 of Linux arm64, 1,800 of Windows, or 290 of macOS. On Team and Enterprise Cloud, larger runners can draw from it too.

Past the allowance you pay the per-minute rate. Storage beyond the plan costs $0.25 per GB a month for artifacts and Packages, and $0.07 per GB a month for cache. GitHub deletes cache entries nobody has used for 7 days, and only charges for cache above 10 GB if you raised the repository's limit.

Two things quietly use the same pool: Copilot code review in private repositories runs on Actions runners, and Copilot cloud sandboxes start drawing from it in November 2026. If your bill jumped and your pipelines didn't change, look at those first.

Note the seat price is separate. A team of eight on Team pays $32 a month in seats whatever its Actions bill is.

Does GitHub charge for self-hosted runners?

No, not on 31 October 2026. The $0.002 a minute charge GitHub announced for self-hosted runners from 1 March 2026 was postponed in December 2025 and has no new date. You pay only for the machines, to AWS or whoever runs them.

GitHub's argument in December 2025 was that self-hosted usage had been subsidised by hosted runner prices. Its FAQ said 96% of customers would see no change, and of the 4% affected, 85% would pay less and the rest would see a median increase of about $13. The increase would have landed on teams running many self-hosted minutes in private repositories, which is exactly the group that had moved off hosted runners to save money.

As announced, the charge would have:

  • cost $0.002 per self-hosted minute in private repositories, from 1 March 2026;
  • counted against the free allowance in your plan before you paid anything;
  • left public repositories and GitHub Enterprise Server unaffected.

Status today: postponed, with no new date, and the roadmap item closed as not planned. We found no GitHub post since then that brings it back. The current billing docs list self-hosted runners as free.

Why it still matters. If GitHub reintroduces a charge like this, it comes straight off your saving. On 2-core runners, a $0.002 fee would take the saving per minute in section 09 from $0.0039 to $0.0019 and double the break-even. Plan a self-hosted move so it still makes sense with the fee, or don't make it.

06Worked example

Illustrative. An invented team of 8 engineers on GitHub Team, one private repo, a Node service built into a container. Usage is made up; rates are GitHub's.

What does GitHub Actions cost an 8-engineer team?

In our illustrative example, about $204 a month: 37,074 billed minutes on standard Linux runners at the 2026 rate, less the Team plan's $18. The same minutes cost $273 at the 2025 rates and $167 on arm64.

Eight engineers each push to a pull request four times a working day and merge one and a half times. Every PR push runs lint, unit tests on three Node versions, a container build and integration tests. Every merge reruns the unit tests on all three Node versions, promotes the image built on the PR, deploys to staging, runs browser tests and deploys to production. Minutes are billed minutes, after rounding.

WorkflowArithmeticJobsMinutes / month
PR checks: lint 2, unit 3 × 7, build 6, integration 9 = 38 min, 6 jobs8 × 4 × 21 days = 672 runs × 384,03225,536
Main branch: unit 3 × 7, image promote 3, staging 5, browser tests 10, production 5 = 44 min, 7 jobs8 × 1.5 × 21 = 252 runs × 441,76411,088
Nightly dependency and security scan30 × 1530450
Total5,82637,074
Priced on GitHub-hosted runnersArithmetic$ /month
Linux 2-core x64, 2026 rate37,074 × $0.006 = $222.44, less $18 included204.44
Same usage at the 2025 rate37,074 × $0.008 = $296.59, less 3,000 min ($24)272.59
Linux 2-core arm6437,074 × $0.005 = $185.37, less $18167.37
For reference: the postponed self-hosted fee on the same minutes37,074 × $0.00274.15

So the January cut saved this team about $68 a month without anyone touching a file. At $204 a month, CI is a modest line next to a seed-stage AWS bill (compare the profiles in how much AWS costs a startup), but it grows with headcount and test count, not with revenue.

How do you run self-hosted GitHub Actions runners on AWS?

There are four common ways: CodeBuild as a managed Actions runner, ephemeral EC2 runners from the terraform-aws-github-runner module, Actions Runner Controller (ARC) on EKS, or a vendor-run runner manager such as RunsOn in your own account.

All four keep your workflows in GitHub. Only the machine that runs each job changes, via the runs-on label.

OptionHow it worksYou runBest for
CodeBuild as an Actions runnerA CodeBuild "runner project" listens for WORKFLOW_JOB_QUEUED webhooks and starts a fresh build per job. You set runs-on: codebuild-<project>-${{ github.run_id }}-${{ github.run_attempt }}.Nothing but the project and its IAM roleJobs that need IAM or VPC access to AWS resources, with no servers to look after
EC2 ephemeral runners (terraform-aws-github-runner)An MIT-licensed Terraform module, started at Philips Labs: Lambda functions take GitHub's webhook and launch EC2 instances, Spot by default, and scale to zero when idle. Ephemeral mode is a setting, off by default.The module, its Lambdas, runner AMIs, upgradesTeams with Terraform skills and enough minutes to care
Actions Runner Controller (ARC) on EKSGitHub's Kubernetes operator. Runner scale sets grow and shrink with queued jobs, and runners can be ephemeral pods. Version 0.15.0 shipped on 1 Oct 2026.A Kubernetes cluster and the controller's Helm chartsTeams already running EKS for the product
RunsOn style (vendor runs it in your account)A commercial runner manager installed in your AWS account. You pay AWS for instances and the vendor for a licence. RunsOn lists €300 a year under 50,000 jobs a month, and says its control plane costs from about $7 a month on your AWS bill.An install and its updatesTeams who want EC2 prices without owning the autoscaler code

CodeBuild can also run jobs on Lambda compute, billed per second with faster start-up. The catch: a 15-minute maximum, no Docker builds, no caching and no VPC connectivity. It suits lint and unit-test jobs, not container builds or jobs that reach private resources.

08Same month on AWS

Sources: CodeBuild pricing, CodeBuild compute types, EC2 On-Demand, EBS, VPC and NAT, EKS, EC2 Spot.

Illustrative. Same 37,074 minutes and 5,826 jobs, plus an assumed 1 minute of start-up per job: 42,900 machine minutes, or 715 hours.

What do self-hosted GitHub Actions runners cost on AWS?

For the example team's 37,074 minutes: about $78 a month on ephemeral x86 EC2 runners and $64 on Graviton, in public subnets, against $204 on GitHub. CodeBuild costs about the same as GitHub, and a dedicated NAT gateway wipes out the EC2 saving.

Item, us-east-1List priceArithmetic$ /month
CodeBuild general1.small (2 vCPU, 4 GiB)$0.005 /min(42,900 − 100 free) × $0.005214.00
CodeBuild arm1.small (2 vCPU, 4 GiB)$0.0034 /min42,800 × $0.0034145.52
CodeBuild general1.medium (4 vCPU, 8 GiB)$0.01 /min42,900 × $0.01429.00
EC2 m7i.large On-Demand (2 vCPU, 8 GiB)$0.1008 /hour715 h × $0.100872.07
EC2 m7g.large On-Demand (Graviton, 2 vCPU, 8 GiB)$0.0816 /hour715 h × $0.081658.34
EBS gp3 root disk, 30 GB per runner$0.08 /GB-month30 × $0.08 × 715 / 7302.35
Public IPv4 per runner, public subnets$0.005 /hour715 h × $0.0053.58
EC2 m7i.large runners, public subnets72.07 + 2.35 + 3.5878.00
EC2 m7g.large runners, public subnets58.34 + 2.35 + 3.5864.27
If the runners sit behind a new NAT gateway instead$0.045 /hour + $0.045 /GB$32.85 + $3.65 IPv4 + 2,913 GB × $0.045, less $3.58+ 164.01
ARC: an EKS cluster you don't already have$0.10 /hour730 h × $0.10+ 73.00

The NAT line assumes each job downloads 500 MB of packages, base images and caches (5,826 × 0.5 GB = 2,913 GB). That's illustrative, but CI is download-heavy, and NAT charges for every gigabyte it processes.

Not priced: the autoscaler's own Lambdas, queues and logs, and CloudWatch Logs if you ship runner logs. Spot instances, which AWS says can be up to 90% cheaper than On-Demand, would lower the EC2 lines further, but Spot prices move hourly and we couldn't verify a current one, so we left them at On-Demand.

What the table says:

  • CodeBuild is not a cost play at this size. Its x86 small has half the memory of GitHub's 2-core runner and costs about the same per minute. You choose it for IAM roles and VPC access, not for price.
  • Ephemeral EC2 is under 40% of the GitHub bill: $78 against $204 on x86, a saving of about $126 a month.
  • A NAT gateway wipes that saving out. Runners in private subnets behind a dedicated NAT gateway cost more than staying on GitHub.
09Break-even

Illustrative. Upkeep valued at $100 an engineer-hour. Use your own number; the formula is what matters.

When do self-hosted runners pay off? The break-even in minutes per month.

On standard 2-core runners, at roughly 100,000 minutes a month, if upkeep takes four hours a month. On 8-core larger runners, from about 28,000 minutes, because the saving per minute grows with the runner size.

A self-hosted fleet has a per-minute saving and a fixed monthly cost. The fixed cost is mostly people: patching runner images, bumping the runner version, upgrading the autoscaler, and working out why jobs queued on a Tuesday. The break-even is:

break-even minutes = monthly fixed cost ÷ (GitHub rate per minute − AWS cost per minute)

AWS cost per minute below is the On-Demand instance with the same CPU and memory as GitHub's runner, grossed up for 1 minute of start-up per job and the disk and IP, exactly as in section 08.

GitHub runnerAWS matchGitHub /minAWS /minSaving /min2 h upkeep4 h upkeep8 h upkeep
Linux 2-core x64m7i.large$0.006$0.0021$0.003951,000103,000205,000
Linux 2-core arm64m7g.large$0.005$0.0017$0.003361,000122,000245,000
Linux 4-core x64m7i.xlarge$0.012$0.0040$0.008025,00050,000101,000
Linux 8-core x64m7i.2xlarge$0.022$0.0079$0.014114,00028,00057,000

Instance prices used: m7i.xlarge $0.2016 an hour, m7i.2xlarge $0.4032 an hour (us-east-1 On-Demand, checked 31 Oct 2026). Upkeep columns are hours a month after the initial setup, which is a separate one-off cost of a few days.

Read the example team against this: 37,074 minutes on 2-core runners, against a break-even of roughly 103,000 at four hours of upkeep. The $126 a month it would save on compute is less than the $400 of engineering time. For this team, self-hosting doesn't pay. If all of its jobs ran on 8-core larger runners instead, the same 37,074 minutes would be past the break-even at two or four hours of upkeep (14,000 and 28,000 minutes).

Rules of thumb that fall out of the table:

  • On standard 2-core runners, think about self-hosting above roughly 100,000 minutes a month, or when you need something GitHub can't give you.
  • On 4-core and bigger, the break-even drops fast: the saving per minute grows with the runner size, while the upkeep stays about the same.
  • If you already run Terraform, EKS or a platform team, your real upkeep is lower. If nobody owns CI today, it is higher than you think.

What are the hidden costs of self-hosted runners?

Four costs don't show up on the runner line: NAT gateway data charges, caching that no longer sits next to GitHub, runner image and version upkeep, and the security risk of machines that run whatever a workflow tells them to.

NAT gateway. Covered above, and the most common surprise; it is the same NAT gateway trap described in our AWS setup guide for startups. Options: run ephemeral runners in public subnets with no inbound rules in their security group; send S3 traffic through a gateway endpoint, which is free; or use interface endpoints for ECR, at $0.01 an hour per endpoint per availability zone plus $0.01 a GB. Compare those with your NAT data line before adding them. Our AWS cost guide shows where NAT hides in Cost Explorer ("EC2-Other").

Caching. GitHub-hosted runners sit next to GitHub's cache. Your runners in us-east-1 download it over the internet, through the NAT if there is one. Ephemeral runners also start every job with an empty Docker layer cache, so builds can get slower even on a faster machine. Plan for a cache that lives in your account, such as an S3 bucket reached through the free gateway endpoint, and for a container registry close to the runners.

Maintenance. GitHub's Ubuntu image comes with a long list of tools preinstalled; yours has what you put in it, and every missing tool is a failed job someone has to debug. Runner versions are enforced: on Enterprise Cloud, since 29 September 2026 runners below 2.329.0 can't register, and registered runners below a higher minimum stop picking up jobs. The Terraform module itself needs Terraform 1.5.6 or later and AWS provider 6.33 or later, and it is maintained "on a best effort basis". Spot instances get a two-minute interruption notice before AWS reclaims them, so long jobs need retries.

Security. This is the one that can cost more than the whole CI bill.

  • Never put self-hosted runners on public repositories. GitHub's own guidance says they "should almost never be used for public repositories", because anyone who can open a pull request can run code on them.
  • Make every runner ephemeral. Self-hosted runners "can be persistently compromised by untrusted code in a workflow." One job per machine, then destroy it. GitHub's just-in-time runners do "at most one job" before they're removed.
  • Watch the instance role. Whatever IAM role the runner has, every workflow on it has too. Give runners almost nothing, and have each job assume a narrow role through GitHub's OIDC provider instead of long-lived keys.
  • Separate CI from production. Run runners in their own AWS account or VPC, and limit which repositories can use which runner group.

More on the pipeline side of this in DevSecOps for startups. If you are heading for SOC 2, auditors will ask who can change the pipeline: see SOC 2 on AWS.

How do you reduce GitHub Actions cost without moving runners?

Cancel superseded runs, skip work with path filters, cache dependencies, run the full test matrix less often and move Linux jobs to arm64. On the example team, two of those changes cut the bill by 41%.

Work through these before you price a runner fleet. Most take an hour, and they cut the bill on any runner, hosted or not.

  1. Cancel superseded runs. Give PR workflows a concurrency block with group: ${{ github.workflow }}-${{ github.ref }} and cancel-in-progress: true. When someone pushes twice in a minute, the first run stops instead of finishing for nobody. Don't use it on deploy workflows to production, where a half-cancelled deploy is worse than a wasted minute.
  2. Skip work the change can't affect. paths and paths-ignore filters on push and pull_request stop a docs-only change from running the whole suite. If at least one changed file matches paths, the workflow runs.
  3. Cache dependencies. setup-node, setup-python, setup-java, setup-go, setup-ruby and setup-dotnet can create and restore dependency caches for you. Cache Docker layers too.
  4. Run the full matrix less often. Test one version on pull requests and the full matrix on main or nightly. Keep fail-fast on (it defaults to true) so one failure cancels the rest.
  5. Move Linux jobs to arm64 where your toolchain builds for it: ubuntu-24.04-arm on standard runners.
  6. Set timeout-minutes. The default is 360. A job that hangs until then costs $2.16 on a 2-core runner and $7.92 on an 8-core one.
  7. Merge tiny jobs. Since each job rounds up to a minute, three 15-second checks cost three minutes as separate jobs and one minute as steps in one job.
  8. Use larger runners only where they halve the time. A 4-core runner costs twice the 2-core per minute. If the job doesn't run in half the time, it costs more.
The example team, two changes onlyArithmetic$ /month
Today, Linux 2-core x64from section 06204.44
Unit tests on one Node version in PRs, full matrix on main672 runs × 14 min saved = 9,408 min− 56.45
Then move to arm6427,666 min × $0.005 = $138.33, less $18120.33

That's 41% off with two pull requests, before cancelling stale runs or caching anything. It is also more than self-hosting would have saved this team after upkeep.

GitHub Actions vs AWS CodeBuild vs CodePipeline: which should you use?

For most small teams, keep GitHub Actions for pipelines and add CodeBuild as a runner only for jobs that must reach your VPC. CodeBuild is not cheaper per minute at small sizes, and CodePipeline makes sense only when deploys have to stay inside AWS.

GitHub ActionsAWS CodeBuildAWS CodePipeline
What it isWorkflows and runners, next to your codeBuild machines that run a buildspec, or GitHub Actions jobsAn orchestrator that chains source, build and deploy actions
BillingPer job-minute, rounded up per job, after the plan's allowancePer build-minute on EC2 from submission to finish, rounded up; per second on LambdaV2: $0.002 per action execution minute after 100 free. V1: $1 per active pipeline a month
Free usage$12 to $300 a month by plan; public repos free100 minutes a month on small; 6,000 seconds on Lambda 1 GB100 action minutes (V2) or one pipeline (V1)
AWS accessOIDC to an IAM roleNative IAM role, VPC, Secrets ManagerNative, through its actions
Watch out forLarger runners add up fastx86 small has 4 GiB of memoryA CodeBuild action is billed twice: action minutes in CodePipeline and build minutes in CodeBuild

Our view for a team of 2 to 15 engineers: keep GitHub Actions as the place where pipelines live. Engineers already read it, it sits next to pull requests, and its free allowance covers small teams. Add CodeBuild as a runner for the few jobs that need to be inside your VPC, such as migrations against a private database. Use CodePipeline only if you have a reason to keep deploys entirely inside AWS, for example an auditor who wants deploy history in the same account as the workload. If you are still choosing a platform, see GitHub alternatives compared: GitLab, Bitbucket, Azure DevOps and GitHub vs GitLab for a startup; if you are leaving another one, start with migrating your pipelines to GitHub Actions.

ARC is worth it only when Kubernetes is already part of the product. Running EKS just for CI adds $73 a month in control plane fees and a cluster to upgrade; our ECS vs EKS guide covers that trade.

13Questions

GitHub Actions pricing: short answers.

How much does GitHub Actions cost per minute?

On private repositories, a standard Linux 2-core runner costs $0.006 a minute, Linux arm64 $0.005, Windows $0.010 and macOS $0.062. Larger Linux runners run from $0.012 a minute (4-core) to $0.252 (96-core). Each job is rounded up to the next whole minute, so many short jobs cost more than their run time suggests.

How many free GitHub Actions minutes do I get per month?

The Free plan includes $12 of compute a month, which is 2,000 standard Linux minutes. Pro and Team include $18, or 3,000 minutes, and Enterprise Cloud $300, or 50,000. Since 28 October 2026 the allowance is a dollar amount, so the same pool buys fewer minutes on Windows, macOS or larger runners.

Is GitHub Actions free for private repositories?

Up to your plan's monthly allowance, yes: 2,000 to 50,000 standard Linux minutes depending on the plan. Past it, you pay the per-minute rate, $0.006 on a standard Linux runner. Public repositories are free on standard hosted runners and don't use the allowance at all, but larger runners are billed even on public repositories.

Is GitHub Actions free for self-hosted runners?

Yes, in GitHub fees. A $0.002 per minute platform charge on self-hosted runners in private repositories was announced for 1 March 2026 and postponed in December 2025, with no new date. GitHub's billing docs list self-hosted runners as free, and they don't use your included compute. You still pay your cloud provider for the machines.

Do failed and re-run jobs count against GitHub Actions minutes?

Yes. Every minute a job runs is billed, whether it passes or fails. GitHub's own example: a 10-minute workflow that fails at minute 5 and is then re-run costs 15 minutes. Setting timeout-minutes on jobs and cancelling superseded runs with a concurrency group are the two cheapest ways to stop paying for runs nobody needs.

Do larger runners use the free GitHub Actions minutes?

On Team and Enterprise Cloud, yes: since 28 October 2026 the shared dollar allowance covers larger runners as well as standard ones. Because a 4-core Linux runner costs twice the 2-core rate per minute, the allowance runs out twice as fast on it. Larger runners are billed even on public repositories, where standard runners are free.

How do I estimate my GitHub Actions bill?

Multiply runs per month by billed minutes per run, rounding each job up to a whole minute, then by the runner's per-minute rate, and subtract your plan's allowance. Our 8-engineer example comes to 37,074 minutes and about $204 a month on standard Linux runners. Count re-runs, nightly jobs and every matrix leg separately.

Is AWS CodeBuild cheaper than GitHub Actions?

Not at the small sizes. CodeBuild's x86 general1.small costs $0.005 a minute with 4 GiB of memory, against GitHub's $0.006 with 8 GB, and its arm1.small costs $0.0034. You choose CodeBuild for native IAM roles and VPC access rather than price. Plain ephemeral EC2 runners are where the real per-minute savings are.

How much do self-hosted GitHub Actions runners on AWS cost?

In our illustrative example, ephemeral m7i.large runners in public subnets cost about $78 a month for work that costs $204 on GitHub. Put them behind a dedicated NAT gateway and it rises to about $242. Add the engineering time to run them, and below roughly 100,000 minutes a month on 2-core runners self-hosting usually costs more than it saves.

What is Actions Runner Controller, and do I need it?

Actions Runner Controller (ARC) is GitHub's Kubernetes operator for self-hosted runners: runner scale sets that grow and shrink with the job queue, running jobs in ephemeral pods. You need it only if you already run Kubernetes and want CI there. Otherwise a CodeBuild runner project or ephemeral EC2 runners are less to operate, and you avoid $73 a month for an EKS control plane.

Are self-hosted runners safe for public repositories?

No. GitHub says self-hosted runners should almost never be used for public repositories, because anyone who can open a pull request can run code on your machines, and that code can persist on them. On private repositories, use ephemeral runners that take one job and are destroyed, with minimal IAM permissions and short-lived credentials through OIDC.

14Related
15Next step

If your Actions bill is a few hundred dollars a month, you don't need us: the quick wins above take an afternoon, and GitHub-hosted runners are the right answer. If CI is slow, the bill is past four figures, or jobs need to reach private AWS resources safely, a monthly plan covers it. Essentials gives you up to 20 hours a month of a senior engineer to tune workflows, set up OIDC roles, and run self-hosted runners only if the maths says so. If you'd rather have a one-off look first, the fixed-price AWS readiness review checks your CI/CD alongside IAM, backups and cost, for $1,900.

StripPLAN-20
PlanEssentials
Hoursup to 20 / mo
ResponseNext business day
TermMonthly after 3 mo
Price$2,900 /mo
NextFractional DevOps plan
Talk to an engineer