What Are the Main Components of Jenkins? Core Architecture Explained

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. 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, 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 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, 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 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. 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. 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. 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. 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:

// 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:

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

Using the REST API to check build status:

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:

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) serves as the global configuration holder and plugin coordinator.
• Executors (Executor.java) are threads that execute build logic, while Computers (Computer.java) represent the physical or virtual agents hosting these threads.
• Jobs (Job.java) define work statically, and Runs (Run.java) track individual executions with their artifacts and logs.
• The Plugin Manager (PluginManager.java) enables runtime extension of capabilities without core code changes.
• Security Realms (SecurityRealm.java) provide pluggable authentication mechanisms.
• The Pipeline Engine (WorkflowJob.java) supports code-defined workflows that execute across the distributed architecture.
• FilePath (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) 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) 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.

What is the Jenkins Pipeline Engine?

The Pipeline Engine (implemented in 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}