A plugin is an add-on that teaches Jenkins a new skill without changing the core program.

Let us start from the beginning. Jenkins is a free automation server that builds, tests and delivers software. A plugin is a small software package that you install into Jenkins to add a new ability. One plugin may add a new type of job. Another may add a new step for Pipelines. Another may add a login method, a new dashboard view or a connection to a cloud service.

Plugins are shared through the Update Center, an online catalogue that Jenkins reads. Inside Jenkins, you open the Plugin Manager, a screen where you can search the catalogue, install plugins, update them and remove them. Plugins are also listed on a public website where you can read their descriptions, see their version history and check whether they are actively maintained.

Why does Jenkins work this way? Because no single program can satisfy every team. A bank needs strict login rules and audit trails. A game studio needs to build for many consoles. A start-up needs cloud servers that appear and vanish. By keeping the core small and letting the community build the rest, Jenkins can fit all of them.

Categories turn a giant catalogue into a short checklist.

Trying to learn a thousand plugins one by one is impossible. But nearly every plugin belongs to a family that answers one simple question. Where does the code come from? How is it built? How is it tested? Where does it run? Who is allowed in? Who gets told? Where does it go at the end? Once you know the families, you can look at any Jenkins server and quickly understand what it is doing and what it is missing.

Categories also help you make good decisions. When a new need appears, you first ask, “Which category is this?” and then compare the well-known choices in that category instead of scrolling through an endless search result. And when a problem appears, categories tell you where to look. A build that cannot fetch code points to the source code family. A build that cannot log in points to the security family.

flowchart TD
    J["Jenkins core: queue, agents, steps, results"] --> C1["Source code management"]
    J --> C2["Pipeline and job types"]
    J --> C3["Build tools"]
    J --> C4["Agents and cloud"]
    J --> C5["Security and credentials"]
    J --> C6["Testing and quality"]
    J --> C7["Notifications"]
    J --> C8["Artifacts and deployment"]
    J --> C9["Administration and configuration"]
    J --> C10["Monitoring and visibility"]
    

Here is the whole map in one table before we visit each family in detail.

Every build starts with code. These plugins connect Jenkins to the place where the code lives.

Source code management, or SCM, means a system that stores your code and remembers every change ever made to it. Jenkins needs a plugin to talk to each such system.

A useful way to understand this family is to split it into two layers. The general plugin, Git, knows how to work with any Git repository. The host plugins, such as those for GitHub, GitLab and Bitbucket, add extras that exist only on those services: pull requests, organisation scanning, status marks and webhook handling.

These plugins decide how you describe the work: as a web form, or as code in a file.

A Pipeline describes your whole delivery journey, such as build, test and deploy, in a text file called a Jenkinsfile. Pipeline support is itself delivered as a group of plugins, though most installations already have them from the start.

The older Freestyle project, which you configure through a web form, is part of the Jenkins core and does not need a special plugin, though plugins add many options to its form. A more visual interface, sometimes seen in older tutorials under the name Blue Ocean, exists as a plugin family too, but it is no longer being actively developed, so newer teams generally rely on the standard interface and the Stage View instead.

Code must be compiled and packaged. Build tool plugins let Jenkins drive the tools that do this.

A build tool is a program that turns source code into something you can run. Each programming world has its own favourites. Jenkins can always run them through a plain command step, but tool plugins add extras such as managed installations, clean settings screens and reports.

Here is the key benefit: version control of tools. If one project needs an older compiler and another needs the newest, the tool plugins let each project name the version it wants, and Jenkins provides it. This avoids the classic “works on my machine” problem, in which a build passes on one agent and fails on another because the tool versions differ.

These plugins decide where builds run, and they are the key to scaling Jenkins.

Quick reminder of two words. The controller is the brain of Jenkins. An agent is a worker machine that does the actual building. Agent and cloud plugins help you create, connect and remove those workers.

The idea of dynamic agents is the star of this family. Instead of keeping many machines switched on all day, waiting for work, Jenkins creates an agent only when a build starts and destroys it when the build ends. Every build gets a fresh, clean worker, so leftovers from a previous build can never spoil the next. You also pay only for the time you actually use.

sequenceDiagram
    participant Dev as Developer
    participant C as Jenkins Controller
    participant K as Cloud or Kubernetes plugin
    participant A as Temporary Agent
    Dev->>C: Push code, build starts
    C->>K: Request a new agent
    K->>A: Create the agent
    A->>C: Connect and ask for work
    C->>A: Send the build steps
    A-->>C: Stream logs and results
    C->>K: Build finished, remove the agent
    K->>A: Delete the agent
    

A Jenkins server can reach your code, your secrets and your production systems. This family guards the doors.

Security plugins answer three questions. Authentication asks “Who are you?” Authorization asks “What are you allowed to do?” And secret handling asks “How do we keep passwords and keys safe?”

Think about how these fit together. A person opens Jenkins and signs in through the company login system (authentication plugin). Jenkins then checks the roles or the permission grid to decide what that person may see and change (authorization plugin). When a job needs to reach a private repository, it borrows a key from the vault (credentials plugin) and never shows it on screen.

A green build is only useful if it means the code is good. These plugins turn raw test output into clear, trackable results.

When tests run, they usually write their results into report files. By themselves, these files are hard to read. Testing and quality plugins read them and show summaries, trends and warnings right on the build page.

The idea of a quality gate deserves a mention. A quality gate is a rule that says “only good builds may continue”. For example, a Pipeline may stop if tests fail, if coverage drops below an agreed level, or if a code scanner finds serious problems. Testing and quality plugins provide the numbers that such gates depend on.

A failed build that nobody hears about is a wasted build. Notification plugins carry the news to people.

Good notification design is more about restraint than about volume. If Jenkins sends a message for every single build, people quickly learn to ignore it. A better pattern is to notify on failure, notify again when the build recovers, and stay quiet the rest of the time. Send the message to the person who caused the change, or to the team channel that can act on it.

Once code is built and tested, the result must be stored and delivered. This family handles the last mile.

An artifact is any file a build produces that you want to keep, such as a program package or a container image. Artifact plugins store these files. Deployment plugins send them to the place where they will run.

An important principle for this family is build once, promote many. Build the program a single time, store it, and then move that same file through testing, staging and production. What you tested is exactly what you ship. Artifact repositories make this possible by keeping a permanent, versioned home for every build result.

These plugins keep Jenkins tidy, repeatable and safe as it grows.

Among these, Configuration as Code is one of the most valuable for growing teams. Without it, a Jenkins server slowly turns into a “snowflake”, a machine tuned by hand over the years with settings that live only in someone’s memory. If it breaks, nobody can rebuild it. With Configuration as Code, the setup lives in a file, stored in a repository, and a new server can be created from that file.

A tool that watches your software must itself be watched, and its results must be easy to see.

For the health of Jenkins itself, the signals worth watching are the length and wait time of the build queue, the number of available agents, build duration trends, failure rates, disk space and how quickly the web page responds. Exporting these numbers to a monitoring tool lets you draw graphs and set alerts, so a person is warned before developers start complaining.

Real delivery uses several families at once. Following one change through the whole system shows how they combine.

flowchart LR
    A["Security: who signed in"] --> B["Source code plugins: fetch the code"]
    B --> C["Agents and cloud: start a clean worker"]
    C --> D["Build tool plugins: compile and package"]
    D --> E["Testing plugins: publish test results"]
    E --> F{"Quality gate passed?"}
    F -->|Yes| G["Artifact plugins: store the package"]
    G --> H["Deployment plugins: release"]
    F -->|No| I["Notification plugins: tell the team"]
    H --> J["Notification plugins: report success"]
    K["Administration plugins: timeouts, cleanup, folders"] -.-> C
    L["Monitoring plugins: metrics and dashboards"] -.-> C
    

With many similar plugins on offer, a short checklist helps you pick wisely.

flowchart TD
    N["I have a need"] --> Q1{"Can a plain command step do it simply?"}
    Q1 -->|Yes| S["Use the command step, no plugin"]
    Q1 -->|No| Q2{"Is there a well-maintained plugin?"}
    Q2 -->|No| R["Reconsider the approach or write a shared library step"]
    Q2 -->|Yes| Q3{"Any open security warnings?"}
    Q3 -->|Yes| R
    Q3 -->|No| T["Test on a practice Jenkins first"]
    T --> U["Install in production and record why"]
    

Getting plugins in is easy. Keeping them healthy takes a little routine.

Ways to install

• Through the Plugin Manager. Open the Available tab, search by name, tick the plugin and install. Jenkins downloads it and its dependencies.
• During first setup. Jenkins offers a suggested set of popular plugins, which is a good starting point for beginners.
• From a list file. Teams that build Jenkins in containers keep a text list of plugins and versions, and install exactly that list, so every new server is identical.
• By uploading a file. For offline servers or private plugins, an administrator can upload a plugin package directly.

Dependencies

A dependency is another plugin that a plugin needs in order to work. When you install one, Jenkins installs its dependencies too. This is convenient but has a cost: a plugin that seems small may quietly bring in a long chain of others. It also means that updating one plugin may require updating several.

flowchart TD
    P["Plugin you chose: Pipeline Stage View"] --> D1["Depends on: Pipeline core"]
    D1 --> D2["Depends on: Workflow API plugins"]
    D2 --> D3["Depends on: Support libraries"]
    P --> D4["Depends on: Jenkins core version"]
    

A safe update routine

The plugin model is Jenkins’ greatest strength and its most common source of trouble.

The main trade-off is flexibility versus maintenance. Every plugin you add makes Jenkins more capable and slightly more fragile. The healthy path is to be generous with categories that are essential, such as source code, security and testing, and strict with anything that is merely nice to have.

Plugins run inside Jenkins with real power. Treat them as part of your security perimeter.

A pattern is a proven habit. An anti-pattern is a tempting shortcut that causes pain later.

Patterns worth copying

Anti-patterns to avoid

A few steady habits decide whether the plugin ecosystem helps you or hurts you.

Best practices

• Think in categories first. Decide the family of your need, then compare the well-known plugins in it.
• Check maintenance and security before installing. Look at release dates, install counts and advisories.
• Keep a written list. Record every plugin and why it exists.
• Update on a schedule. Small, regular updates are safer than rare giant ones.
• Always back up before changes. A rollback plan turns a disaster into an inconvenience.
• Test on a practice server. Never learn about a broken update on the live system.
• Limit who can install plugins. A plugin has nearly unlimited power inside Jenkins.
• Prune regularly. Remove unused plugins and retire deprecated ones.
• Watch startup time and page speed. Slow screens are often a sign of too many plugins.

Common mistakes

Different teams combine categories in different ways. Here are some common shapes.

Jenkins is small by design and grows through plugins. Instead of memorising a thousand names, you can remember a handful of families, each answering one practical question: where the code comes from, how work is described, how it is built, where it runs, who may enter, how quality is measured, who is told, where results go, how the server is kept tidy, and how its health is watched.

Thinking in categories makes choices easier and problems easier to locate. But every plugin is also a small responsibility, since it must be kept updated, secured and compatible with the rest. Teams that choose plugins deliberately, keep a written list, test updates before applying them and prune what they do not need enjoy the power of Jenkins without its usual headaches.