GitHub Actions vs GitLab CI: what 200,000 build minutes a month costs

Where the minutes actually go

GitHub measures a job by its processing time, so the cheapest fix is usually fewer minutes rather than a cheaper minute. A workflow that generates a 10 MB artifact consumes 10 minutes of the owner's allowance and 10 MB of the artifact allowance. Log files and long job summaries do not count against artifact storage, which makes verbose logging cheaper than verbose artifacts.

Storage is the second bill and it behaves unlike minutes. GitHub accrues artifact and Packages storage hourly in GB-Hours, and deleting artifacts stops future charges without removing what has already accrued. Its worked example stores 10 GB for ten days and deletes on day eleven: the bill still shows 2,400 GB-Hours. A team that clears artifacts at the end of a sprint has already paid for the sprint.

Cache storage is measured by peak usage per hour and carries a separate 10 GB per repository. A repository peaking at 15 GB in an hour is charged for 5 GB, and only if the configured cache limit sits above the included amount. Custom image storage for larger runners has its own allowance, 150 GB on Enterprise Cloud, and each retained image version keeps contributing until it is deleted or a retention policy removes it.

Larger runners are always charged, even on public repositories and even when plan quota remains. That is the one line where a public repository does not escape the bill, and it is worth knowing before a team moves heavy builds onto bigger machines to cut wall-clock time.

What GitLab bundles into the seat

GitLab's published numbers are seat prices, not minute prices. Premium is $12 per user per month and Ultimate $24, both with included GitLab Credits to access AI features, and the credits are described as a promotional offer available for a limited time. For 50 engineers that is $600 and $1,200 a month respectively before any usage charge, which is the comparable figure to GitHub's per-seat Enterprise pricing rather than to its minute rate.

GitLab also sells add-ons aimed at teams that exhaust included minutes: additional compute minutes for pipelines that regularly run out, and more storage for large repositories, LFS files and build artifacts when a group namespace hits its limit. The pages provided name both without a price. A buyer comparing the two should ask GitLab for the per-minute rate and the storage rate, because without them the 200,000-minute comparison cannot be completed on published figures.

The licensing mechanics differ in a way that affects the true-up. GitLab charges added users prorated from the purchase date through the end of the term, and with quarterly subscription reconciliation, the default for new and renewing subscriptions after 1 August 2021, users added mid-quarter are charged only for the remaining quarters. Without it, add-on users are charged annual true-ups for the full term. A team that grows through the year should confirm which model its contract carries.

GitLab's own FAQ states that all users in a GitLab.com group or on a self-managed instance must be on the same plan. That removes the mixed-tier arithmetic some buyers assume, and it means the seat count that drives the bill is the whole group, not the subset running pipelines.

The self-hosted escape hatch, and what it costs instead

GitHub Actions is free for self-hosted runners. That single line changes the arithmetic for a 200,000-minute estate: the per-minute charge disappears and the cost moves to the compute the team runs the runners on, which GitHub does not bill. For a team already carrying spare capacity or a committed cloud spend, this is often the cheapest route past the 50,000-minute allowance.

The trade is operational. Self-hosted runners are infrastructure the team patches, scales and secures, and GitHub's billing documentation treats them as outside the minute model rather than as a managed service. A team without platform engineers to spare should price that labour before assuming self-hosting undercuts the overage.

GitLab offers the same split in a different shape. GitLab.com is cloud-hosted by the vendor, while a self-managed instance is maintained by the customer with full control of data and infrastructure, and a single-tenant SaaS option is fully managed. The compute-minute economics of each are not published on the pages provided, so the self-managed route has to be quoted rather than calculated.

The decision here is not which vendor is cheaper per minute. It is whether the team wants to own runner capacity at all. A team that already runs Kubernetes or a build fleet has a marginal cost near zero for self-hosted runners; a team that does not is buying a new operational surface to avoid a bill it has not yet measured.

Storage, artifacts and the limits that bite later

GitHub's artifact allowance is shared with GitHub Packages, so the 50 GB on Enterprise Cloud covers both and the two cannot be spent separately. Cache storage and custom image storage sit outside that pool with their own allowances. A team that assumes three separate 50 GB buckets will find one shared ceiling and a bill for the difference.

Git LFS is a separate limit again. GitHub caps the maximum file size at 2 GB on Free and Pro, 4 GB on Team and 5 GB on Enterprise Cloud, and a file above the per-file limit is rejected with an error. Large binaries that pass through LFS are stored as pointer files in the repository, with the object held elsewhere, which keeps clones small but does not make the storage free.

GitLab sells storage expansion as an add-on when a group namespace hits its limit, again without a published rate on the pages provided. The practical question for both vendors is the same: what does a gigabyte-month of artifact storage cost above the included amount, and does deleting an artifact stop the charge or only stop the next hour of it. GitHub's answer is documented and unhelpful to the careless: accrued GB-Hours stay on the bill.

The decision rule for a 50-engineer team

Choose GitHub Actions with self-hosted runners if the team already runs compute it can dedicate to builds, because the minutes are free on self-hosted runners and the 50,000-minute Enterprise Cloud allowance stops being the constraint. Choose GitHub-hosted runners and pay the overage if the team values not operating a build fleet and can get the per-runner-size minute rates in writing before signing, since that rate is what turns 150,000 minutes into a number.

Choose GitLab if the seat bundle is what the team is buying: $12 per user per month for Premium or $24 for Ultimate with included credits, one plan for every user in the group, and add-on compute minutes for the pipelines that outrun the allowance. Ask GitLab for the per-minute and per-gigabyte rates before comparing, because the pages provided publish neither and the comparison is incomplete without them.

Wait if the 200,000 minutes are mostly public-repository builds on standard runners, which are free on GitHub and make the whole question moot, or if the estate is small enough that 50,000 included minutes cover it. The number to settle first is not the vendor's rate but the team's own monthly minute count, split between private and public repositories and between hosted and self-hosted runners.