GitHub Actions vs GitLab CI vs Jenkins (2026): Pricing, Runners, Security

Every few months someone asks me to settle GitHub Actions vs GitLab CI vs Jenkins for their team, usually right after a Jenkins upgrade went sideways or a GitHub invoice surprised finance. My answer used to be one sentence: use the CI that lives next to your code. In 2026 that is still the right default, but the numbers around it moved. GitHub cut hosted-runner prices on 1 January after backing away from a charge on self-hosted runners, Jenkins started requiring Java 21, GitLab shipped 19.5, and the extension ecosystems (actions and plugins) became the usual way CI gets breached. This post compares the three, plus CircleCI and Buildkite, on price per minute, runners, security model and real usage, and ends with what a migration actually involves.

GitHub Actions vs GitLab CI vs Jenkins: who uses what in 2026

The most useful recent usage data is JetBrains' State of CI/CD in 2026, built on a 598-person CI/CD tools survey plus context from its 21,946-respondent Developer Ecosystem Survey. Asked which tools their organisation uses, 47 percent named GitHub Actions (up from 41 percent in 2025), 32 percent GitLab CI (down from 34), 28 percent Jenkins (down from 31), 15 percent Azure DevOps Server and 10 percent TeamCity. Two caveats before anyone pastes this into a slide: it is multi-select, so the shares add up to more than 100, and JetBrains sells TeamCity, so read that 10 percent with an eyebrow raised. The 2025 edition also found 62 percent using GitHub Actions for personal projects, which is usually where enterprise adoption comes from a few years later.

Two other findings matter more than the ranking. First, 72.8 percent of Developer Ecosystem respondents run their primary CI/CD system on their own premises or on self-managed cloud instances; on-premises alone reached 30.5 percent, a five-year high, and fully managed CI sits at 24.4 percent. Second, organisations rarely run one tool. The share running two fell from 33 to 25 percent while three or more rose from 12 to 17 percent, and the 2025 respondents said why: half-finished migrations, Jenkins estates nobody wants to touch, and consultancies that use whatever the client's Git host provides.

So "Jenkins is dead" is wrong, and so is "Jenkins is fine". It lost three points in a year while still running in more than a quarter of organisations: a tool people are leaving slowly.

How much does CI cost per minute in 2026?

For a small Linux runner the SaaS options cluster tightly. The table uses each vendor's standard 2-vCPU hosted Linux machine at list price on 31 October 2026.

Platform	Standard hosted Linux	Price per minute	Included each month	Your own runners	Source
GitHub Actions	2 vCPU, 8 GB (private repos)	$0.006	2,000 min Free, 3,000 Team, 50,000 Enterprise	Free; a $0.002 charge is postponed	Pricing, billing
GitLab.com	small, 2 vCPU, 8 GB	$0.010 ($10 per 1,000)	400 Free, 10,000 Premium ($29/user), 50,000 Ultimate	Quota measured on instance runners	Pricing, cost factors
CircleCI	Docker medium, 2 vCPU, 4 GB	$0.006 (10 credits)	30,000 credits (3,000 medium min)	5 concurrent Free, 20 Performance	Price list, plans
Buildkite	hosted Small, 2 vCPU	$0.008 (Pro, $30/user)	2,000 vCPU-min Free, 4,000 Pro	10 agents on Pro, then $3.50 per agent a month	Pricing
Jenkins	none	no meter	n/a	everything is self-hosted	Jenkins

GitHub's pricing notice cut hosted-runner rates by up to 39 percent from 1 January 2026, with a new $0.002 per minute "Actions cloud platform charge" folded into the lower rates, and claimed 96 percent of customers would see no change. It also proposed charging that $0.002 on self-hosted minutes in private repositories from 1 March 2026. On 15 December 2025 GitHub postponed that part "to re-evaluate our approach", and the billing docs still say self-hosted usage is free. There is no new date. I would budget as if it returns: 500,000 self-hosted minutes a month would be $1,000. Public repositories stay free on standard runners; GitHub says they used 11.5 billion minutes in 2025, roughly $184 million at list price.

GitLab bills compute minutes: duration multiplied by a cost factor of 1 for the default small Linux runner, 2 for medium, up to 12 for the 32-vCPU 2xlarge and the M2 Pro macOS runner. Extra minutes cost $10 per 1,000, so a small-runner minute is a cent once the quota is gone. The quota is measured on instance runners (on GitLab.com, the hosted fleet), so runners you register to your own groups sit outside it. Premium includes 10,000 minutes per namespace against GitHub Team's 3,000, at $29 a seat against $4.

CircleCI sells credits: a Docker medium burns 10 a minute at $15 per 25,000, so $0.006, the same as GitHub. Buildkite charges per active user and per self-hosted agent, which rewards teams that run a lot of compute per engineer. Jenkins has no meter, which is not the same as free: you pay for the controller, the agents, the backups and whoever patches them. If CI spend is creeping, my caching guide covers the cheap wins before you change vendors.

Runners: hosted VMs, Kubernetes, and who patches the machine

The runner is where the real differences live, because it is where your code and secrets execute. GitHub-hosted runners are a fresh VM per job; on private repositories ubuntu-latest gets 2 vCPU, 8 GB and a 14 GB SSD, and public repositories get 4 vCPU and 16 GB. That label is moving: GitHub is migrating ubuntu-latest from Ubuntu 24.04 to 26.04 between 19 October and 19 November 2026, so pin ubuntu-24.04 if your build is fragile. Self-hosted runners on Kubernetes go through Actions Runner Controller (ARC), whose 0.15.1 release shipped on 23 October 2026. GitHub Enterprise Cloud now enforces runner version 2.329.0 or newer to register, from 29 September 2026, and runners below the runtime minimum stop picking up jobs.

GitLab Runner follows GitLab's monthly cadence (19.5.0 on 15 October 2026) with Docker, Kubernetes, shell and autoscaling executors; the hosted Linux fleet spans 2 to 32 vCPUs, sizes above medium on Premium and Ultimate only.

Jenkins is a controller plus agents, which many teams now run as pods through the Kubernetes plugin. The controller is the part that costs you. Jenkins 2.555.1 (15 April 2026) dropped Java 17, so every LTS since needs Java 21 or 25, and the 2.580 line (2.580.2, a 28 October security release, is current) stopped bundling the JUnit, Mailer and SSH server plugins. Neither change is hard; both are what a team that ignored Jenkins for two years discovers mid-incident.

Ephemeral runners are the problem I work on at PandaStack, my company, which runs untrusted code in Firecracker microVMs: one job, one fresh machine, nothing carried over. GitHub-hosted runners do that by default; a long-lived Jenkins agent does not, and fixing that comes first when you self-host any of these.

Is GitHub Actions more secure than Jenkins?

Self-hosted CI servers get breached through the server; SaaS CI gets breached through its ecosystem and occasionally its vendor. CISA's Known Exploited Vulnerabilities catalog, which lists only bugs with evidence of real-world exploitation, shows the pattern when I filter its JSON feed (the 30 October 2026 edition) for CI products:

Product	KEV entries	Most recent addition	Notable entry
Jenkins (core and plugins)	6	CVE-2017-1000353, added 2 Oct 2025	CVE-2024-23897, CLI path traversal
GitLab CE/EE	6	CVE-2026-97229, added 29 Oct 2026	CVE-2023-7028, improper access control
JetBrains TeamCity	4	CVE-2026-63077, added 5 Aug 2026	CVE-2024-27198, authentication bypass
GitHub Actions (third-party actions)	2	CVE-2025-30154, added 24 Mar 2025	CVE-2025-30066, tj-actions/changed-files
CircleCI, Buildkite	0	none	none

Jenkins' attack surface is its plugins and its Groovy. The update centre metadata lists 2,128 plugins and carries 1,512 plugin security warnings across 767 of them, 95 pointing at 2026 advisories. Even the Groovy sandbox is a plugin (Script Security), and one of its bypasses, CVE-2019-1003029, is in KEV. GitLab self-managed is the same story with one vendor: run either yourself and you own the patch window.

GitHub's weak point is third-party actions. In March 2025 the attacker behind CVE-2025-30066 repointed tj-actions/changed-files version tags at code that leaked CI secrets into build logs, and GitHub's 2026 security roadmap, published 26 March, cites it alongside the Nx and trivy-action incidents. The fixes are now shipping: an organisation policy to require full-SHA pinning (August 2025), actions/checkout v7 refusing fork code in pull_request_target workflows (June 2026, backported to older majors on 20 July), workflow execution protections generally available since 17 September, and workflow lockfiles, generally available since 28 October, which record transitive action commits in .github/workflows/actions.lock. A native egress firewall for hosted runners is still on the roadmap. I went through the tag-hijacking problem in detail in GitHub Actions Security in 2026.

The vendor belongs in your threat model too. CircleCI's January 2023 incident began with malware stealing an engineer's SSO session and ended with every customer told to rotate every stored secret. That is the argument for OIDC over stored cloud keys anywhere. GitHub issues short-lived OIDC tokens natively, GitLab does through id_tokens, and Jenkins can through the OpenID Connect Provider plugin. My workload identity federation explainer covers how the trust works.

The same pipeline in GitHub Actions, GitLab CI and Jenkins

The syntax differences are smaller than the marketing suggests. One Maven build in all three, versions pinned:

# .github/workflows/ci.yml (GitHub Actions)
name: ci
on: [push, pull_request]
permissions:
  contents: read              # GITHUB_TOKEN can read the repo and nothing else
jobs:
  test:
    runs-on: ubuntu-24.04     # pinned: ubuntu-latest moves to 26.04 by 19 Nov 2026
    container: maven:3.10.0-eclipse-temurin-21
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - run: mvn -B -ntp verify

# .gitlab-ci.yml (GitLab CI; runs on every push by default)
test:
  image: maven:3.10.0-eclipse-temurin-21
  timeout: 20m
  script:
    - mvn -B -ntp verify

// Jenkinsfile (declarative; the docker agent needs the Docker Pipeline plugin)
pipeline {
  agent { docker { image 'maven:3.10.0-eclipse-temurin-21' } }
  options { timeout(time: 20, unit: 'MINUTES') }
  stages {
    stage('Test') {
      steps { sh 'mvn -B -ntp verify' }
    }
  }
}

Three differences matter. GitHub makes you think about the token: permissions scopes GITHUB_TOKEN, and the SHA pin stops a moved tag from changing your build. GitLab's image effectively is the job, so the runner configuration is the interesting part. Jenkins needs the Docker Pipeline plugin for that one agent line, and every capability beyond sh is another plugin with its own release cycle and its own advisories, which is the whole Jenkins bargain in a sentence.

Should you migrate from Jenkins to GitHub Actions or GitLab CI?

Probably, eventually, and not in one go. GitHub's Actions Importer converts from Jenkins, GitLab, CircleCI, Azure DevOps, Bamboo, Bitbucket and Travis CI, and its audit and forecast commands are worth running even if you never migrate: they show how much of your estate is declarative, which plugins you lean on, and how many concurrent runners you would need. What it will not convert is listed plainly in the Jenkins migration docs: scripted pipelines, secrets, self-hosted runners, mandatory build tools and unknown plugins. In my experience that list is most of the work. GitLab has its own Jenkins migration guide if your code lives there. I wrote the full sequence up, from inventory to ARC runners, in How to Migrate Jenkins to GitHub Actions.

Leaving Jenkins trades a server you patch for a vendor you trust, and shared libraries for reusable workflows that need their own versioning. If CI volume is high and machines are cheap to you, self-hosted runners on any of these platforms stay cheaper than hosted minutes; the JetBrains self-hosting numbers suggest most organisations did that sum already. Agents opening pull requests add another reason to watch the meter, as I covered in CI/CD when agents open the pull requests.

Which CI/CD tool should you choose in 2026?

My rules are short. Code on GitHub: use GitHub Actions, and turn on SHA pinning on day one. Code on GitLab, or you want source control, CI, registry and scanning in one self-managed product: use GitLab CI and budget for patching. A large Jenkins estate that works: keep it while new repositories start elsewhere, and upgrade to 2.580.2 on Java 21 and prune plugins now. CircleCI makes sense when you want CI decoupled from your Git host at GitHub-level prices. Buildkite fits large self-hosted fleets where a SaaS control plane over your own agents is the point, because it charges per person and per agent rather than per minute on your hardware.

FAQ

Is Jenkins still used in 2026?

Yes. JetBrains' 2026 survey found Jenkins in 28 percent of organisations, down from 31 percent a year earlier, and the project shipped LTS 2.580.2 on 28 October 2026. It is declining slowly, not disappearing.

Are GitHub Actions self-hosted runners free in 2026?

Yes, as of October 2026. GitHub proposed a $0.002 per minute platform charge for self-hosted runners in private repositories from 1 March 2026, then postponed it on 15 December 2025 with no new date, and its billing docs still list self-hosted usage as free. Public repositories are free on standard hosted runners too.

Is GitLab CI cheaper than GitHub Actions?

Per hosted minute, no: GitLab's small Linux runner works out to $0.010 a minute in add-on minutes against GitHub's $0.006. GitLab Premium includes more minutes (10,000 against 3,000 on GitHub Team) but costs $29 a user against $4. For most teams the seat price decides it, not the minutes.

What is the best alternative to Jenkins?

The CI system attached to your Git host, in most cases: GitHub Actions for GitHub, GitLab CI for GitLab. Teams with large self-hosted fleets should also look at Buildkite, and teams that want CI independent of their Git host at similar per-minute prices should look at CircleCI.

This quarter, on Jenkins, I would upgrade to 2.580.2 on Java 21, delete every plugin nobody can name an owner for, and run gh actions-importer audit against the controller to see the shape of a migration, even with no plan to start one. On GitHub Actions, I would turn on the SHA-pinning policy, try lockfiles on one repository, pin ubuntu-24.04 until the 19 November migration settles, and keep a budget line for the self-hosted charge in case it returns. The tool matters less than the discipline around it: ephemeral runners, pinned dependencies, short-lived credentials and someone who owns the upgrades.

Related: GitHub Actions Security in 2026: 76 Hijacked Tags and the Fixes That Work, How to Use GitHub Actions OIDC With AWS, GCP and Azure (2026) and How to Speed Up GitHub Actions CI: Caching, Sharding, Docker (2026).