Jenkins

The self-hosted automation server much of CI started on: a Java controller that hands jobs to agents, more than 2,300 plugins, and pipelines written as a Jenkinsfile.

CDF · Graduated

What it is: CI/CD pipelines
Type: Open source
Made by: Continuous Delivery Foundation
Foundation: Continuous Delivery Foundation, graduated, joined March 2019. Part of the Linux Foundation
License: MIT
Facts checked: 28 October 2026

What it is

Jenkins is a Java web application you run yourself. The controller serves the web UI, schedules work and keeps everything as files under $JENKINS_HOME: its configuration, the job definitions, every build record and the plugins. Builds run on agents, other machines or containers connected to the controller. The docs advise against running builds on the controller’s own built-in node, because a build there has the same access to the controller’s files as Jenkins itself. Nearly everything beyond scheduling comes from plugins, for source control, credentials, cloud agents, test reports and notifications; the plugin index lists more than 2,300.

Since Jenkins 2.0 in April 2016, the usual way to describe a build is Pipeline: a Jenkinsfile committed to the repository, written in a Groovy-based syntax, either the stricter Declarative form or the free-form Scripted one. It splits the work into stages of steps such as sh 'make', can build every branch and pull request, and survives restarts of the controller. The Configuration as Code plugin does the same for the controller, setting it up from a YAML file instead of the web UI. Jenkins ships weekly releases and long-term support (LTS) lines; the latest LTS, 2.580.2, came out on October 28, 2026 and needs Java 21 or 25. It was a founding project of the Continuous Delivery Foundation in 2019 and its first to graduate, in August 2020.

Why teams pick it

Runs on your own hardware, under the MIT licence, with no per-minute billing or vendor service in the path
A plugin for almost any tool, cloud or version control system, so it fits into whatever a company already runs
Pipelines live in a Jenkinsfile next to the code, are reviewed like code, and keep running across controller restarts
Two decades of production use and neutral governance at the Continuous Delivery Foundation

Watch out for

You run it: the controller’s state is a directory of files to back up, and core and plugins need regular updates
Plugins are most of the attack surface: seven of the ten security advisories Jenkins published in 2026 up to October 28 involved plugins
Pipeline Groovy always runs on the controller, using its CPU and memory; the docs say to keep logic in sh steps that run on agents
Upgrades follow Java: since 2.555.1 Jenkins needs Java 21 or 25, and the last LTS line to support Java 17 ended in March 2026

Alternatives

What all ci/cd pipelines have in common →Compare side by side →

GitHub ActionsCommercialCI/CD built into GitHub: YAML workflows in the repository run on GitHub’s VMs or your own machines whenever something happens in the repo.

GitLabCommercialA Git forge sold as one application for the whole software lifecycle, from issues and merge requests to built-in CI/CD, packages and security scanning, that you can use on GitLab.com or run yourself.

TektonOpen sourceBuilding blocks for CI/CD systems as Kubernetes resources: each Task runs as a pod, each step in it as a container, and Pipelines chain Tasks together.

Argo CDOpen sourceGitOps delivery for Kubernetes: a controller in the cluster keeps what’s running identical to the manifests in a Git repository.

CodecovCommercialA hosted code coverage service: CI jobs upload the coverage reports their tests produce, and Codecov merges them per commit and reports on each pull request how well the changed lines are tested, with a status check that can block the merge.

KernelCIOpen sourceContinuous integration for the upstream Linux kernel: it builds kernel trees in many configurations, boots and tests them on real boards in community labs, and collects results from other kernel CI systems in one public database.

SigstoreOpen sourceSigning for releases, images and packages without keys to manage: a short-lived certificate tied to a login or CI job, and a public log of every signature.

How it fits with other technologies

What Jenkins uses

A declarative Jenkinsfile that builds, tests and deploys only from main · text

pipeline {
  agent { label 'linux' }   // run on an agent, not the controller
  options { timeout(time: 30, unit: 'MINUTES') }
  stages {
    stage('Build') {
      steps { sh './gradlew assemble' }
    }
    stage('Test') {
      steps { sh './gradlew test' }
      post { always { junit 'build/test-results/**/*.xml' } }
    }
    stage('Deploy') {
      when { branch 'main' }
      steps { sh './deploy.sh' }
    }
  }
}

See it in a real stack

No architecture uses Jenkins yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2004–2026

Kohsuke Kawaguchi, an engineer at Sun Microsystems, started Hudson in the summer of 2004 and released it in February 2005. It built and tested projects on every change, and its plugin system let other developers add support for their own tools.

After Oracle bought Sun in 2010, the community and Oracle disagreed over the project’s infrastructure and its name, which Oracle had applied to register as a trademark. In January 2011 Andrew Bayer wrote that without a binding guarantee the project would be “living under a sword of Damocles”, and the community voted to rename it Jenkins, with Kawaguchi registering the new trademark to hand to a non-profit. Oracle kept developing Hudson, gave it to the Eclipse Foundation at the end of 2012, and it was declared obsolete in 2017.

Jenkins 2.0, announced on April 26, 2016, put Pipeline as code at the centre: build definitions moved from forms in the web UI into a Jenkinsfile in the repository. In 2019 Jenkins became one of four founding projects of the Continuous Delivery Foundation, and in August 2020 its first graduated project. It has kept its weekly and LTS release lines since, moving to Java 21 as the minimum in 2026.

Why it’s built this way

A small core and everything else as plugins: Every team used a different mix of version control, build tools and test reports. Plugins let the community add support for each without changing the core, and the index has grown past 2,300.
A controller that hands builds to agents: Spreading builds over many machines adds capacity and lets each build run on the operating system it needs; it also keeps untrusted build scripts away from the controller’s files.
Rename rather than live with Oracle’s trademark: Oracle could withdraw the right to use “Hudson” at any time, so the community chose a new name it controlled instead.
Pipelines as code in a Groovy-based language: Jobs configured by clicking couldn’t be versioned or reviewed. A Jenkinsfile checked in with the source is versioned with it, and a Groovy-based language keeps complex pipelines manageable.

Timeline

2004
Kohsuke Kawaguchi starts Hudson at Sun Microsystems
2005
First Hudson release in February
2011
The community renames the project Jenkins in January
2016
Jenkins 2.0 makes Pipeline as code the default in April
2019
Founding project of the Continuous Delivery Foundation in March
2020
First CDF project to graduate, in August
2026
Java 17 support ends; LTS 2.580.2 released on October 28

Sources14 · facts checked 28 October 2026

Improve this page on GitHub