The Jenkins controller is the central server component that manages the entire Jenkins environment, including configuration, job scheduling, plugin management, and user authentication, while delegating actual build execution to agents
The Jenkins controller (previously called master) is the core component of a Jenkins installation that acts as the central management hub. It runs as a Java process, typically on a dedicated server, and provides the web interface that users interact with. The controller is responsible for storing all configuration data, managing plugins, authenticating users, scheduling build jobs, and orchestrating the entire CI/CD workflow.
The controller performs several critical functions in a Jenkins environment. It maintains the Jenkins home directory, which contains all configuration files, job definitions, build logs, and artifacts. It runs the web server that serves the Jenkins UI on port 8080 by default, providing a dashboard for managing jobs, viewing build results, and configuring the system. The controller also manages the queue of pending builds, deciding when and on which agent to execute each job.
Configuration Management: Stores and manages all Jenkins configurations, including global settings, job definitions, credentials, and plugin configurations .
Job Scheduling: Maintains a build queue and decides when to trigger jobs based on schedules, webhooks, or manual requests .
Agent Coordination: Manages connections to agents, assigns jobs to appropriate nodes, and collects build results .
Plugin Management: Loads, initializes, and manages the lifecycle of all installed plugins .
User Authentication and Authorization: Handles user login, permissions, and access control for different Jenkins resources .
Artifact Storage: Stores build outputs, logs, and test reports for historical reference and debugging .
The Jenkins controller runs as a Java application with a web server (Jetty) embedded. It maintains an internal thread pool for handling HTTP requests and a separate execution engine for managing builds. The controller's JVM typically requires sufficient memory allocated (often 2-4GB minimum for production use) to handle concurrent builds and web requests. It uses the filesystem for persistent storage, with the JENKINS_HOME directory containing all configuration and data.
To maintain optimal performance and security, Jenkins administrators should follow several best practices for the controller. The controller should never run builds itself—set the number of executors on the built-in node to 0 and delegate all build work to dedicated agents. Regular backups of JENKINS_HOME are essential for disaster recovery. Monitoring the controller's disk space, memory usage, and CPU load helps identify potential bottlenecks before they impact users.
For mission-critical environments, a single Jenkins controller represents a single point of failure. High availability can be achieved through warm standby controllers with shared JENKINS_HOME on distributed filesystems (NFS), combined with load balancers and database-backed job history plugins. However, true active-active clustering remains challenging due to Jenkins' filesystem-based storage model, so many organizations implement automated failover strategies instead.
The Jenkins project officially replaced the term 'master' with 'controller' in 2020 to promote more inclusive language. While older documentation and many existing installations still use 'master', new documentation and future versions adopt 'controller'. Both terms refer to the same central Jenkins server component.