Picking free CI/CD in 2026 is harder than the minute counts suggest
I compared six CI/CD options with a real free or no-cost entry path: GitHub Actions, GitLab CI/CD, CircleCI, Buildkite, Woodpecker, and Codefresh. The Reddit-style “just use GitHub Actions, public repos are free” answers mostly ignore that these products do not meter the same unit, and that monorepos often hit concurrency walls before they run out of minutes.
My default for a public open-source repo is still GitHub Actions. Standard hosted runners on public repositories are free and unlimited, including macOS on standard runners, with up to 20 concurrent jobs total and 5 concurrent macOS jobs on GitHub Free. That is hard to beat if your code already lives on GitHub.
The catch shows up fast on private repos and fat pipelines. GitHub Free private repos get only 2,000 minutes/month, 500 MB artifact storage, and 10 GB cache. A polyglot monorepo can hit 20 concurrent jobs, the 5-macOS ceiling, 256 matrix jobs per workflow run, or 500 queued workflow runs per 10 seconds long before the minute counter becomes the bottleneck. Community reports also describe sudden usage spikes triggering queueing or automated abuse review that disables Actions until support clears it. I would not treat “public repo = infinite free CI” as a release-critical assumption without a fallback.
I prioritized official docs, pricing pages, and changelogs from mid-2026, then checked recent community reports for queueing, shared-IP throttling, and self-hosted hardware anecdotes. Where docs conflict, I call it out instead of guessing.
You cannot compare these on minutes alone
Vendors bill minutes, credits, or your own ops time. Pick the wrong mental model and you will mis-budget.
| Mental model | Tools | What burns quota |
|---|---|---|
| Hosted minutes | GitHub Actions, GitLab CI/CD | Runner time, with cost multipliers on non-Linux runners |
| Credits | CircleCI | Resource class and executor type, not a fixed minute rate |
| Hybrid agents | Buildkite | Hosted Linux minutes on Personal; agent fleet on self-hosted |
| Ops labor | Woodpecker self-hosted | Server, DB, runners, backups, artifact storage |
| Opaque account billing | Codefresh | Runtime environments; free hosted allowance not published |
Private repo with modest Linux CI? Minutes math matters. Linux-heavy OSS project? CircleCI credits can dwarf GitHub’s private allowance. Team with platform engineers? Woodpecker’s $0 software bill trades for capex and maintenance. Evaluating Codefresh on a free-tier spreadsheet is mostly guesswork.
You will not get a perfect apples-to-apples table. Use the numbers below as directional, then run your actual pipeline matrix against the provider you are leaning toward.
Free tiers at a glance
| Option | Free hosted allotment | Concurrent jobs | macOS on free | Secrets limits | Artifacts and cache | Retention defaults | Quota scope | Monorepo caveat |
|---|---|---|---|---|---|---|---|---|
| GitHub Actions | Public repos: standard hosted runners free and unlimited. Private GitHub Free: 2,000 min/mo, 500 MB artifacts, 10 GB cache. | 20 total on Free; 5 max macOS. | Yes on standard runners. | 1,000 org, 100 repo, 100 environment secrets; 48 KB each. | Cache API: 200 uploads/min, 1,500 downloads/min, 400 deletes/min per repo. | Artifacts/logs: 90 days. Cache: 7 days. | Minutes and concurrency are plan/account scoped; cache is per repo. | 256 matrix jobs/workflow, 500 queued runs/10 s, 100 queued by concurrency group. |
| GitLab CI/CD Free | 400 compute min/mo per namespace. Cost factors: Linux small 1x; macOS M1 medium 6x; macOS M2 Pro large 12x. OSS program: 50,000 min/mo. | No single public concurrency number for Free; 500 jobs/pipeline and 500 jobs in active pipelines. | Yes, beta. | 8,000 project vars, 30,000 group vars; 10,000 chars each. | Artifacts max 1 GB compressed. Cache upload max 5 GB compressed. | Artifacts: 30 days. Hosted cache stale after 14 days without updates. | Minutes are per namespace, shared across repos. | 400 minutes vanishes on macOS; 500-jobs/pipeline is the first hard wall. |
| CircleCI Free | 30,000 credits/mo. OSS on Linux/Arm/Docker: 400,000 credits/mo (~80,000 build minutes). | 30 jobs org-wide. | Yes; burns credits faster. | 100 env vars per context; 100 unique contexts across workflows. | DLC storage 15 GiB/org if used. | Artifacts 30 days; caches/workspaces 15 days. | Credits and concurrency are org scoped. 5 active users on Free. | Credits are non-intuitive; large configs and shared-IP Docker pulls hurt. |
| Buildkite Personal | Free forever. Pricing page: 500 hosted Linux min/mo; limits page: 550 min/mo. No free macOS. 1 active user. | 3 concurrent jobs, hosted and self-hosted combined. | No on Personal. | UI docs: 32 KB values; REST API: <8 KB. Key max 255 chars. | 5,000 artifacts/job, 50 GiB batch/job. Per-file limit conflicts: CLI 5 GB vs limits page 10 GiB. | Builds 90 days; artifacts 180 days; cache volumes 14 days from last use. | Per-org/account; steep cliff at 1 user / 3 jobs. | Too small once parallel tests start. |
| Woodpecker self-hosted | $0 software; you provide compute. | Agent count + backend capacity. | Only if you provide macOS agents. | Repo / org / global scopes; no public numeric limits found. | No native managed artifact store; cross-workflow needs S3/WebDAV plugin. | Backend-defined; no built-in archival. | Your infra sets the ceiling. | “Free” ends when you price servers, backups, and artifact storage. |
| Codefresh | No clean public free hosted allowance. Cloud Build/SaaS runtime not enabled by default; requires approval. | Account-specific; visible in Billing. 1,000 delayed builds max; 7-day delayed-build expiry. | No public first-party macOS runner found. | Secret-store integrations exist; no public count/size limits found. | Build logs max 100 MB/build, 20 MB/step. SaaS runtime: 1 / 4 / 8 GB RAM. | Public retention numbers not clearly documented. | Account and pipeline policies govern parallelism. | Hard to plan; “free” becomes ask support / enable runtime / inspect Billing. |
GitHub’s billing docs still describe self-hosted runners as free, but GitHub’s December 2025 changelog announced a $0.002/minute cloud-platform charge for self-hosted runner usage effective March 1, 2026. Treat that contradiction as a planning risk, not a footnote.
What the free tiers actually cost you later
GitHub Actions: best OSS default, sharp private limits
GitHub Actions has the strongest free story for public repositories. Standard hosted runners are unlimited, macOS is available on the free tier, and the developer experience is already wired into where your code lives.
Private repos are a different product. Two thousand minutes per month sounds generous until you multiply it across a team shipping daily. Artifact storage at 500 MB fills up with test reports and build outputs faster than people expect.
Monorepo pain shows up in orchestration, not billing. Twenty concurrent jobs total. Five macOS jobs. Two hundred fifty-six matrix jobs per workflow. Queue burst limits. A large JavaScript or polyglot monorepo can hit those ceilings while still showing plenty of minutes left on the dashboard.
The operational risk I keep seeing in community threads is abuse and fairness enforcement. GitHub’s limits page acknowledges rate limiting at scale. Reports of Actions getting disabled pending manual review after unusual spikes are common enough that I would keep a backup path for release-critical jobs, even on public repos.
Self-hosted runners add another wrinkle for 2026. Docs still say usage is free; the changelog says otherwise from March 2026. Re-check billing before you scale a self-hosted fleet.
GitLab CI/CD: tight on ordinary Free, generous only with OSS program
GitLab CI/CD Free is feature-rich but economically sharp. Four hundred compute minutes per month sounds simple until you notice they are per namespace, shared across every repo in that namespace, and billed with cost factors that make macOS runs 6x or 12x more expensive than Linux small.
That turns the headline number into a Linux-small allowance, not a cross-platform one. Need macOS builds on ordinary Free? You will burn through the pool fast. GitLab also caps projects at 500 jobs in a single pipeline and 500 jobs in active pipelines. Monorepos hit that wall predictably, which is almost refreshing compared to GitHub’s softer queue limits, but it still hurts.
GitLab’s real free play is the Open Source program: 50,000 compute minutes per month and hundreds of concurrent jobs on GitLab.com for eligible projects. That is a different class of offering from ordinary Free. Without qualification, GitLab Free fits teams already on GitLab with modest Linux demand. macOS and Windows hosted runners are still marked beta with no SLA on beta images.
CircleCI: raw Linux OSS compute, confusing credits
CircleCI Free is the most generous Linux-heavy OSS offer in raw public-runner compute, but CircleCI wants you to think in credits, not minutes. Thirty thousand credits per month on the ordinary Free plan. Eligible open-source organizations on Linux, Arm, and Docker can get 400,000 credits per month, which CircleCI equates to about 80,000 build minutes. Org-wide hosted concurrency is 30 jobs. Only five active users on Free.
Credits work for mature teams that already model resource classes. They are friction for a small team asking a simple question: will our pipelines fit?
CircleCI’s operational caveats are mostly about shared infrastructure. Support docs warn about Docker Hub rate limiting because jobs share IP pools. The default 10-minute no-output timeout bites long-running steps without log output. Monorepos that accumulate dynamic config and fan-out stages can hit the “compiled config too large” error, which has its own support article. Context limits (100 variables per context, 100 unique contexts across workflows) show up sooner than equivalent limits on GitHub Actions.
Buildkite Personal: honest individual plan, not a team foundation
Buildkite Personal is free forever and clearly aimed at one person: 1 active user, 3 concurrent jobs across hosted and self-hosted execution, Linux hosted minutes only on Personal (no free macOS). The pricing page says 500 hosted Linux minutes per month; the limits page says 550. Secret value limits conflict between UI docs (32 KB) and REST API docs (<8 KB). Per-artifact upload limits conflict between CLI reference (5 GB) and limits page (10 GiB).
Those mismatches matter. They signal a free tier in flux, not a durable team-scale CI foundation.
The product itself is excellent for sophisticated pipelines and dynamic build graphs. Buildkite positions hybrid mode as the real scaling path: SaaS control plane, your agent fleet. Some customers run 100,000+ concurrent agents. Personal still caps you at 3 concurrent jobs total even when self-hosted. Buildkite minimizes control-plane toil; it does not give you a generous free hosted minute pool.
Woodpecker: lowest cash cost, highest ops cost
Woodpecker is open-source CI you run yourself. No vendor minute bill. You own the server, database, runners, TLS, backups, upgrades, and artifact plumbing.
Secrets scope to repo, organization, or global. PR secrets are not exposed by default. External secret integrations cannot be masked the same way as native Woodpecker secrets. Artifacts share within a workflow only; cross-workflow artifact passing needs an external store like S3 or WebDAV via plugins.
Woodpecker’s server docs note no built-in data archival, and database logs can grow the database considerably. The vendor bill is zero. The invoice lands in your time budget.
Teams still do it. One 2026 migration write-up described building a Woodpecker fleet from four mini PCs for about $1,300 total, framing it as ROI against hosted CI spend. That is one anecdote, not a universal formula, but it captures the trade: monthly metering swapped for up-front capex plus ops labor.
Codefresh: skip as a free baseline
Codefresh is hard to recommend as a free CI starting point. Public docs say pipeline execution requires at least one runtime environment. Cloud Build for pipelines is not enabled by default and must be requested. Account creation may be free; builds are not self-evidently free on a published quota.
Concurrency is account-specific and lives in the Billing screen or in account/pipeline policies, not in a public pricing table. Operationally, watch builder queuing: 7-day delayed-build expiry, 1,000 delayed builds account cap, 100 MB total build log limits, 20 MB per-step log limits. SaaS runtime sizes are 1 GB, 4 GB, or 8 GB RAM, with warnings that parallel steps increase memory usage. Fine product if you are already committed to its runner-centric architecture. Poor fit for a free-tier comparison spreadsheet.
Self-hosted: what “free” actually costs
The useful distinction is not hosted vs self-hosted. It is which part of the stack you operate yourself.
With Woodpecker, you self-host everything: control plane, auth, database, runners, artifact path, storage lifecycle. With Buildkite self-hosted, you self-host only the execution fleet. Buildkite’s UI, scheduling, and account management stay SaaS. That makes Buildkite materially lighter to operate than Woodpecker, even when both get called “self-hosted.”
| Cost area | Woodpecker self-hosted | Buildkite self-hosted |
|---|---|---|
| Hardware and capacity | You provide all compute and specialized runners. | You provide agents and queues; Buildkite coordinates the fleet. |
| Maintenance | Highest: server, DB, upgrades, proxying, backups, no built-in archival. | Medium: agent images, autoscaling, OS patching; Buildkite runs the control plane. |
| Security | Full responsibility; PR secrets off by default. | Better perimeter control; external secret managers possible; agents still need hardening. |
| Scaling | Add agents or Kubernetes capacity; cross-workflow artifacts need external storage. | Scale by agent count and queue design; Personal still caps concurrency at 3. |
| Network and storage | Usually S3/WebDAV/Nexus plugins; you pay your cloud provider. | Image pulls, downloads, and artifact transfers leave your VMs either way. |
Woodpecker minimizes vendor spend. Buildkite minimizes control-plane toil. GitHub, GitLab, and CircleCI minimize infra toil but meter you with minutes, credits, or queue ceilings. The cheapest vendor line item is often not the cheapest total cost of ownership.
What I would pick
flowchart TD
start[What is the main constraint?] --> oss{Public OSS repo?}
oss -->|Yes, lowest friction| gh[GitHub Actions]
oss -->|Linux-heavy OSS, credits OK| cci[CircleCI OSS credits]
oss -->|Qualifies for GitLab OSS program| gl[GitLab Open Source program]
oss -->|No| private{Already on GitLab?}
private -->|Yes, mostly Linux| glfree[GitLab Free]
private -->|No| users{Team under 5 active users?}
users -->|Yes, credits acceptable| ccifree[CircleCI Free]
users -->|Yes| ghprivate[GitHub Actions private Free]
users -->|No| paid[Budget for paid tier or self-host]
paid --> infra{Can you operate servers and runners?}
infra -->|Yes, want zero vendor metering| wp[Woodpecker]
infra -->|Yes, want SaaS control plane| bk[Buildkite self-hosted agents]
infra -->|No| gh For small teams with private repos, the low-friction choices are GitHub Actions if you already live in GitHub, GitLab Free if you already live in GitLab and mostly run Linux pipelines, and CircleCI Free if you are under the 5 active-user ceiling and comfortable budgeting in credits. I would not default to Buildkite Personal or Codefresh for private repos unless there is a specific workflow reason. Buildkite Personal is intentionally tiny. Codefresh’s public free-hosted story is too opaque.
For open-source projects, GitHub Actions if you want the simplest hosted path and need macOS on a real free tier. GitLab only if you can qualify for the Open Source program; otherwise 400 minutes per namespace is modest. CircleCI if your workload is strongly Linux-centric and you can use the 400,000-credit OSS allocation. Buildkite’s free path works for showcasing pipelines, not as a serious hosted free OSS CI service once a project grows.
For monorepos without platform-engineering budget, GitHub Actions is the best “good enough” starting point, but optimize aggressively around matrix size, concurrency, and caching. GitLab Free is the least forgiving ordinary free tier for large monorepos because of 500 jobs per pipeline and 400 minutes per namespace. CircleCI can work for large Linux monorepos, but large configs and credit burn add complexity. If monorepo CI is strategically important and you have infrastructure skills, the long-term winners are Buildkite with self-hosted agents or Woodpecker, because those models scale by fleet capacity rather than hosted-free ceilings.
For a bootstrapped side project on GitHub with a public repo, I would ship GitHub Actions on day one, cache aggressively, and keep matrix jobs lean. I would only add CircleCI or a self-hosted runner path once I actually hit a documented limit, not because a comparison table made me anxious.
Gaps in the public docs
CircleCI’s public docs never published a clear hard size cap for project or context secret values. GitLab did not expose a single authoritative hosted-runner concurrency number for ordinary Free namespaces. Codefresh did not publish a clean free-hosted build quota.
Buildkite’s docs conflict on 500 vs 550 free hosted Linux minutes, 32 KB vs <8 KB secret value limits, and 5 GB vs 10 GiB per-artifact upload size. GitHub’s docs and changelog currently disagree on whether self-hosted runner usage is free or subject to a cloud-platform charge from March 2026.
Those are not small footnotes. They are the places where a prudent team should re-check the live product UI or billing page before committing.
Sources
GitHub Actions
About billing for GitHub Actions
Usage limits, billing, and administration
About GitHub-hosted runners
GitHub Changelog
GitLab CI/CD
GitLab pricing
Compute minutes
Hosted runners cost factors
GitLab for Open Source
CircleCI
CircleCI pricing
Open source credit policy
Configuration reference
Docker Hub rate limiting
Buildkite
Buildkite pricing
Pipeline limits
Self-hosted agents
Buildkite Secrets
Woodpecker
Woodpecker documentation
Secrets
Plugins and artifacts
Server administration
Codefresh
Codefresh documentation
Runtime environments
Cloud Build
Concurrency policies