Jenkins

Last reviewed Aug 26, 2026 · 836 words

Choose Jenkins in 2026 for one reason: a plugin or an integration that nothing else has. It has been in the CI/CD category since 2011, it has thousands of plugins, and it can build anything, from a 2004 Ant project to a Kubernetes-scaled matrix of containers, on any operating system. It also asks more of its operator than any modern alternative, and for a homelab with Git repositories on Gitea or Forgejo, Woodpecker CI does the common case in a tenth of the RAM with a tenth of the attention.

Why it is still everywhere

The plugin catalogue is the moat. Vendor integrations for hardware test rigs, legacy source control, obscure artifact stores, and enterprise notification systems exist for Jenkins because for 15 years it was the only game. Distributed builds are mature: static agents over SSH, ephemeral Docker agents, Kubernetes pods spun up per build, Windows and macOS agents for native builds. And the Jenkinsfile turned it into a pipeline-as-code system that reads like a proper build definition:

pipeline {
  agent { docker { image 'golang:1.22' } }
  stages {
    stage('Test') {
      steps { sh 'go test ./...' }
    }
    stage('Build') {
      steps { sh 'go build -o app ./cmd/app' }
    }
  }
}

That file lives in the repository, the agent is a fresh container per run, and any Jenkins in the world with the Docker plugin can run it. Teams migrating from GitHub Actions will recognise the shape.

Docker install and the first 10 minutes

services:
  jenkins:
    image: jenkins/jenkins:lts-jdk21
    ports:
      - "8080:8080"
      - "50000:50000"
    volumes:
      - ./jenkins_home:/var/jenkins_home
    restart: unless-stopped

Port 8080 is the UI, 50000 is where inbound agents connect, and /var/jenkins_home is the entire state: config, plugins, credentials, job history. Back that directory up and you have backed up Jenkins. On first visit the UI asks for the initial admin password, which is in jenkins_home/secrets/initialAdminPassword, then offers to install a suggested plugin set. Take the suggestion; it includes the pipeline, Git, and credentials plugins that everything else assumes.

The catalogue's 1 GB minimum is right for the controller alone. Give it 2 GB once a few plugins are in, and run builds on agents rather than on the controller, which is both a security boundary and the thing that keeps the UI responsive. The official image does not bundle Docker; the usual homelab arrangement is a separate agent container with the Docker socket, or a dedicated build VM.

Configuration as Code is not optional

Jenkins is click-configured by default, and a click-configured Jenkins is a snowflake that nobody can rebuild. The Configuration as Code plugin, usually called JCasC, fixes that: a YAML file declaring credentials, agents, security realm, tool installations, and global settings, loaded at startup from a path in the CASC_JENKINS_CONFIG environment variable. Pair it with a plugins.txt file baked into a custom image via the jenkins-plugin-cli tool, and the whole controller becomes reproducible from a Git repository. Jobs themselves should come from a multibranch pipeline that scans your forge organisation and creates them from Jenkinsfiles, so no job is ever created by hand either. Set this up in week one. Retrofitting it onto a Jenkins that has grown by clicking for 2 years is a project.

Plugins are the operational cost

The catalogue's "plugin management can be painful" con understates it. Plugins have dependencies on each other and on the Jenkins core version, security advisories arrive most weeks and often involve a plugin, and an update to one plugin can break another. The LTS release line, which updates every 12 weeks with monthly point releases, is the only line worth running outside of development. My routine: read the advisory feed, update the controller monthly from a pinned tag, update plugins from the plugins.txt in the same commit, and rebuild the image rather than updating in place. That is roughly 30 minutes a month, and it is the honest price of the plugin catalogue.

Keep the plugin list short. Every plugin beyond the suggested set is a future upgrade problem, and most of what people install, such as Blue Ocean for a nicer UI, is unmaintained or replaced by core features. The dated interface the catalogue mentions is real, and I have made peace with it.

What I'd do

For a homelab or a small team on a self-hosted forge with Docker-based builds: Woodpecker or the forge's own CI, and no Jenkins. For anything that needs Windows or macOS native agents, a specific vendor plugin, or a pipeline definition that has grown for a decade: Jenkins on the LTS image, JCasC and plugins.txt from day one, controller at 2 GB, builds on agents, and a calendar reminder for the monthly update. Run that way it is a boring, dependable, MIT-licensed build server with 26,000 stars and 15 years of answers to every question you will ever ask it, and boring is the compliment.