# GitHub Actions vs GitLab CI: what a minute costs on each

> GitHub Actions vs GitLab CI, priced properly: GitLab multiplies each minute by a cost factor, GitHub sells a flat rate per size. They cross at 20,500.

Source: https://latchkey.dev/learn/runners/github-actions-vs-gitlab-ci-compared  
Updated: 2026-09-21

GitHub Actions vs GitLab CI is not the feature comparison it is usually written as, because both define pipelines in YAML and both run them on hosted or self-managed machines. The difference that shows up on an invoice is arithmetic: GitLab multiplies each job minute by a cost factor tied to the machine size, and GitHub publishes a flat per-minute rate for each size instead.

GitLab.com measures instance runner usage in compute minutes, and its formula is published: job duration in seconds divided by 60, multiplied by a cost factor. The default Linux runner has a cost factor of 1; a four-core runner has a cost factor of 2, and a 32-core runner has a cost factor of 12.

GitHub sells the same ladder as separate SKUs with their own rates: $0.006 a minute for Linux at 2 vCPU, then $0.012, $0.022, $0.042 and $0.082 as the core count doubles. Nothing is multiplied; the rate is the rate.

Which of those is cheaper depends on where you are relative to your included quota, and the two quotas are very different sizes. Every figure below was read from GitLab's compute minutes documentation, the GitLab pricing page, GitLab's hosted runner documentation and GitHub's billing and limits references on 21 September 2026.

## Comparison

|  | GitHub Actions | GitLab CI |
| --- | --- | --- |
| How usage is measured | Runner minutes, rounded up to the whole minute per job | Compute minutes: **job duration / 60 multiplied by a cost factor** set by runner type and machine size |
| Included allowance | 2,000 minutes a month on Free, 3,000 on Team, 50,000 on Enterprise Cloud | 400 compute minutes a month on Free, 10,000 on Premium, 50,000 on Ultimate |
| Cost of the next minute | $0.006 at 2 vCPU Linux, rising by SKU to $0.082 at 32 cores | **$10 per 1,000 compute minutes**, which is a cent a compute minute before the cost factor is applied |
| Bigger machines | Larger runners are available on Team and Enterprise Cloud only, and included minutes cannot be spent on them | The large, xlarge and 2xlarge Linux runners are available on Premium and Ultimate only |
| Open source terms | Standard GitHub-hosted runners are free and unlimited on public repositories | A cost factor of 0.5 for public projects in the GitLab for Open Source program, and 0.008 for public forks of them, which is one compute minute per 125 minutes of job time |
| Getting onto the free tier | Nothing to do | Credit or debit card verification is required to use GitLab.com shared runners, which GitLab attributes to abuse of free minutes for cryptocurrency mining. Not required if you bring your own runner |
| Self-managed execution | Self-hosted runners, or a managed vendor at $0.0025 a minute for 2 vCPU | GitLab Runner with ten executors, including Docker, Kubernetes, Instance and Docker Autoscaler. Execution on your own runners does not consume compute minutes |
| Config | `.github/workflows/*.yml`, one file per workflow | `.gitlab-ci.yml`, with `include` for composition |
| Self-healing or retries | None on GitHub-hosted runners; transient failures diagnosed and retried inside the run on Latchkey | Declarative `retry` on a job, which reruns it from the start |
| Setup change required | A file in the repository | A file in the repository, plus a card on file or your own runner |

## The same ladder, priced two ways

Put GitLab's cost factors against GitHub's rate card at matched core counts and the pattern is consistent. GitLab charges a cent per compute minute for additional minutes, so multiply the cost factor by one cent to get the cost of a job minute at that size.

| Size | GitLab runner and specs | Cost factor | GitLab per job minute | GitHub SKU | GitHub rate |
| --- | --- | --- | --- | --- | --- |
| 2 vCPU | `saas-linux-small-amd64`, 8 GB, 30 GB | 1 | $0.01 | Linux 2-core (x64) | **$0.006** |
| 4 vCPU | `saas-linux-medium-amd64`, 16 GB, 50 GB | 2 | $0.02 | Linux 4-core | **$0.012** |
| 8 vCPU | `saas-linux-large-amd64`, 32 GB, 100 GB | 3 | $0.03 | Linux 8-core | **$0.022** |
| 16 vCPU | `saas-linux-xlarge-amd64`, 64 GB, 200 GB | 6 | $0.06 | Linux 16-core | **$0.042** |
| 32 vCPU | `saas-linux-2xlarge-amd64`, 128 GB, 200 GB | 12 | $0.12 | Linux 32-core | **$0.082** |

GitLab's figure sits above GitHub's at every rung: 67% higher at the bottom two sizes, and 36% to 46% higher from eight cores up. That is the marginal rate, and it is the number that matters once a quota is spent. It is not the whole bill, and a page that stopped here would be making exactly the mistake this hub is being rebuilt to correct.

The balancing fact is the quota itself. GitLab Premium includes 10,000 compute minutes a month against GitHub Team's 3,000, and the extra 7,000 are worth more than the rate difference until the volume gets large. Set the two overage curves equal on the default 2 vCPU runner and they cross at about 20,500 job minutes a month: below that, GitLab Premium's compute is the cheaper side despite the higher rate, and above it GitHub Team is, by a margin that widens with every minute. That comparison is metered compute only and excludes the per-seat subscription each quota arrives with, which is a separate decision on both sides.

One more line changes the answer for maintainers, and it goes the other way from everything above. Standard GitHub-hosted runners are free and unlimited on public repositories. GitLab's equivalent is a discount rather than a waiver: a 0.5 cost factor for public projects accepted into its Open Source program, and 0.008 for public forks of those projects.

## Speed

Not benchmarked yet. Both vendors publish machine specifications rather than timings, and the specifications line up closely enough at each rung that a difference would come from the image and the cache rather than the platform.

The one thing the documentation does settle is which sizes you can reach. GitLab gates its large, xlarge and 2xlarge Linux runners to Premium and Ultimate; GitHub gates larger runners to Team and Enterprise Cloud and states that included minutes cannot be used for them. On both platforms the fastest machines are behind a plan, and on both the honest first move is caching rather than cores.

## Where the bill actually goes, and what to do about it

On GitLab the cost factor makes machine size an unusually expensive decision, because it is multiplicative rather than additive: moving a job from the default runner to the 2xlarge multiplies its compute minutes by twelve, and that job has to finish in a twelfth of the time to break even. On GitHub the equivalent move multiplies the rate by about 13.7 from $0.006 to $0.082, so the arithmetic is similar in shape and the warning is the same. A job that does not parallelize gets no faster on a bigger machine, and both platforms will happily sell you the machine.

Execution on your own runners consumes no compute minutes on GitLab, which is the documented escape hatch and the reason GitLab Runner ships ten executors. The same escape hatch exists on GitHub through self-hosted runners, and a middle option exists there that GitLab has no real equivalent for: a managed vendor that keeps the machines but is adopted with a `runs-on` label, at $0.0025 a minute for 2 vCPU against GitHub's $0.006.

## Why there is no recorded run on this page

Every number here is a rate, a quota or a multiplier, and all of them are published on pages that carry a date. A recorded run would contribute one job duration, and job duration is the single input the reader already has from their own pipeline history: put your own number into the formula and the answer is exact for you rather than approximate from our workload. The three source pages are linked below.

## When each one is right

- **Stay where the code is.** Neither platform is enough better at CI to justify moving repositories, and the integration each has with its own host is most of what you are buying.
- **GitLab CI** if you are under roughly 20,500 job minutes a month on the default runner and already paying for Premium, because the 10,000 included compute minutes absorb it.
- **GitHub Actions** at high volume, where the flat rate at every size is below GitLab's cost-factor equivalent, and for anything public, where standard runners are free and unlimited.
- **Your own runners on either**, once metered minutes dominate the bill and the machines would run hot. On GitLab that means GitLab Runner; on GitHub it can mean a managed vendor instead, which is a label rather than infrastructure.

## The verdict

These two are close enough on capability that the choice should follow the repositories, and the cost comparison should be done with your own volume rather than with a vendor's example. If you want the short version: GitLab includes more minutes and charges more for the next one, GitHub includes fewer and charges less, and on the default 2 vCPU runner the two overage curves cross around 20,500 job minutes a month. Below that GitLab Premium is the cheaper compute, above it GitHub is, and for public repositories GitHub is free while GitLab is discounted. If you are on GitHub Actions and the minutes bill is what sent you looking at GitLab, changing the runner is a one-line experiment and migrating a platform is not.

## FAQ

### How are GitLab compute minutes calculated?

Job duration in seconds divided by 60, multiplied by a cost factor. The cost factor comes from the runner type and machine size: 1 for the default small Linux runner, 2 for medium, 3 for large, 6 for xlarge and 12 for 2xlarge, with separate factors for Arm64, GPU, macOS and Windows runners. The result is added to the top-level namespace that owns the project.

### Is GitLab CI cheaper than GitHub Actions?

Per minute, no: additional GitLab compute is $10 per 1,000 compute minutes, which works out to $0.01 a job minute on the default runner against GitHub's $0.006 for the same 2 vCPU size. Per month it depends on the quota. GitLab Premium includes 10,000 compute minutes against GitHub Team's 3,000, so the curves cross at around 20,500 job minutes.

### Why does GitLab ask for a credit card for free CI?

GitLab says credit or debit card details are required to use GitLab.com shared runners because of a large increase in abuse of free compute minutes to mine cryptocurrency. The card is verified with a one dollar authorization that is not charged, and it is not required if you bring your own runner or disable shared runners.

### Do self-managed GitLab runners use compute minutes?

No. GitLab states that execution on your own runners does not use your compute minutes and is unlimited, which is why GitLab Runner ships executors for Docker, Kubernetes, Instance, Docker Autoscaler, Shell and several others. The equivalent on GitHub is a self-hosted runner, or a managed vendor that keeps the machines but is adopted with a label.

## References

- [GitLab docs: compute minutes, the usage formula and the cost factor table](https://docs.gitlab.com/ci/pipelines/compute_minutes/)
- [GitLab docs: hosted runners for Linux and their machine sizes](https://docs.gitlab.com/ci/runners/hosted_runners/linux/)
- [GitLab pricing, read for the tier quotas and the additional compute price](https://about.gitlab.com/pricing/)
- [GitHub Actions runner pricing, read for every rate quoted here](https://docs.github.com/en/billing/reference/actions-runner-pricing)
- [GitHub Actions limits, read for the included minutes by plan](https://docs.github.com/en/actions/reference/limits)

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt