CI/CD-Tools 2026: GitHub Actions, GitLab CI und Jenkins im Praxisvergleich

Für die meisten Teams ist GitHub Actions im Oktober 2026 das passende CI/CD-Tool, solange der Code ohnehin auf GitHub liegt. GitLab CI gewinnt, wenn Self-Hosting, EU-Datenhaltung oder eine einzige Plattform für Code, Pipelines und Registry gefragt sind. Jenkins lohnt sich nur noch mit einer bestehenden, großen Jenkins-Installation.

Hinweis: Links mit Sternchen (*) sind Amazon-Partnerlinks. Kaufst du darüber, erhält bfg-it.de eine Provision, der Preis für dich bleibt gleich.

Welches CI/CD-Tool passt 2026 zu welchem Team?

Das passende CI/CD-Tool hängt 2026 vor allem davon ab, wo der Code liegt. GitHub Actions passt zu Repositories auf GitHub, GitLab CI zu Teams mit Self-Hosting- oder Compliance-Vorgaben, Jenkins zu Unternehmen mit vielen gewachsenen Jobs, deren Migration teurer wäre als der Betrieb.

Die drei Systeme unterscheiden sich weniger in dem, was eine Pipeline kann, als im Betriebsmodell. GitHub Actions ist die in GitHub eingebaute CI/CD-Funktion. Workflows liegen als YAML unter .github/workflows/, Bausteine kommen als wiederverwendbare Actions aus dem Marketplace. GitLab CI/CD ist Teil der GitLab-Plattform und wird über eine einzige .gitlab-ci.yml gesteuert. GitLab lässt sich als SaaS auf gitlab.com nutzen oder komplett selbst betreiben, die aktuelle Version 19.4 erschien am 17. September 2026. Jenkins ist ein Open-Source-Automatisierungsserver in Java. Pipelines stehen als Groovy-Code in einem Jenkinsfile, fast jede Funktion kommt über Plugins.

Aus Admin-Sicht entscheiden drei Fragen: Wer betreibt die Infrastruktur? Wo müssen Daten und Build-Logs liegen? Und wie viel Pflegeaufwand trägt das Team? Die Tabelle übersetzt das in konkrete Empfehlungen.

Wer Infrastruktur ohnehin als Code verwaltet, sollte die Entscheidung mit dem Deployment-Werkzeug abstimmen. Terraform- und OpenTofu-Pläne laufen in allen drei Systemen, die Unterschiede beim State-Handling beschreibt unser Vergleich Infrastructure-as-Code 2026: Terraform, Pulumi und OpenTofu.

Was kosten GitHub Actions, GitLab CI und Jenkins wirklich?

GitHub Actions kostet seit 1. Januar 2026 auf gehosteten Linux-Runnern 0,006 US-Dollar pro Minute nach den Freiminuten. GitLab rechnet Compute-Minuten ab, Premium enthält 10.000 pro Monat für 29 US-Dollar pro Nutzer. Jenkins ist lizenzfrei, die Kosten stecken in Servern und Wartungszeit.

Bei GitHub ist die Abrechnung pro Minute und Betriebssystem gestaffelt. Laut GitHub-Dokumentation (Stand Oktober 2026) kostet ein Linux-Runner mit 2 Kernen 0,006 US-Dollar, Linux auf ARM64 0,005 US-Dollar, Windows 0,010 US-Dollar und macOS 0,062 US-Dollar pro Minute. GitHub rundet jeden Job auf die volle Minute auf. Die Preissenkung zum Jahreswechsel betrug laut GitHub bis zu 39 Prozent. Die ursprünglich für 1. März 2026 angekündigte Plattformgebühr von 0,002 US-Dollar pro Minute auf self-hosted Runnern hat GitHub nach Kritik verschoben, um den Ansatz neu zu bewerten. Einen neuen Termin gibt es bisher nicht.

GitLab arbeitet mit Kostenfaktoren. Ein kleiner Linux-Runner auf gitlab.com hat den Faktor 1, ein mittlerer den Faktor 2, ein großer den Faktor 3. Ein macOS-Runner mit M1 zählt sechsfach. Die Formel aus der GitLab-Doku lautet: Jobdauer in Sekunden geteilt durch 60, multipliziert mit dem Kostenfaktor. Wartezeit in der Queue zählt nicht mit. Zusätzliche Minuten kauft man in Paketen zu 10 US-Dollar pro 1.000 Minuten.

Quellen: GitHub Docs (Actions runner pricing, GitHub Actions billing), github.com/pricing, about.gitlab.com/pricing, GitLab Docs (Compute minutes), jeweils abgerufen am 07.10.2026.

Kostenrechnung für ein Team mit zehn Entwicklern

Nehmen wir ein typisches Produktteam: zehn Entwickler, 1.200 Pipeline-Läufe im Monat, jeder Lauf dauert acht Minuten auf einem kleinen Linux-Runner. Das ergibt 9.600 Build-Minuten. Die Annahmen sind bewusst einfach, damit du deine eigenen Zahlen einsetzen kannst.

GitHub Team: 10 Nutzer mal 4 US-Dollar ergibt 40 US-Dollar. Von den 9.600 Minuten sind 3.000 inklusive, bleiben 6.600 mal 0,006 US-Dollar, also 39,60 US-Dollar. Zusammen rund 80 US-Dollar im Monat.

GitLab Premium: 10 Nutzer mal 29 US-Dollar ergibt 290 US-Dollar. Die 9.600 Minuten passen in das Kontingent von 10.000. Zusammen 290 US-Dollar im Monat. Dafür bekommst du allerdings mehr als CI: Merge-Request-Approvals, Code-Owner-Regeln und Support. Der Vergleich ist also nur fair, wenn du diese Funktionen tatsächlich brauchst.

Jenkins: Die Lizenz kostet nichts. Rechne mit einer VM für den Controller, ein bis zwei Agent-Maschinen und der Wartungszeit. Setzt du konservativ vier Stunden im Monat für Updates, Plugin-Konflikte und Backups an, ist das bei internen Stundensätzen schnell teurer als beide SaaS-Varianten. Jenkins rechnet sich vor allem dort, wo Hardware schon steht und das Know-how im Haus ist.

Der größte Hebel liegt bei macOS. 1.000 iOS-Build-Minuten kosten auf GitHub 62 US-Dollar. Bei 5.000 macOS-Minuten im Monat sind das 310 US-Dollar, aufs Jahr 3.720 US-Dollar. Diese Summe stellst du dem Kaufpreis eines Mac mini als self-hosted Runner plus Wartungszeit gegenüber. Wenn Container-Builds in Kubernetes-Clustern landen, kommen deren Betriebskosten dazu. Was EKS, AKS und GKE im Monat kosten, haben wir in Kubernetes-Kosten 2026: Was managed Cluster wirklich pro Monat kosten durchgerechnet.

Wie sieht dieselbe Pipeline in GitHub Actions, GitLab CI und Jenkins aus?

Dieselbe Node.js-Pipeline mit Abhängigkeiten installieren, testen und 15-Minuten-Timeout braucht in GitHub Actions 19 Zeilen YAML, in GitLab CI 17 Zeilen YAML und in Jenkins ein deklaratives Jenkinsfile mit zwei Stages. Die Logik bleibt gleich, die Syntax und das Caching unterscheiden sich.

Der direkte Vergleich zeigt besser als jede Feature-Liste, wie sich die Systeme anfühlen. Alle drei Beispiele bauen ein Node.js-Projekt mit Node 24, nutzen einen npm-Cache und brechen nach 15 Minuten ab. Den GitHub-Workflow haben wir mit actionlint 1.7.7 geprüft (keine Befunde), die GitLab-Datei per YAML-Parser validiert.

GitHub Actions

name: ci
on:
  push:
    branches: [main]
  pull_request:
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-24.04
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm test

Zwei Details, die in vielen Tutorials fehlen: permissions: contents: read beschränkt das automatisch erzeugte GITHUB_TOKEN auf Lesezugriff. Und die Actions sind auf den vollen Commit-SHA gepinnt statt auf @v7. Warum das wichtig ist, steht im nächsten Abschnitt.

GitLab CI

default:
  image: node:24
  interruptible: true

stages: [test]

test:
  stage: test
  timeout: 15m
  cache:
    key:
      files: [package-lock.json]
    paths: [.npm/]
  script:
    - npm ci --cache .npm --prefer-offline
    - npm test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

GitLab kann den npm-Cache nur innerhalb des Projektverzeichnisses sichern, deshalb der Umweg über --cache .npm. interruptible: true bricht ältere Pipelines ab, sobald jemand auf denselben Branch nachpusht. Das spart bei aktiven Merge Requests spürbar Minuten.

Jenkins

pipeline {
  agent { docker { image 'node:24' } }
  options { timeout(time: 15, unit: 'MINUTES') }
  stages {
    stage('Install') { steps { sh 'npm ci' } }
    stage('Test')    { steps { sh 'npm test' } }
  }
}

Das Jenkinsfile sieht am kürzesten aus, setzt aber die Plugins Pipeline und Docker Pipeline sowie einen Agent mit Docker voraus. Caching musst du selbst lösen, etwa über ein gemountetes Volume.

Jenkins in fünf Minuten lokal starten

Wer Jenkins nur evaluieren will, startet das offizielle LTS-Image. Die folgende Befehlsfolge haben wir am 07.10.2026 ausgeführt, die Ausgaben stammen aus diesem Lauf.

1. Container starten:

   docker run -d --name jenkins -p 8080:8080 -p 50000:50000 \
     -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-jdk21

   Erwartete Ausgabe: eine 64-stellige Container-ID.

2. Version im Log prüfen:

   docker logs jenkins 2>&1 | grep -E "Starting version|fully up"

   Ausgabe bei uns: Starting version 2.580.1 und nach rund zwei Sekunden Jenkins is fully up and running.

3. Java-Version kontrollieren:

   docker exec jenkins java -version

   Ausgabe: openjdk version "21.0.12.1" 2026-08-18 LTS (Temurin).

4. Initiales Admin-Passwort auslesen:

   docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

   Ausgabe: eine 32-stellige Hex-Zeichenkette. Danach unter http://localhost:8080 den Setup-Assistenten durchlaufen.

Für den Produktivbetrieb reicht das nicht. Dort gehören ein Reverse Proxy mit TLS, ein Backup von jenkins_home und getrennte Agents dazu. Builds auf dem Controller selbst sollten deaktiviert sein.

Wie schützt du eine CI/CD-Pipeline vor Supply-Chain-Angriffen?

Eine CI/CD-Pipeline schützt du vor Supply-Chain-Angriffen, indem du Actions und Images auf feste Commit-SHAs pinnst, Token-Rechte minimal hältst und statt langlebiger Cloud-Schlüssel OIDC nutzt. Der Fall tj-actions/changed-files vom März 2025 betraf laut The Hacker News über 23.000 Repositories auf GitHub.

Der Vorfall ist das Lehrbuchbeispiel. Angreifer hatten die Version-Tags der beliebten Action tj-actions/changed-files auf einen manipulierten Commit umgebogen. Laut Wiz Research schrieb der Schadcode den Speicher des Runners samt Secrets doppelt Base64-kodiert in die Workflow-Logs. Bei öffentlichen Repositories waren diese Logs für jeden lesbar. Getroffen hat es alle, die @v45 oder einen anderen Tag referenzierten. Wer auf einen vollständigen Commit-SHA gepinnt hatte, war nicht betroffen, weil ein SHA nicht nachträglich umgebogen werden kann.

Den SHA zu einem Tag ermittelst du ohne Browser direkt mit Git. Abfrage vom 07.10.2026:

$ git ls-remote https://github.com/actions/checkout 'refs/tags/v7*'
9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0	refs/tags/v7.0.0
3d3c42e5aac5ba805825da76410c181273ba90b1	refs/tags/v7.0.1
3d3c42e5aac5ba805825da76410c181273ba90b1	refs/tags/v7

Bei annotierten Tags zeigt git ls-remote zusätzlich eine Zeile mit ^{}. Pinne dann auf diesen SHA, denn nur er zeigt auf den Commit. Damit das Pinnen nicht in Handarbeit ausartet, aktualisiert Dependabot gepinnte SHAs automatisch, wenn du im Kommentar die Version stehen lässt.

Seit dem 15. August 2025 können Organisations-Admins das Pinnen auch erzwingen. GitHub prüft dann, ob jede Action mit vollem Commit-SHA eingebunden ist, und lässt Workflows ohne Pinning fehlschlagen. In derselben Policy lassen sich einzelne Actions oder Versionen mit einem vorangestellten ! sperren. In GitLab ist das Gegenstück das Einbinden von CI/CD-Komponenten und Includes mit fester Version oder SHA statt ~latest.

Der zweite Baustein sind Cloud-Zugänge. Statt AWS-Access-Keys oder Azure-Service-Principal-Secrets in den CI-Variablen abzulegen, tauscht die Pipeline per OpenID Connect ein kurzlebiges Token gegen temporäre Cloud-Credentials. GitHub und GitLab unterstützen OIDC mit AWS, Azure und Google Cloud nativ, bei Jenkins brauchst du dafür Plugins. Ein gestohlenes OIDC-Token ist nach Minuten wertlos, ein geleakter Access Key nicht. Für Deploy-Schlüssel auf Servern gilt dasselbe Prinzip: getrennte, eingeschränkte Schlüssel pro Pipeline. Wie du SSH-Schlüssel sauber erzeugst und verwaltest, zeigt unsere Anleitung zu SSH-Schlüsselpaaren für Linux und macOS.

Wann lohnen sich self-hosted Runner?

Self-hosted Runner lohnen sich, wenn Builds Zugriff auf interne Netze brauchen, viele macOS-Minuten anfallen oder große Caches lokal schneller sind. Für öffentliche Repositories und kleine Teams mit wenigen tausend Linux-Minuten im Monat sind gehostete Runner günstiger und sicherer.

Ein self-hosted Runner ist ein Agent-Prozess auf deiner eigenen Maschine, der Jobs von GitHub oder GitLab abholt. Die Rechenzeit zahlst du dann über Strom und Hardware statt pro Minute. Bei GitHub ist das bis auf Weiteres gebührenfrei, weil die angekündigte Plattformgebühr verschoben wurde. Behalte die GitHub-Changelogs im Blick, falls sie zurückkommt: Bei 0,002 US-Dollar pro Minute würden 50.000 self-hosted Minuten im Monat 100 US-Dollar kosten.

Die Registrierung eines GitLab-Runners läuft seit dem neuen Runner-Workflow über ein Authentifizierungs-Token, das du in der Oberfläche unter Settings, CI/CD, Runners erzeugst. Das Token beginnt mit glrt-:

sudo gitlab-runner register \
  --non-interactive \
  --url https://gitlab.com \
  --token glrt-XXXXXXXXXXXXXXXXXXXX \
  --executor docker \
  --docker-image alpine:latest

Danach zeigt sudo gitlab-runner verify den Runner als is valid an, und er erscheint in der Projektansicht mit grünem Punkt.

Ein Sicherheitsaspekt wird oft übersehen: Self-hosted Runner an öffentlichen Repositories sind ein Einfallstor, weil jeder Fork-Pull-Request Code auf deiner Maschine ausführen kann. GitHub rät ausdrücklich davon ab. Nutze self-hosted Runner nur für private Repositories und setze sie, wo möglich, als kurzlebige Instanzen auf, die nach jedem Job neu starten.

Am Arbeitsplatz selbst hilft bei Pipeline-Arbeit vor allem Bildschirmfläche: Logs, Editor und Monitoring-Dashboard nebeneinander. Wer am Laptop mit zwei Monitoren arbeitet, braucht dafür ein Dock mit genug Ladeleistung. Das CalDigit TS4^* liefert laut Hersteller 98 W, 2,5-Gigabit-Ethernet und 18 Anschlüsse und funktioniert an Macs sowie an Windows- und Linux-Laptops mit Thunderbolt oder USB4. Bei nur einem Monitor ist es überdimensioniert. Für langes Scrollen durch Build-Logs ist eine Maus mit schnellem Scrollrad angenehm, etwa die Logitech MX Master 3S^*, deren MagSpeed-Rad zwischen Raster- und Freilauf umschaltet.

Welche Fehler bremsen CI/CD-Pipelines am häufigsten aus?

Die häufigsten Pipeline-Bremsen sind fehlende Caches, Jobs ohne Timeout, unnötige Läufe bei jedem Push und flaky Tests, die Wiederholungen erzwingen. Jeder dieser Fehler kostet direkt Minuten und damit Geld, und alle lassen sich mit wenigen Zeilen Konfiguration beheben.

Kein Dependency-Cache. Ein npm ci oder mvn install ohne Cache lädt bei jedem Lauf alles neu. Behebung: In GitHub reicht cache: npm in setup-node, in GitLab ein Cache-Key auf die Lockfile wie im Beispiel oben. Kontrolle: Im Log muss beim zweiten Lauf Cache restored beziehungsweise Successfully extracted cache stehen.

Kein Timeout. GitHub bricht einen Job auf gehosteten Runnern erst nach sechs Stunden ab. Ein hängender Integrationstest verbrennt so 360 Minuten. Behebung: timeout-minutes pro Job setzen, in GitLab timeout, in Jenkins options { timeout(...) }.

Doppelte Läufe. Wer on: [push, pull_request] ohne Branch-Filter setzt, baut jeden Commit in einem Pull Request zweimal. Behebung: push auf main beschränken. Zusätzlich hilft in GitHub concurrency mit cancel-in-progress: true, in GitLab interruptible: true.

Flaky Tests. Ein Test, der jedes zwanzigste Mal fehlschlägt, führt zu Re-Runs aus Gewohnheit, und irgendwann ignoriert das Team rote Builds. Behebung: Flaky Tests in Quarantäne verschieben, mit Ticket versehen und den Rest der Suite wieder verbindlich machen. Das ist weniger ein Tool- als ein Prozessproblem.

Fehlende Sicht auf Pipeline-Daten. Ohne Messung merkt niemand, dass die Durchlaufzeit von sechs auf vierzehn Minuten gewachsen ist. Der DORA-Report 2025 mit knapp 5.000 Befragten zeigt, warum das gerade jetzt zählt: 90 Prozent nutzen KI bei der Arbeit, KI-Einsatz korreliert positiv mit dem Durchsatz, aber weiterhin negativ mit der Stabilität der Auslieferung. Mehr Änderungen pro Tag brauchen schnellere und verlässlichere Pipelines. Wie du Build-Metriken in ein Monitoring-Backend bekommst, beschreibt unser Vergleich Observability-Stacks 2026: Datadog, Grafana Cloud und New Relic.

Häufige Fragen zu CI/CD-Tools

Was ist eine CI/CD-Pipeline?

Eine CI/CD-Pipeline ist eine automatisierte Abfolge von Schritten, die jeden Commit baut, testet und bei Erfolg ausliefert. CI (Continuous Integration) steht für das ständige Zusammenführen und Testen von Code, CD für Continuous Delivery oder Deployment, also das automatische Bereitstellen bis in Test- oder Produktivumgebungen.

Ist GitHub Actions für private Repositories kostenlos?

Teilweise. Der Free-Plan enthält 2.000 Minuten pro Monat auf Standard-Runnern, Pro und Team je 3.000. Darüber hinaus zahlst du pro Minute, auf Linux 0,006 US-Dollar. Für größere Runner gelten die Freiminuten nicht.

Wie aufwendig ist der Umstieg von Jenkins auf GitHub Actions oder GitLab CI?

Einfache Freestyle-Jobs und deklarative Pipelines lassen sich in wenigen Stunden pro Projekt übertragen. GitHub bietet dafür den GitHub Actions Importer, der Jenkins-Pipelines analysiert und Workflows vorschlägt. Aufwendig wird es bei Shared Libraries und Spezial-Plugins, für die es keine direkte Entsprechung gibt.

Wie lange sollte eine Pipeline dauern?

Eine feste Grenze gibt es nicht. Als Faustregel aus der Praxis sollte die Pipeline für einen Pull Request in unter zehn Minuten Feedback liefern, sonst wechseln Entwickler in der Wartezeit den Kontext. Lange Suites gehören in nächtliche oder parallelisierte Jobs.

Kann ich KI-Coding-Assistenten in der Pipeline nutzen?

Ja, etwa für automatische Code-Reviews in Pull Requests. Die Ergebnisse ersetzen aber keine Tests. Welche Assistenten sich im Alltag bewähren, vergleichen wir in KI-Coding-Tools 2026: Claude Code, Cursor und GitHub Copilot.

Quellen

• GitHub Docs: Actions runner pricing, docs.github.com/en/billing/reference/actions-runner-pricing, abgerufen am 07.10.2026
• GitHub Docs: GitHub Actions billing, inkludierte Minuten und Speicher je Plan, abgerufen am 07.10.2026
• GitHub: Pricing changes for GitHub Actions (Preissenkung zum 01.01.2026, Verschiebung der Self-hosted-Gebühr), github.com/resources/insights, abgerufen am 07.10.2026
• GitHub: Preisseite github.com/pricing, abgerufen am 07.10.2026
• GitHub Changelog: GitHub Actions policy now supports blocking and SHA pinning actions, 15.08.2025
• GitLab: Preisseite about.gitlab.com/pricing, abgerufen am 07.10.2026
• GitLab Docs: Compute minutes, Kostenfaktoren der gehosteten Runner, abgerufen am 07.10.2026
• endoflife.ai: GitLab 19.4, Release am 17.09.2026, Patch 19.4.1 am 22.09.2026
• Jenkins: LTS Changelog, Release 2.580.1 vom 30.09.2026, jenkins.io/changelog-stable
• Jenkins: Java Support Policy, jenkins.io/doc/book/platform-information/support-policy-java, abgerufen am 07.10.2026
• Wiz Research: GitHub Action tj-actions/changed-files supply chain attack (CVE-2025-30066), März 2025
• The Hacker News: GitHub Action Compromise Puts CI/CD Secrets at Risk in Over 23,000 Repositories, 17.03.2025
• Google Cloud / DORA: Announcing the 2025 DORA Report, 23.09.2025
• Eigener Testlauf: jenkins/jenkins:lts-jdk21 und actionlint 1.7.7, ausgeführt am 07.10.2026

Das könnte dich auch interessieren

Cloud & DevOps

Kubernetes-Kosten 2026 – Was managed Cluster wirklich pro Monat kosten

Cloud & DevOps

AWS vs Azure vs GCP 2026 – Welche Cloud-Plattform fuer welchen Use Case rechnet sich

Cloud & DevOps

Observability-Stacks 2026 – Datadog, Grafana Cloud und New Relic im Vergleich