Background: Why Jenkins Needed a Strategic Shift

Jenkins is one of the most widely adopted open-source automation servers in the DevOps ecosystem. Released in 2011, it has grown to support hundreds of plugins and serves millions of users across thousands of contributing developers worldwide. Its extensibility made it powerful, but that same extensibility introduced systemic problems as enterprise workloads scaled.

As enterprises began running larger workloads, loading more plugins simultaneously, and demanding higher availability, several recurring pain points emerged:

• Service instability: Many projects required frequent restarts due to resource issues and plugin upgrade cycles. Each restart degraded service for delivery teams, delaying build starts and completions—unacceptable for organizations treating CI/CD as mission-critical infrastructure.
• Brittle configuration: Administrators grew reluctant to make configuration changes, fearing downstream breakage for software delivery teams. Changes spanning multiple plugins were particularly risky, since users rarely upgrade all affected components simultaneously.
• Fragile plugin deployment: Contributors lacked confidence that shipping new code would run safely in automated pipelines without causing regressions across plugin dependencies.

The Two-Pronged Response: Cloud-Native Jenkins and the Jolt Initiative

Kohsuke Kawaguchi outlined two complementary initiatives to address these issues. Rather than patching over existing limitations, the approach involves both a architectural reinvention and an accelerated improvement of the existing Jenkins 2 platform.

1. Cloud-Native Jenkins

Cloud-Native Jenkins is designed as a general-purpose CI/CD engine built to run natively on Kubernetes. It represents a fundamental rethinking of Jenkins architecture rather than an incremental update. Key characteristics include:

• Kubernetes-native architecture: Functionality is decomposed into separate microservices. Services interact through Kubernetes Custom Resource Definitions (CRDs), leveraging Kubernetes-native primitives rather than Jenkins-internal mechanisms.
• Serverless execution model: By embracing Kubernetes’s approach to workload scheduling, Cloud-Native Jenkins targets a pay-as-you-go cost model, where compute is consumed only when needed.
• Immutability and zero-downtime operations: Moving away from mutable, file-system-based state enables immutable deployments and eliminates the need for disruptive restarts.
• Cloud-managed data storage: Jenkins is moving data storage away from the local file system toward cloud-managed data services. This shift enables high availability and horizontal scalability that file-system storage fundamentally cannot provide.
• Configuration as Code: Addressing brittle configuration directly, Cloud-Native Jenkins incorporates Configuration as Code principles to make system state declarative, auditable, and reproducible.
• Redesigned extensibility: A new extensibility mechanism replaces the traditional plugin model to reduce service instability caused by incompatible plugin interactions.
• Security improvements: The initiative also targets security vulnerabilities that stem from architectural design decisions in the original Jenkins codebase—issues that cannot be patched without deeper structural changes.

Kawaguchi noted that part of the motivation for Cloud-Native Jenkins is to align Jenkins with Jenkins X, the opinionated Kubernetes-native CI/CD project. As he explained:

“Cloud Native Jenkins will be the general-purpose CI/CD engine that runs on Kubernetes, which Jenkins X uses to create an opinionated CD experience for developing cloud native apps.”

— Kohsuke Kawaguchi, creator of Jenkins, CTO of CloudBees

2. Injecting a “Jolt” into Jenkins 2

Because Cloud-Native Jenkins targets a specific subset of Jenkins use cases, the team recognised that the large installed base of Jenkins 2 users still needs active investment. The “jolt” initiative continues along the incremental trajectory of Jenkins 2, with a focus on:

• Accelerated development velocity: Moving faster on improvements and fixes, even if it requires some breaking changes along the way.
• Better stability for production workloads: Serving the enterprise teams already running Jenkins 2 in production with improvements to reliability and scalability.
• Continued plugin ecosystem support: Preserving the extensive plugin compatibility that makes Jenkins 2 viable for such a broad range of workloads.

What This Means for Jenkins Operators and Teams

For teams currently running Jenkins 2 on traditional infrastructure, the jolt initiative means improvements are coming to the platform they already operate—without requiring a full migration. For teams already investing in Kubernetes-native delivery pipelines, Cloud-Native Jenkins and its relationship with Jenkins X represents a path toward a more scalable, operationally resilient CI/CD architecture.

The two-initiative approach reflects a pragmatic acknowledgment that Jenkins serves enormously diverse workloads. A single migration path would not serve the community effectively. By running both tracks simultaneously, the Jenkins project aims to move its architecture forward without leaving production users behind.

Key Takeaways

• Jenkins is addressing service instability and brittle configuration through two complementary initiatives, not a single replacement strategy.
• Cloud-Native Jenkins targets Kubernetes-based environments with a microservices architecture, CRD-based extensibility, and cloud-managed storage.
• The Jenkins 2 “jolt” initiative continues to improve stability and velocity for the existing installed base.
• Configuration as Code and a new extensibility model are central to resolving the architectural pain points that cannot be fixed with plugin patches alone.
• Cloud-Native Jenkins is designed to serve as the underlying engine for Jenkins X, bridging general-purpose CI/CD with opinionated Kubernetes-native delivery.