Jenkins: open-source automation server for CI/CD

What Jenkins is

Jenkins is an open-source automation server written in Java. Its README calls it the leading open-source automation server and says it provides over 2,000 plugins to support automating virtually anything. In practice it is the engine behind a large share of self-hosted continuous integration and delivery: it checks out code, builds it, runs tests and static analysis, packages artefacts and deploys them, on hardware the team controls.

The README lists the common jobs directly: building projects, running tests to detect bugs as soon as they are introduced, static code analysis and deployment. Beyond that, the plugin ecosystem means Jenkins is often used as a general job scheduler and orchestrator for anything that can be scripted. The project is governed by an open-source community, is MIT-licensed, and offers official distributions as WAR files, Docker images, native packages and installers for several Linux distributions and Windows.

Jenkins suits teams that need CI/CD on their own infrastructure, whether for compliance, network access to internal systems, unusual build hardware or cost control, and teams that want deep customisation through plugins and pipeline code rather than a fixed hosted feature set.

How it works

Controller and agents

The Jenkins architecture is designed for distributed builds. The controller is the original node of an installation: it administers agents and orchestrates their work, scheduling jobs and monitoring them. Agents provide executors that perform the work, whether Pipeline steps, freestyle jobs or other job types. Agents can be local machines or cloud computers, and each needs a Java installation and a network connection to the controller.

Labels describe agent capabilities. The docs give the examples of an aarch64 label for an Arm64 machine and a code-signing label for an agent that holds signing tools, so jobs can target the right environment. The number of executors controls how many tasks an agent runs concurrently, and the docs recommend setting the controller's executors to 0 so the controller only coordinates and does not run builds itself. Inbound agents connect to the controller over TCP port 50000 by default; WebSocket agents do not need that port.

Pipeline as code

Jenkins Pipeline is a suite of plugins for modelling continuous delivery pipelines as code. A pipeline definition lives in a text file called a Jenkinsfile, which is committed to the project's repository. The documentation lists the benefits: Jenkins can automatically create pipelines for all branches and pull requests, the pipeline is reviewed and iterated on alongside the code, there is an audit trail, and there is a single source of truth that several people can edit.

Two syntaxes exist. Declarative Pipeline is designed to be easier to write and read and offers richer syntactical features. Scripted Pipeline is a more flexible Groovy-based form. Many individual steps are common to both. The docs describe pipelines as durable (they survive planned and unplanned controller restarts), pausable (they can wait for human input or approval), versatile (fork, join, loop and parallel work) and extensible through plugins and shared libraries.

Plugins

Most functionality beyond the core arrives as plugins, installed from the Manage Jenkins page or during setup. Source control integrations, build tools, cloud agent provisioning, authentication providers, notifications and the Pipeline features themselves are delivered this way. The plugin index at plugins.jenkins.io is where they are catalogued.

Key features

• Pipeline as code. Jenkinsfiles in Declarative or Scripted syntax, versioned with the application.
• Multibranch and pull request builds. Pipelines are created automatically for each branch and pull request that contains a Jenkinsfile.
• Distributed builds. A controller schedules work across any number of agents, selected by label, on local machines or cloud infrastructure.
• Durable, pausable pipelines. Runs survive controller restarts and can stop to wait for approval before continuing.
• Parallel and complex flows. Fork and join, loops and parallel stages for real-world delivery processes.
• Docker integration. Pipelines can run steps inside containers on agents, and the official jenkins/jenkins image is the documented way to run Jenkins itself in Docker.
• Shared libraries. Common pipeline code can be extracted into libraries reused across projects.
• Over 2,000 plugins, according to the README, covering integrations from source control to deployment targets.
• Access control. A security realm decides who users are (Jenkins' own user database, LDAP, Active Directory and others) and an authorization strategy decides what they can do, including matrix-based permissions.
• Two release lines. Weekly releases with all new features and fixes, and Long-Term Support releases updated with backported bug fixes.
• Many distribution formats. WAR file, Docker images, native Linux packages and a Windows installer, with the installation docs also covering macOS and Kubernetes.

Getting started

The installation docs list minimum hardware of 256 MB of RAM and 1 GB of disk (10 GB recommended when running in a container), and recommend 4 GB or more of RAM and 50 GB or more of disk for a small team. Jenkins requires Java 21 or later.

Debian or Ubuntu

The Linux guide says to install Java before Jenkins; if Java is added afterwards, the service may fail to start with a "failed to find a valid Java installation" error. The documented commands are:

sudo apt update
sudo apt install fontconfig openjdk-21-jre
java -version

Then add the LTS repository and install the package:

sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2026.key
echo "deb [signed-by=/etc/apt/keyrings/jenkins-keyring.asc]" \
  https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt update
sudo apt install jenkins

A weekly-release repository is documented as an alternative. The guide explains that an LTS release is chosen every 12 weeks from the stream of regular releases as the stable release for that period.

WAR file

The WAR file bundles Winstone, a Jetty servlet container wrapper, and runs on any platform with a supported Java version. The docs show the default start and a custom port:

java -jar jenkins.war
java -jar jenkins.war --httpPort=9090

The JENKINS_HOME environment variable sets where Jenkins stores its configuration. Starting from the WAR does not install any plugins automatically.

Docker

The Docker guide creates a bridge network, runs a docker:dind container so builds can execute Docker commands, builds a customised image from jenkins/jenkins that includes the Docker CLI and the docker-workflow plugin, and runs it with ports 8080 and 50000 published and a jenkins-data volume for /var/jenkins_home. The first step is:

docker network create jenkins

The guide notes that running Docker in Docker currently requires privileged access, and that TLS between Jenkins and the inner Docker daemon is recommended because of that.

The setup wizard

On first launch, browsing to port 8080 shows an Unlock Jenkins page. The automatically generated administrator password appears in the console log and can be read from disk on a package install:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

The wizard then offers to install suggested plugins or a custom selection, and asks for the first administrator account. If user creation is skipped, the initial password remains the password of the default admin account.

A first Jenkinsfile

The Jenkinsfile docs start with a three-stage Declarative Pipeline:

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                echo 'Building..'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing..'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying....'
            }
        }
    }
}

The agent directive is required and tells Jenkins to allocate an executor and workspace; by default it also checks out the source repository. The stages and steps directives are required too. Real pipelines replace the echo steps with build commands, for example using the sh step to call make.

Use cases

• Self-hosted CI for private code. Build and test every branch and pull request on infrastructure inside the company network, close to internal package registries and databases.
• Multi-platform builds. Use labelled agents to build and test on different operating systems and CPU architectures from one pipeline, including Arm64 machines.
• Release pipelines with approvals. Pause a pipeline before production deployment until a person approves, while keeping the whole process in a reviewed Jenkinsfile.
• Specialised hardware. Dedicate agents to machines with signing keys, GPUs or attached devices, and route only the relevant jobs to them.
• Scheduled automation. Run recurring maintenance, data jobs or report generation with the same logging, credentials handling and history as builds.
• Static analysis and quality gates. Run linters and analysers as pipeline stages, as the README suggests, and fail builds that do not pass.

Running Jenkins day to day

Almost all of a Jenkins installation's state lives in its home directory. On a package install that is under /var/lib/jenkins; with the WAR file it is set by JENKINS_HOME; in the documented Docker setup it is the /var/jenkins_home path inside the container, mapped to a named volume called jenkins-data or, as the docs suggest as an alternative, to a directory on the host such as $HOME/jenkins. Backing up and migrating Jenkins largely means handling that directory, and the Docker guide warns that if the source volume changes, the Docker-in-Docker container's volume must be changed to match.

Ports are adjustable at every layer. The WAR accepts --httpPort; in Docker the host side of the --publish mapping can differ from the container's 8080, and the docs give -p 49000:8080 as an example. If the inbound agent port is changed on the controller's Security page, the container has to be re-run with a matching publish option.

Plugins are installed and removed later from Manage Jenkins, then Plugins, so the initial wizard choice is not permanent. For access, the security documentation lists several patterns: a simple setup for a java -jar jenkins.war install, Jenkins' own user database with finer-grained permissions, putting Jenkins behind an Apache front end that performs access control, BASIC authentication for scripted clients, and matrix-based security. Separately, access control for builds limits what a build can do once it has started, which matters when untrusted code runs in pipelines.

How it compares

Jenkins is often weighed against CI/CD systems built into code hosts, such as GitHub Actions and GitLab CI, and against other self-hosted servers. The broad trade-off is control versus convenience. Jenkins runs wherever you install it, connects to any network you can reach, and can be extended in almost any direction through plugins and Groovy pipeline code. In return, the team owns the controller: upgrades, plugin compatibility, backups, security hardening and scaling the agent pool. Hosted, platform-integrated systems remove much of that operational work but tie pipelines to a specific platform and its runners. Teams evaluating options should compare against each tool's own documentation rather than generic feature lists.

Things to know before adopting

• Licence. Jenkins core is MIT-licensed. Plugins are separate projects with their own licences and maintainers, so the overall licence picture depends on which plugins are installed.
• Java 21 or later. Both the controller and agents need Java, and the docs point to a Java support policy page for compatible versions.
• Choose a release line. Weekly releases get new features first; LTS releases are picked every 12 weeks and receive backported fixes. Most production installations will want to make this choice deliberately and stick with it.
• Plugins need care. Much of Jenkins' value is in plugins, and each one is code running inside the controller. Keeping plugins updated and pruning unused ones is part of operating Jenkins.
• Lock down access. The security docs describe two axes that must each be configured: the security realm (who users are) and the authorization strategy (what they can do). The setup wizard creates an admin user; skipping that step leaves the generated password as the admin password.
• Do not build on the controller. The agents documentation recommends zero executors on the controller to avoid resource contention and keep it dedicated to coordination.
• Agent networking. Inbound agents need TCP port 50000 (or a configured alternative) reachable on the controller unless WebSocket agents are used.
• Docker in Docker is privileged. The documented Docker setup runs docker:dind with --privileged; consider the security implications on shared hosts.
• Resources grow with usage. The minimum is 256 MB of RAM, but the recommendation for a small team is 4 GB or more and 50 GB or more of disk, and build history, artefacts and workspaces accumulate in JENKINS_HOME.
• Java before Jenkins on Debian. Installing the package before Java can leave the service unable to start.

Project activity

As of November 2026 the jenkinsci/jenkins repository has about 26,700 stars on GitHub. The repository was created in November 2010, is written in Java and is licensed under MIT. The most recent tagged release on GitHub at the time of writing is jenkins-2.580.2, published at the end of October 2026, and the repository received commits on the day of writing. Jenkins publishes a weekly line and an LTS line, with changelogs for both on jenkins.io, and the README shows badges for reproducible builds and the CII Best Practices programme.

The source is at github.com/jenkinsci/jenkins. Documentation, downloads, the plugin index and governance information are on jenkins.io.

[![Featured on TechLogHub](https://techloghub.com/badge-neutral.svg)](https://techloghub.com/open-source/jenkins?utm_source=techloghub_badge&utm_medium=referral&utm_campaign=readme)