Jenkins Course
Plugin Management
Installing a plugin takes 30 seconds. Managing 80 plugins across a production Jenkins server — keeping them updated, compatible, and secure — is a different skill entirely. This lesson covers both.
This lesson covers
Installing plugins via the UI → Installing via the CLI → The Plugin Manager screen → Updating safely → Pinning versions → Disabling and uninstalling → Identifying security vulnerabilities → Plugin management as code
Most Jenkins problems that aren't pipeline bugs are plugin problems — a plugin update that breaks an existing pipeline step, a security advisory on an outdated plugin, or a conflict between two plugins that both try to override the same behaviour. Understanding plugin management properly keeps your Jenkins stable and secure.
The Analogy
Plugins are like apps on a smartphone. A fresh Jenkins install is a blank screen — barely useful on its own. Plugins are where the power comes from. But just like phone apps, plugins need updating, some become abandoned, some have security holes, and occasionally two plugins clash in ways that break everything. The skill is in curating them — not just installing them.
The Plugin Manager — Your Control Panel
The Plugin Manager lives at Manage Jenkins → Plugin Manager. It has four tabs — each serving a different purpose:
Updates tab
Shows which installed plugins have newer versions available. Red "Security" badge means the update patches a known vulnerability — prioritise these.
Available tab
Search and install new plugins. Over 1,800 available. Use the search box — scrolling the full list is not practical.
Installed tab
Lists every installed plugin with its version and enabled/disabled status. Use this for auditing and for disabling plugins you no longer need.
Advanced tab
Upload a plugin .hpi file manually, configure a custom update centre URL, or force a plugin list refresh. Used for air-gapped environments and private plugin repositories.
Installing a Plugin — Step by Step
The UI method is the right choice for one-off installs on a server you're actively managing. Here's the complete flow:
Manage Jenkins → Plugin Manager → Available plugins
Type the plugin name in the search box. The list filters as you type.
Tick the checkbox next to the plugin you want
You can select multiple plugins at once. Jenkins resolves dependencies automatically — if Plugin A requires Plugin B, both will be installed.
Click "Install without restart" or "Download now and install after restart"
"Install without restart" works for most plugins. Some plugins require a Jenkins restart to activate — the UI will tell you which ones.
Verify on the Installed tab
After installation, go to Installed plugins and confirm the plugin appears with status "Enabled". If it shows "Disabled", click Enable.
Installing and Managing Plugins via the CLI
For scripted setups, automation, or managing plugins across multiple Jenkins servers, the CLI is far more powerful than clicking through the UI one plugin at a time.
The scenario:
You're a platform engineer setting up a new Jenkins instance for the infrastructure team. You need to install six specific plugins, check which installed plugins have security advisories, and disable a plugin that's no longer needed — all from the terminal without touching the browser.
Tools used:
- jenkins-cli.jar — Jenkins' command-line tool. Download from
http://YOUR-JENKINS/jnlpJars/jenkins-cli.jar. - install-plugin — a CLI command that installs one or more plugins by their short name (the ID used in the plugin marketplace, not the display name).
- list-plugins — lists every installed plugin with its version. Pipe through
grepto filter for specific plugins. - disable-plugin — disables a plugin without uninstalling it. Safer than uninstalling — the plugin can be re-enabled without reinstalling if you change your mind.
- enable-plugin — re-enables a previously disabled plugin.
- restart — safely restarts Jenkins. Waits for running builds to finish before restarting (safe restart).
# Shorthand for the CLI command — saves typing the full java command every time
JENKINS_CLI="java -jar jenkins-cli.jar -s http://jenkins-master-01:8080 -auth admin:your-api-token"
# Install multiple plugins by their short IDs in one command
# Find a plugin's short ID at https://plugins.jenkins.io — it's in the URL
# e.g. https://plugins.jenkins.io/git/ → short ID is 'git'
$JENKINS_CLI install-plugin \
git \
docker-workflow \
kubernetes \
slack \
pipeline-stage-view \
blueocean
# List all installed plugins and their versions
# Useful for auditing what's installed before an update or migration
$JENKINS_CLI list-plugins
# Filter for a specific plugin — check what version of git is installed
$JENKINS_CLI list-plugins | grep "^git "
# Disable a plugin you no longer need
# Disabled plugins are inactive but stay on disk — easy to re-enable
$JENKINS_CLI disable-plugin cobertura
# Re-enable a plugin that was previously disabled
$JENKINS_CLI enable-plugin cobertura
# Safe restart — waits for running builds to finish before restarting
# Use this after installing plugins that require a restart
$JENKINS_CLI safe-restartWhere to practice: Download jenkins-cli.jar from http://localhost:8080/jnlpJars/jenkins-cli.jar on your local Jenkins. Run list-plugins first to see what's already installed. Then try installing a simple plugin like timestamper. Full plugin short ID list at plugins.jenkins.io.
Installing git Installing docker-workflow Installing kubernetes Installing slack Installing pipeline-stage-view Installing blueocean Installation successful # list-plugins output (excerpt): git 5.2.1 docker-workflow 1.27 kubernetes 3845.v7b_a_73e04b_deb_ slack 2.51 pipeline-stage-view 2.33 blueocean 1.27.4 # grep result: git 5.2.1 # disable-plugin output: Disabling cobertura Plugin cobertura disabled — restart required to take effect # safe-restart output: Waiting for running builds to complete... No running builds — restarting Jenkins now Restarting...
What just happened?
- All six plugins installed in one command — the CLI resolved dependencies automatically. If any of those plugins required another plugin, Jenkins installed it too without prompting.
list-pluginsshows short IDs and versions — this output is the basis of your plugin audit. Save it to a file before any major update:$JENKINS_CLI list-plugins > plugins-before-update.txt. After the update, diff the two files to see exactly what changed.- Disabling requires a restart — some plugins hook into Jenkins' core at startup. Disabling them takes effect only after Jenkins restarts. The safe-restart command handled that cleanly by waiting for running builds first.
- The kubernetes plugin version string looks odd —
3845.v7b_a_73e04b_deb_is an incrementals-style version number. Jenkins plugins don't always use semantic versioning. The number before the dot is a build counter, not a semantic version. Higher = newer.
Updating Plugins Safely
Plugin updates are the most common source of "it was working yesterday" problems in Jenkins. The safe update workflow has three rules: always back up first, always test on staging, never update everything at once.
Step 1 — Back up JENKINS_HOME before any update
If a plugin update breaks something and you can't roll back, you need the backup. This is not optional. Even a quick tar -czf jenkins-backup.tar.gz /var/lib/jenkins before updating is better than nothing.
Step 2 — Read the changelog before updating
Click the plugin name in the Updates tab — it links to the plugin's changelog on plugins.jenkins.io. Look for "breaking changes" or "removed feature" entries. These are the updates that break pipelines.
Step 3 — Update on a staging Jenkins first
Run your most critical pipelines on the staging Jenkins after the update. If they pass, update production. If they fail, you have a clean production server and time to investigate without pressure.
Step 4 — Update security advisories first, everything else separately
Security advisory updates (the red badge) are urgent — update these immediately and separately from feature updates. Mixing security and feature updates makes it harder to identify which update caused a problem.
Plugins as Code — plugins.txt
If you're running Jenkins in Docker or building Jenkins images for your team, you can define your plugin list as a text file and install everything automatically at container startup. This is the reproducible, version-controlled way to manage plugins — no clicking required.
Tools used:
- plugins.txt — a plain text file listing one plugin per line in the format
plugin-id:version. Pinning to a specific version ensures every Jenkins instance installs exactly the same plugin version — no surprises. - jenkins-plugin-cli — the official Jenkins plugin installation tool built into the Jenkins Docker image. It reads
plugins.txtand installs everything listed, resolving dependencies automatically. - Dockerfile — the file that defines how to build a custom Jenkins Docker image with your plugins pre-installed. Teams build this image once and deploy it across all Jenkins instances.
# plugins.txt — pin every plugin to a specific version
# Format: plugin-short-id:version
# Find versions at https://plugins.jenkins.io//releases/
# Update versions deliberately — not automatically
git:5.2.1
docker-workflow:1.27
kubernetes:3845.v7b_a_73e04b_deb_
slack:2.51
pipeline-stage-view:2.33
blueocean:1.27.4
credentials:1319.v7eb_51b_3a_c97b_
timestamper:1.26
ws-cleanup:0.45
workflow-aggregator:596.v8c21c963d92d # Dockerfile — build a custom Jenkins image with pre-installed plugins
FROM jenkins/jenkins:2.440.1-lts-jdk21
# Switch to root to install plugins (jenkins-plugin-cli needs write access)
USER root
# Copy the plugins list into the image
COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
# Install all plugins listed in plugins.txt
# --plugin-file reads the list · --verbose shows progress
RUN jenkins-plugin-cli \
--plugin-file /usr/share/jenkins/ref/plugins.txt \
--verbose
# Switch back to the jenkins user — never run Jenkins as root
USER jenkins$ docker build -t acmecorp/jenkins:2.440.1 . Step 1/5 : FROM jenkins/jenkins:2.440.1-lts-jdk21 Step 2/5 : USER root Step 3/5 : COPY plugins.txt /usr/share/jenkins/ref/plugins.txt Step 4/5 : RUN jenkins-plugin-cli --plugin-file /usr/share/jenkins/ref/plugins.txt --verbose Installing git (5.2.1) and its 3 dependencies... Installing docker-workflow (1.27) and its 2 dependencies... Installing kubernetes (3845.v7b_a_73e04b_deb_) and its 8 dependencies... Installing slack (2.51) and its 1 dependencies... Installing pipeline-stage-view (2.33) and its 2 dependencies... Installing blueocean (1.27.4) and its 12 dependencies... Installing credentials (1319.v7eb_51b_3a_c97b_)... Installing timestamper (1.26)... Installing ws-cleanup (0.45)... Installing workflow-aggregator (596.v8c21c963d92d)... All plugins installed successfully. Step 5/5 : USER jenkins Successfully built a4b7c2d9e3f1 Successfully tagged acmecorp/jenkins:2.440.1
What just happened?
- Every plugin pinned to an exact version — the image always installs exactly these versions. Rebuild the image six months later and you get the same plugins. No surprise updates, no broken pipelines from an automated version bump.
- Dependencies resolved automatically — the kubernetes plugin has 8 dependencies.
jenkins-plugin-clifound and installed all of them without you having to list them manually inplugins.txt. Only list the plugins you explicitly need. - The image is now reproducible — store this Dockerfile and plugins.txt in Git alongside your Jenkinsfile. Any engineer can rebuild the exact same Jenkins environment from scratch. When you need to upgrade a plugin, update the version in
plugins.txt, rebuild the image, test it, then deploy. USER jenkinsat the end — Jenkins should never run as root inside the container. Switching back ensures the Jenkins process has limited permissions even if a pipeline step tries something malicious.
Teacher's Note
The plugins.txt approach is the single most impactful thing you can do for Jenkins reproducibility. If your Jenkins dies, you rebuild the image and you're back in minutes — not hours.
Practice Questions
1. Which Jenkins CLI command deactivates a plugin without removing it from disk — so it can be re-enabled later if needed?
2. What is the name of the file used to define a list of pinned plugins for automatic installation when building a custom Jenkins Docker image?
3. Which Jenkins CLI command restarts Jenkins but waits for all currently running builds to finish first?
Quiz
1. Where in the Jenkins UI do you find plugins that have known security vulnerabilities and need urgent updates?
2. What is the main benefit of using a pinned plugins.txt file in a Jenkins Docker image?
3. What is the safe plugin update workflow?
Up Next · Lesson 28
Jenkins Security Model
Authentication, authorisation, CSRF protection, and the security settings every production Jenkins must have configured before it goes near a network.