Running Jenkins

Jenkins is the piece of infrastructure nobody wants to touch. It works, it has been running for four years, half the pipelines depend on plugins whose authors have moved on, and the person who set it up has left. These seven articles are about the operational side of that: which version to be on, how to get there without breaking a Friday, and how to stop the server being a thing only one person understands.

They are operational notes rather than tutorials. Several are short and reference-shaped on purpose — you go to the Java compatibility page to check one fact, not to read an essay.

Everything comes back to $JENKINS_HOME

Jenkins is a stateful application pretending to be a service. Its entire identity — job definitions, build history, credentials, plugin versions, installed plugin .jpi files, the secrets used to decrypt everything else — lives in one directory. The war file is replaceable. That directory is not.

Almost every operational question about Jenkins is really a question about how much of $JENKINS_HOME is reproducible:

• Upgrades are risky because you cannot roll one back without a copy of it.
• Disaster recovery is a directory restore, and it fails if the plugin versions on the new machine do not match the ones that wrote the config.
• Configuration as Code is valuable because it moves the part of that directory you care about into a YAML file you can review and diff.
• A baked AMI or image is valuable because it does the same for the machine underneath it.

If you do one thing after reading this hub, make it this: know where your $JENKINS_HOME is, know that it is backed up, and know that you have restored it at least once. Everything below is easier when that is true.

The version question is three coupled questions

“Should I upgrade Jenkins?” is never one decision. It is three, and they are chained:

1. Which line — LTS or Weekly? LTS is a release every twelve weeks with backported fixes; Weekly is the current tip. For anything a team depends on, LTS. The versions guide makes the case properly, along with the history that explains why the two lines exist.
2. Which Java? Jenkins has moved through Java 8, 11, 17, 21 and now 25, and each core version has a supported window. Upgrading Jenkins onto a JVM it does not support fails at startup — which is the good outcome, because the alternative is a plugin failing at runtime three days later. The Java compatibility page is the lookup table.
3. Which plugins? This is the one that actually breaks. Plugins declare a minimum core version, and core upgrades can leave older plugins unable to load. The dependency runs in both directions, so a plugin you need can pin you to a core version, which pins you to a JVM.

Skipping several major versions makes all three worse at once, which is why the upgrade article treats a big jump differently from a routine one: in-place for a small step, blue-green or phased for a large one, on the reasoning that you cannot debug a four-version jump if it goes wrong — you can only go back.

The risk lives in the plugins

Jenkins has around 1,900 plugins and most installations run somewhere between forty and a hundred and fifty. That is your real attack surface and your real upgrade surface.

Core Jenkins security advisories exist — CVE-2024-23897, the CLI file-read vulnerability, was serious and is worth knowing about, and the security article covers it. But the steady stream is plugins: unmaintained ones, ones that were never audited, ones running with permissions nobody granted deliberately.

The useful habits are unglamorous. Subscribe to the Jenkins security advisory mailing list. Uninstall plugins you are not using rather than leaving them disabled. Look at the “last released” date before adopting one. And keep the controller off the public internet — a large share of Jenkins incidents are not exploits at all, they are an instance that was reachable with weak authentication.

Stop clicking things

The two articles in the middle group are the ones that change how the server is operated, rather than what version it runs.

Configuration as Code puts the settings that live in the web UI — security realm, authorisation strategy, credentials, tools, clouds, shared libraries — into a YAML file. The immediate payoff is a config you can diff and review. The real payoff is that a rebuilt Jenkins comes back the same, which turns “restore from backup” from an exercise in memory into a deploy.

A custom AMI does the equivalent for the host: Java, Jenkins, the agent tooling and the base configuration baked into an image, so a new controller boots ready rather than being configured by hand. That article was written for EC2 and the same reasoning applies to a container image — it discusses the Docker route too.

Both are pointed at the same target. A Jenkins nobody can rebuild is a Jenkins nobody can safely upgrade, and that is how installations end up eight versions behind.

What is not in this series

Running Jenkins on Kubernetes. That article lives in the Kubernetes and Containers series, because it teaches pods, deployments and persistent storage using Jenkins as the workload — it is a Kubernetes tutorial with Jenkins in it rather than the other way round. Read it when you want Jenkins on EKS: Deploy Jenkins on Amazon EKS.

Pipeline authoring. There is one pipeline article here — UserRemoteConfig, for building the same pipeline against a repository chosen at runtime — and it is a technique rather than an introduction to Declarative Pipeline.

Jenkins alternatives. Whether to still be on Jenkins in 2026 is a fair question and it is answered elsewhere on this site, in The DevOps Stack I’d Pick If I Started Over. This series assumes you have a Jenkins and it has to keep working, which is the situation most people are actually in.

How to read this

Inheriting an old instance: the versions guide to find out where you are, then Java compatibility and upgrade strategies to plan the way out. Take a copy of $JENKINS_HOME first.

Standing one up fresh: JCasC from day one. Retrofitting it onto a server configured by clicking is considerably more work than starting with it.

Already comfortable, want the sharp edges: security for where the risk actually is, and UserRemoteConfig if you have ever copy-pasted a pipeline to change one repository URL.