Jenkins: the CI veteran with 2000+ plugins, high learning curve, low modernity

What is Jenkins?

Jenkins is the veteran of the continuous integration world. The project started in 2004 as Hudson at Sun Microsystems, was renamed Jenkins in 2011 after Oracle bought Sun, and has been an independent project under MIT licence since. As of May 2026, in version 2.450+ (LTS line) – a very long history, a very large community, a very broad plugin marketplace with over 2000 entries.

Licence: MIT – fully free, fully self-host. CloudBees as the main sponsor offers a commercial CloudBees CI, but OSS Jenkins itself is not limited.

Architecture: Jenkins is a Java application (runs in a servlet container or as standalone WAR). Master/controller orchestrates, agents (build slaves) execute jobs. Configuration historically via the UI (job configuration XMLs on disk), modern via Jenkinsfile (Groovy DSL) in the repo.

Plugin system: the core argument for and against Jenkins. 2000+ plugins cover practically every conceivable integration – Git, Slack, Jira, Docker, Kubernetes, AWS, Azure, GCP, Selenium, SonarQube, Nexus, Artifactory, and thousands more. But: plugin quality varies wildly, many are unmaintained, many carry security vulnerabilities. Plugin updates must be tested carefully.

Jenkinsfile: since around 2016 the modern configuration mode. A Groovy DSL file in the repo defines the pipeline. Very flexible (the full Groovy language is available), but with a steeper learning curve than YAML-based competitors (GitLab CI, Gitea Actions, Woodpecker). Pipelines can be written scripted (imperative) or declarative – declarative is the 2026 default.

May 2026 verdict: Jenkins is not dead, but not modern. Anyone already running it with hundreds of Jenkinsfiles should stay – migrating to YAML CI is effort without immediate value. Anyone starting fresh in 2026 should pick Woodpecker, Gitea Actions, GitLab CI, or GitHub Actions. Jenkins is "legacy by choice" – justified only by very specific plugin requirements, compliance mandates, or existing Jenkins know-how in the team.

Why it (still) matters

Jenkins is not the tool an SME would newly introduce in 2026. But it is the tool many SMEs already have – often for 8 or 10 years, with hundreds of Jenkinsfiles, with plugin configurations, with build agent setups. Ignoring that reality would be unfair.

Brownfield reality: we regularly see Jenkins in mandates – a fiduciary office with 5 internal tools, all built via Jenkins since 2018. A law firm with its own client platform whose build pipeline has been in Jenkinsfile Groovy since 2020. A mid-market industrial with complex cross-platform builds (Linux + Windows + macOS agents) centrally orchestrated in Jenkins. Migrating to YAML CI would be weeks of work without the end customer seeing any benefit.

CH DSG fit: fully achievable. Jenkins self-host on Hetzner Falkenstein, all data on-premise, MIT licence without US cloud binding. From a DSG view, Jenkins is unproblematic.

Plugin power as argument: when an SME need is very specific (e.g. SonarQube integration plus Selenium grid plus Nexus artifact publishing plus Slack approval gate plus Jira integration), Jenkins can map all of it into one workflow. YAML CI competitors would have to solve it through external tools. For mandates of that complexity, Jenkins is the rational pick.

Learning curve as reality: Groovy DSL is its own world. Writing Jenkinsfile pipelines requires knowledge that is not universally spread. After a personnel change a new hire is often unproductive without ramp-up. YAML pipelines (Woodpecker, GitLab CI) are more universally understood.

Security reality: a Jenkins master with system-level plugin permissions is an attractive target. CVE watching is mandatory – Jenkins publishes plugin security advisories weekly. Anyone running Jenkins must have an update process in place.

May 2026 realism: Jenkins will not "die". But investment energy goes to modern tools. Anyone free to choose today: Woodpecker, GitLab CI, or GitHub Actions. Anyone with Jenkins: stay, patch, migrate to YAML CI long-term when the opportunity arises.

How it works

Jenkins runs as a Java application. Standard setup: one controller plus N agents.

docker-compose.yml example (simplified):

```yaml services: jenkins: image: jenkins/jenkins:lts-jdk17 user: root ports: - "8080:8080" - "50000:50000" volumes: - jenkins-data:/var/jenkins_home - /var/run/docker.sock:/var/run/docker.sock environment: JAVA_OPTS: "-Djenkins.install.runSetupWizard=false" JENKINS_OPTS: "--prefix=/jenkins" restart: unless-stopped jenkins-agent: image: jenkins/inbound-agent:latest environment: JENKINS_URL: http://jenkins:8080/jenkins JENKINS_AGENT_NAME: docker-agent-01 JENKINS_SECRET: ${AGENT_SECRET} depends_on: [jenkins] restart: unless-stopped volumes: jenkins-data: ```

After first start: read the initial admin password from jenkins-data/secrets/initialAdminPassword, browser to http://server:8080, click through the plugin selection (recommended default set), create admin user.

Pipeline example (Jenkinsfile, declarative):

```groovy pipeline { agent { docker { image "node:20" } } stages { stage("Build") { steps { sh "npm ci" sh "npm run build" } } stage("Test") { steps { sh "npm test" } post { always { junit "test-results/*.xml" } } } stage("Deploy") { when { branch "main" } steps { withCredentials([sshUserPrivateKey(credentialsId: "deploy-key", keyFileVariable: "SSH_KEY")]) { sh "ssh -i $SSH_KEY deploy@server \"cd /app && git pull && pm2 restart all\"" } } } } post { failure { mail to: "[email protected]", subject: "Build failed: ${env.JOB_NAME}" } } } ```

Credentials management: in Jenkins via the credentials store. Several types (username/password, SSH key, secret file, cert). Per job or global. The "Credentials Binding" plugin exposes them as env vars or files.

Plugin maintenance: Update Center in the UI. Recommendation: check plugin updates monthly, test in a staging Jenkins setup, then promote to production. Subscribe to the CVE mailing list (jenkinsci-advisories).

Backup: back up the JENKINS_HOME directory (default /var/jenkins_home) completely. Contains job configurations, build histories, plugins, credentials (encrypted with master key). Cron daily plus off-site copy via rsync. Restore: copy directory back, start Jenkins image, done.

Setup in 5 steps (or migration away)

1. 01Check if a new install is needed – May 2026 Woodpecker, GitLab CI, or Gitea Actions are the strategic pick. Existing Jenkins stays, new setups go YAML CI.
2. 02If Jenkins continues: start docker-compose with jenkins/jenkins:lts-jdk17, persist JENKINS_HOME volume, save the initial admin password.
3. 03Install minimum plugin set: Git, Pipeline, Credentials, Docker, Email Extension, Mailer. Avoid plugin inflation – every install is a potential CVE source.
4. 04Create first pipeline as Jenkinsfile in the repo, configure multibranch pipeline job in Jenkins, set webhook in the Git host for push trigger.
5. 05Enable CVE watching: subscribe to jenkinsci-advisories mailing list, test plugin updates in staging monthly, daily backup of JENKINS_HOME.

When to (still) use Jenkins

In May 2026 Jenkins is the right choice in specific constellations: (a) existing Jenkins setup with hundreds of Jenkinsfiles – migration is effort without immediate value, (b) very specific plugin requirements that YAML CI cannot model (e.g. complex cross-platform build matrix with Windows slaves), (c) deep Jenkins know-how in the team – the YAML CI learning curve would cause productivity loss, (d) compliance mandates explicitly require Jenkins (rare but real in some bank audits).

Concrete cases: a mid-market industrial with 50 build jobs, 20 of them Windows-specific using Selenium Grid plus Nexus artifact publishing – Jenkins stays. A SaaS platform with a complex multi-cloud deployment pipeline (AWS plus Azure plus GCP targets in one pipeline) centralised through a Jenkins pipeline library – migration to YAML CI would be weeks without value.

For SMEs with standard web apps and simple pipelines: not Jenkins. Use Gitea Actions, Woodpecker, or GitLab CI instead.

At Fairlane we run Woodpecker, not Jenkins. A Jenkins setup would be overkill and slower to set up for our SME-typical pipelines (build, test, container push, SSH deploy).

When not to use

Jenkins is the wrong choice when (a) the setup is being built fresh in May 2026 – Woodpecker, GitLab CI, or GitHub Actions are more modern, (b) the team is under 5 developers – learning curve and maintenance are disproportionate, (c) container-native pipelines are expected – Jenkins can do it but is not as clean as Drone successors, (d) the operations budget does not allow weekly plugin CVE watching.

Pitfalls: updating plugins in production without prior testing – plugin updates have broken pipelines historically. Always test in a staging Jenkins. Exposing the Jenkins master directly to the internet – extremely high target. Place behind nginx with IP allow-list or VPN. Creating Jenkinsfile pipelines without version control (via UI config) – disaster recovery becomes impossible. Always keep Jenkinsfile in the repo.

Anti-patterns: picking Jenkins as central CI for an SME fiduciary setup because "the others have it" – the others have it for historical reasons, not rational choice. Plugin inflation: installing every "nice-to-have" plugin – each adds a CVE source. Aim for the minimum plugin set. Running build agents as root – privilege escalation on plugin compromise. Use a user account with Docker group membership.

Trade-offs

FAQ

Related topics

Sources

1. Jenkins – Documentation · 2026-05
2. Jenkins – LTS release line · 2026-04
3. Jenkins – Security advisories · 2026-05
4. CloudBees – Commercial Jenkins distribution · 2026-03