# What Are the Main Components of Jenkins? Core Architecture Explained

> Understand the core Jenkins architecture learn about its master node agents job system and plugin architecture for efficient CI/CD management.

- Repository: [Jenkins/jenkins](https://github.com/jenkinsci/jenkins)
- Tags: architecture
- Published: 2026-07-29

---

**Jenkins consists of a central master node that manages configuration and scheduling, remote agents that execute builds via thread-based executors, a job and build lifecycle system for defining and tracking work, and a dynamic plugin architecture that extends functionality without modifying core source code.**

Jenkins is an open-source automation server written in Java that coordinates continuous integration and delivery pipelines. The main components of Jenkins form a modular architecture where a thin core delegates work to distributed agents while the plugin system provides extensibility for source control, build tools, and deployment targets.

## Jenkins Core: The Central Orchestrator

At the heart of the system lies **Jenkins Core**, implemented as a singleton in [`core/src/main/java/jenkins/model/Jenkins.java`](https://github.com/jenkinsci/jenkins/blob/main/core/src/main/java/jenkins/model/Jenkins.java). This class extends `Hudson` and serves as the central registry for all configuration, plugin lifecycle management, and the servlet container integration point. The core maintains the global configuration XML, manages the queue of pending builds, and provides the extension points that allow plugins to integrate seamlessly with the platform.

## Execution Infrastructure: Agents and Executors

Jenkins distributes work across a master-agent architecture using two primary abstractions:

**Executors (`hudson.model.Executor`)**

Defined in [`core/src/main/java/hudson/model/Executor.java`](https://github.com/jenkinsci/jenkins/blob/main/core/src/main/java/hudson/model/Executor.java), an executor represents a thread that performs the actual build work. Each executor occupies one build slot on a node, and the executor thread is responsible for running the build logic, capturing console output, and updating build status in real-time.

**Computers and Agents (`hudson.model.Computer`)**

The `Computer` class in [`core/src/main/java/hudson/model/Computer.java`](https://github.com/jenkinsci/jenkins/blob/main/core/src/main/java/hudson/model/Computer.java) abstracts the machine where builds run. Historically referred to as "slaves" and now called "agents," these remote JVMs connect to the master and report their available executors, labels, and resource capabilities. The master schedules jobs onto computers based on label matching and load balancing.

## Job and Build Lifecycle

Work in Jenkins is structured around a clear separation between definition and execution:

**Job Definitions (`hudson.model.Job`)**

Located in [`core/src/main/java/hudson/model/Job.java`](https://github.com/jenkinsci/jenkins/blob/main/core/src/main/java/hudson/model/Job.java), this abstract class represents the static configuration of a project—including SCM settings, triggers, parameters, and build steps. Concrete implementations include freestyle projects, Maven jobs, and pipeline definitions.

**Build Executions (`hudson.model.Run`)**

The `Run` class in [`core/src/main/java/hudson/model/Run.java`](https://github.com/jenkinsci/jenkins/blob/main/core/src/main/java/hudson/model/Run.java) represents a single execution instance of a job. Each build obtains a unique workspace directory, executes the configured steps, and persists results including logs, artifacts, and test reports. The `Run` object lifecycle tracks the build from queueing through completion.

## The Plugin Architecture

Extensibility is provided through the **Plugin System**, centralized in [`core/src/main/java/hudson/model/PluginManager.java`](https://github.com/jenkinsci/jenkins/blob/main/core/src/main/java/hudson/model/PluginManager.java). This component handles dynamic loading of `.hpi` (or `.jpi`) files, dependency resolution between plugins, and lifecycle callbacks for initialization and shutdown. Plugins contribute to the UI via Jelly/Groovy views, add new build steps, and register extension points using annotations.

## Security and Access Control

The **Security Subsystem** implements pluggable authentication and authorization through [`core/src/main/java/hudson/security/SecurityRealm.java`](https://github.com/jenkinsci/jenkins/blob/main/core/src/main/java/hudson/security/SecurityRealm.java). This abstraction allows Jenkins to integrate with LDAP, Active Directory, SAML, or OAuth providers without core modifications. The security layer also handles CSRF protection and API token management for programmatic access.

## Pipeline Engine (Workflow)

Modern Jenkins usage relies heavily on the **Pipeline Engine**, implemented in [`workflow/job/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowJob.java`](https://github.com/jenkinsci/jenkins/blob/main/workflow/job/src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowJob.java). This component interprets `Jenkinsfile` scripts written in Groovy and orchestrates complex workflows across multiple agents. Unlike traditional jobs that configure steps through the UI, pipeline jobs store their definition as code and execute through a durable task engine that survives master restarts.

## Workspace and Artifact Management

File operations on remote agents are abstracted through [`core/src/main/java/hudson/FilePath.java`](https://github.com/jenkinsci/jenkins/blob/main/core/src/main/java/hudson/FilePath.java). This class provides a sandboxed view of the filesystem that works transparently across master and agent boundaries, handling workspace creation, artifact archiving, and remote file copying via the agent channel protocol.

## Interacting with Jenkins Components Programmatically

You can inspect and manipulate these components using Groovy scripts or the REST API.

**Querying installed plugins via the Script Console:**

```groovy
// Access the Jenkins singleton and iterate through PluginManager
Jenkins.instance.pluginManager.plugins.each { p ->
    println "${p.shortName} : ${p.version}"
}

```

This script accesses the `PluginManager` through `Jenkins.instance`, demonstrating how the core singleton provides access to the plugin registry.

**Triggering a build programmatically:**

```groovy
def job = Jenkins.instance.getItemByFullName('MyProject')
job.scheduleBuild2(0)   // Queue build with 0-second quiet period

```

**Using the REST API to check build status:**

```bash
curl -s http://localhost:8080/job/MyProject/api/json | jq '.lastBuild.result'

```

The REST layer exposes the same object model used internally, allowing external tools to query `Job` and `Run` states without direct Java access.

**Defining a Pipeline in a Jenkinsfile:**

```groovy
pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean compile'
            }
        }
    }
}

```

This declarative syntax is processed by the Pipeline Engine (`WorkflowJob`), which allocates an `Executor` on an available `Computer` to run the steps.

## Summary

- **Jenkins Core** ([`Jenkins.java`](https://github.com/jenkinsci/jenkins/blob/main/Jenkins.java)) serves as the global configuration holder and plugin coordinator.
- **Executors** ([`Executor.java`](https://github.com/jenkinsci/jenkins/blob/main/Executor.java)) are threads that execute build logic, while **Computers** ([`Computer.java`](https://github.com/jenkinsci/jenkins/blob/main/Computer.java)) represent the physical or virtual agents hosting these threads.
- **Jobs** ([`Job.java`](https://github.com/jenkinsci/jenkins/blob/main/Job.java)) define work statically, and **Runs** ([`Run.java`](https://github.com/jenkinsci/jenkins/blob/main/Run.java)) track individual executions with their artifacts and logs.
- The **Plugin Manager** ([`PluginManager.java`](https://github.com/jenkinsci/jenkins/blob/main/PluginManager.java)) enables runtime extension of capabilities without core code changes.
- **Security Realms** ([`SecurityRealm.java`](https://github.com/jenkinsci/jenkins/blob/main/SecurityRealm.java)) provide pluggable authentication mechanisms.
- The **Pipeline Engine** ([`WorkflowJob.java`](https://github.com/jenkinsci/jenkins/blob/main/WorkflowJob.java)) supports code-defined workflows that execute across the distributed architecture.
- **FilePath** ([`FilePath.java`](https://github.com/jenkinsci/jenkins/blob/main/FilePath.java)) manages workspace isolation and remote file operations.

## Frequently Asked Questions

### What is the difference between a Jenkins Master and Agent?

The **master** runs the Jenkins Core ([`Jenkins.java`](https://github.com/jenkinsci/jenkins/blob/main/Jenkins.java)) and handles the web UI, configuration persistence, build scheduling, and plugin management. **Agents** (represented by `Computer` instances) are separate processes—often on remote machines—that host executors and perform the actual build work. The master delegates build execution to agents via the Remoting protocol, keeping the core lightweight and allowing horizontal scaling of build capacity.

### How does the Jenkins Plugin System work?

Plugins are packaged as `.hpi` files containing Java classes, Jelly views, and manifest metadata. The **Plugin Manager** ([`PluginManager.java`](https://github.com/jenkinsci/jenkins/blob/main/PluginManager.java)) loads these into a separate classloader hierarchy at startup or dynamically at runtime. Plugins contribute functionality by implementing Extension Points—annotated Java interfaces that the core queries at runtime. This allows plugins to add new job types, build steps, and UI elements without modifying [`Jenkins.java`](https://github.com/jenkinsci/jenkins/blob/main/Jenkins.java).

### What is the Jenkins Pipeline Engine?

The **Pipeline Engine** (implemented in [`WorkflowJob.java`](https://github.com/jenkinsci/jenkins/blob/main/WorkflowJob.java) and related workflow plugins) interprets Groovy-based `Jenkinsfile` scripts to define continuous delivery pipelines as code. Unlike traditional freestyle jobs configured through the UI, pipeline jobs use the **Durable Task** system to survive master restarts and can orchestrate complex workflows across multiple agents. The engine extends the standard `Job` and `Run` classes to support stage visualization and parallel execution.

### How does Jenkins manage build workspaces and artifacts?

Each `Run` object allocates a unique **workspace** directory on the executing agent, isolated via `FilePath` operations to prevent interference between concurrent builds. Build outputs designated as **artifacts** are copied from the agent's workspace back to the master's `JENKINS_HOME` directory (or external artifact repositories) according to the job configuration. The `FilePath` class abstracts local and remote filesystem operations, ensuring consistent behavior whether running on the master or distributed agents.