Open-source alternative to the CloudBees CI operations center for many controllers
If you run many Jenkins controllers under CloudBees CI and face a renewal, a cost increase or a data residency question, community Jenkins can cover the operations center's provisioning role with Configuration as Code, the official Helm chart, a secrets manager and a controller-per-team pattern. Central governance, meaning uniform access rules, audit visibility and fleet-wide policy, needs extra work that you would design and own yourself. Jenkins itself is distributed under the MIT License, while the operations center is a CloudBees feature rather than part of Jenkins core, so the replacement is a design decision you carry, not a drop-in product.
In practice, each team gets its own controller defined as code. The Configuration as Code plugin reads YAML from the location set by CASC_JENKINS_CONFIG (default $JENKINS_HOME/jenkins.yaml), and the plugin does not install plugins, so your plugin list must come from Docker images or the Helm chart. Credentials should live in an external secrets manager rather than in each controller's $JENKINS_HOME, because the scaling guide places configuration, plugins and secrets on the controller and that becomes your backup scope. Start by inventorying which controllers depend on CloudBees-only features, then confirm each plugin's status against the current LTS changelog before you standardize images.
Before you commit, confirm with your own environment and with CloudBees which operations center behaviors your teams rely on: centrally pushed controller templates, role-based access control across controllers, and audit trails for administrative changes. Open-source plugins can cover parts of these, but you should test them against your identity provider and record the gaps in a written risk register, which auditors and your security team will ask for.
Which operations center capabilities map to open-source Jenkins
This table maps each main operations center function to the open-source Jenkins option that covers it, and marks where coverage is partial or needs confirmation in your environment. Read each row as the replacement pattern plus the gap you will still own, not as a one-to-one feature match.
| Operations center capability | Open-source option | Coverage and what to confirm |
|---|---|---|
| Controller provisioning | Helm chart on Kubernetes, one controller per team or project, following the scaling guide's horizontal model | Provisioning is scripted from your own Helm values, so no central UI exists. Confirm who approves new controllers and how their configuration is reviewed. |
| Central configuration | Configuration as Code plugin reading YAML from CASC_JENKINS_CONFIG, stored in Git | Strong coverage for system and security settings. Plugins are not installed by this plugin, so pin them in the image or Helm values and confirm each one is configured. |
| Plugin management | Plugins baked into a versioned controller image, with the plugin manager for updates | Manual process. Track CloudBees-only plugins during inventory, and confirm license and support terms for each open-source plugin you rely on. |
| Shared credentials | External secrets manager plugin or Kubernetes secrets injected at startup, with credentials scoped to folders | Secrets stay out of $JENKINS_HOME only if you configure the store that way. Confirm rotation ownership, audit logging and how the store is backed up. |
| Role-based access and folder authorization | Open-source authorization plugins such as Role-based Authorization Strategy with folder roles | Covers team-level separation well. Fine-grained global policy across many controllers is not centralized, so confirm how drift between controllers is detected. |
| Backup and restore | Back up $JENKINS_HOME on each controller, plus the Git repository holding Configuration as Code and Helm values | The scaling guide places configuration, plugins and secrets in $JENKINS_HOME, so backup is per controller. Test restore on each one, since no central backup view exists. |
| Upgrades and LTS baseline | Upgrade on the LTS release line, one controller at a time, rolled through a staging controller first | Operations center schedules and gates upgrades centrally. Here you run the sequence yourself, and LTS changes such as bundled plugin removals need checking per controller. |
| Central monitoring and health | Prometheus and Grafana dashboards per controller, plus alerting on build queue and agent health | Fleet view must be assembled from separate sources. Confirm which metrics your monitoring stack collects and who owns alert response. |
Which open-source building blocks replace the operations center
The CloudBees operations center manages many controllers from one place. Open-source Jenkins splits that job across several parts: version-controlled configuration, a Helm-based deployment, a secrets manager, and a team-by-team controller layout. Each part covers some of the operations center's work and leaves some governance to your own processes.
Configuration as Code
The Configuration as Code plugin reads YAML files located through the CASC_JENKINS_CONFIG variable, which defaults to $JENKINS_HOME/jenkins.yaml. Keep those files in Git so every controller's security realm, authorization, agents and system settings are reviewed like any other change. It does not install plugins. Plugin versions must be pinned separately, through Docker images or the Helm chart, or controllers will drift from their declared configuration.
Official Helm chart and Kubernetes plugin
The official Jenkins Helm chart deploys controllers from versioned values files, so each team's controller can be created from one template. The Kubernetes plugin starts build agents as pods on demand and removes them afterward. The trade-off is operational: your platform team owns the cluster, chart upgrades and agent pod templates that the operations center used to handle. Confirm which chart version and plugin set your upgrade path supports before you commit.
Secrets manager for shared credentials
CloudBees stores credentials inside the operations center's domain. In open-source Jenkins, shared credentials can come from an external secrets manager, so the controller fetches them at build time rather than holding copies. This narrows the blast radius of a controller compromise and keeps rotation in one place. The trade-off is availability: a secrets manager outage stops builds that depend on it. Check how each plugin caches values and who can read the secrets path.
Controller-per-team with dedicated agents
Jenkins scales by adding controllers for new teams or projects, which isolates plugins, credentials and job namespaces by team. Build work moves to dedicated agents so each controller only handles HTTP requests and manages the build environment. This removes the operations center's central view. Expect to maintain your own inventory of controllers, their plugin versions and their owners, and to build any cross-team reporting you still need.
Plugin bundling checklist
Jenkins LTS 2.580.1 stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins. Before you upgrade, list every plugin your controllers use, then install any bundled-only plugin through the plugin manager so builds do not fail after the upgrade. Record the result in your Configuration as Code files. Treat this list as part of each controller's change record, not a one-time task.
How Configuration as Code replaces central controller configuration
The CloudBees operations center pushes shared configuration from one console to every managed controller. With Configuration as Code, the same idea moves into files: each controller reads its own jenkins.yaml, located through the CASC_JENKINS_CONFIG variable (by default $JENKINS_HOME/jenkins.yaml), and those files live in version control. A change to the security realm, authorization, or shared settings becomes a reviewed commit that is applied to each controller from the same source. Decide which settings stay common across all controllers and which belong to a single team's controller, because one shared file for every controller recreates the old bottleneck. The plugin does not install plugins, so plugin versions need their own pinning step.
Configuration as Code covers settings, not the software underneath, so the pinned set has three parts. Pin plugin versions in the Docker image or the Helm chart values. Pin the Jenkins version to the LTS line: Jenkins LTS 2.580.1 was released on September 30, 2026, and its changelog notes that the bouncycastle API, SSH server and JUnit plugins are no longer bundled, so teams that depend on them must install them through the plugin manager. Then check the Java support policy before choosing a runtime: Java 21 has a planned end of support in September 2027, Java 25 in September 2029, and 2.541.3 in March 2026 was the final LTS release for Java 17. Confirm these dates on the policy page before you plan upgrades.
Agents are where the operations center's job of distributing work moves. The Jenkins Kubernetes plugin starts a build agent as a pod for each build and removes it afterward, so the controller coordinates work without long-lived build machines that need central configuration. Pod templates, namespaces and the service account that creates pods are defined in the same Configuration as Code files, which is where you review what a build can reach. Confirm with your platform team which cluster and namespace each controller may use and how pod credentials are scoped. The Jenkins scaling guide recommends dedicated build agents so the controller handles HTTP requests and manages the build environment, which supports this split.
How to move controllers off the operations center
This sequence turns a centrally managed CloudBees fleet into independently run Jenkins controllers, each rebuilt from code and backed up, with the Jenkinsfiles in your repositories left untouched.
Inventory controllers, jobs, credentials and plugins
The platform team lists every managed controller, its jobs, the credentials each job uses and every plugin that is installed. Mark the CloudBees-only plugins, since each one needs an open-source replacement or a decision to drop it before cutover. The step is done when the list has an owner for each team and each CloudBees-only plugin has a named replacement or a retirement decision.
Export configuration as code
For each controller, write the settings into YAML that the Jenkins Configuration as Code plugin can read, covering security realm, authorization, cloud agents and global tools. Store the files in a Git repository with review on every change. Confirm the plugins listed in the YAML are installed through the plugin manager or a Helm values file, because that plugin does not install them. The step is done when a test controller boots from the YAML with no manual edits.
Back up each controller's JENKINS_HOME
Take a complete backup of $JENKINS_HOME on every controller that will be retired. The Jenkins scaling guide places all configuration, plugins and secrets in that directory, so the backup is the fallback if a cutover fails. Keep the backups encrypted and restrict access, because they contain stored secrets. The step is done when a restore has been tested on an isolated host.
Re-enter secrets from the source of truth
Recreate each credential in the team's secrets manager or in Jenkins credentials, using values taken from the owning system such as the cloud account, registry or SSH key store. Do not rely on exporting CloudBees credential values, because support for that export is not confirmed in the supplied documentation; confirm the export options with CloudBees before you assume they exist. The step is done when every job's credential ID resolves on the new controller and a test build authenticates.
Stand up controllers with the official Helm chart
Deploy one controller per team or project into the Kubernetes cluster using the official Jenkins Helm chart, with the Kubernetes plugin configured for ephemeral agents and the Configuration as Code files mounted into the controller. Keep the controllers on the same LTS line so plugin behavior matches across teams. The step is done when each new controller passes a test pipeline on a dedicated agent.
Cut over team by team
Point each team's webhooks and forge integrations at its new controller, then run its existing Jenkinsfiles without edits. Pipeline syntax lives in the repositories, so the Jenkinsfiles stay unchanged and only the controller address and credential references move. Keep the CloudBees controller read-only for that team until a full build cycle has passed. The step is done when the team confirms its builds, notifications and deployments work on the new controller.
Decommission the operations center and retired controllers
After every team has cut over, disable the old controllers and remove their agent connections, then archive the final backups under your retention policy. Remove the operations center and the CloudBees license from your renewal calendar only after the license terms are confirmed in writing with the vendor. The step is done when no build traffic reaches the retired hosts and the archive is verified.
Running open-source controllers beside CloudBees CI during transition
Teams that remain on CloudBees CI keep their controllers, licenses and operations center until their cutover date. During the overlap, the main risk is that the operations center continues to push configuration, plugin versions and role assignments to controllers that other teams have already started to rebuild on open-source Jenkins. Keep the existing controllers unchanged until their owners schedule a move, and record which Jenkinsfiles, shared libraries and credentials each one uses.
- Freeze shared configuration: Stop making changes in the operations center that affect teams not yet moved, so the open-source controllers are built from a known baseline.
- Inventory CloudBees-only plugins: List every plugin in use on each controller and mark those with no direct open-source equivalent.
- Keep Jenkinsfiles in Git: Confirm that pipeline definitions live in source control, so the same repository can be built by either controller.
- Document credential IDs: Note which credential IDs each pipeline references so the secrets manager entries can be matched during cutover.
- Set the license end date: Confirm with CloudBees the date on which support and access to the operations center end, and plan moves before that date.
Before any team moves, confirm the plugin inventory with the platform owner and the CloudBees account team in writing.
Teams that have already moved run their pipelines on open-source Jenkins controllers, usually defined through Configuration as Code and deployed with the official Helm chart. Their working repositories and pipeline definitions do not change, but their controllers now have to be operated without the operations center, including backups of $JENKINS_HOME, upgrades to the current LTS line and plugin updates. Their onboarding and configuration are managed by the platform team in version control rather than in a central UI.
- Back up controller state: Schedule backups of
$JENKINS_HOMEand the Configuration as Code files, since the scaling guide places configuration, plugins and secrets on the controller. - Track LTS upgrades: Follow the Jenkins LTS changelog and test each baseline on a non-production controller before applying it.
- Route webhooks to the new controller: Update repository webhooks so pushes reach the open-source controller, and remove the old CloudBees endpoints once cutover is verified.
- Retire duplicate jobs: Disable the matching jobs on the CloudBees controller so the same commit does not build twice.
- Confirm agent connectivity: Verify that agents reach the new controller and that build logs and artifacts are stored where the team expects.
Review this list with the team's application owners after the first two release cycles on the new controller.
During the overlap, both controllers may draw on the same agent pool, shared libraries and Git repositories. This is workable only if agent labels, workspace paths and plugin versions do not collide. Plugin compatibility is the main item to confirm, because some plugins that CloudBees CI bundles or depends on are not part of the open-source distribution, and Jenkins itself changes its bundled plugin set between LTS releases. Agreeing on agent labels and plugin baselines first avoids most failures during the period when both systems are live.
- Confirm plugin compatibility: Check each required plugin against the Jenkins plugin index and the Java and LTS versions in use, and test on a staging controller.
- Check bundled plugin changes: Review the LTS changelog for plugins that stop being bundled, such as the SSH server or JUnit plugins, and install them explicitly if needed.
- Separate agent labels: Use distinct labels or pools for each controller so jobs are not scheduled on the wrong side.
- Use the Kubernetes plugin: If agents are ephemeral pods, confirm the plugin version and cluster permissions for both controllers.
- Share repositories carefully: Avoid two controllers writing to the same deployment target at the same time.
The mapping of CloudBees-only features to open-source plugins should be confirmed in writing against your own pipelines before any shared agent is reassigned.
Questions buyers ask before replacing the operations center
What does replacing the CloudBees operations center cost, and what drives it?
The cost has three parts: the one-time engineering work to rebuild controller management, and the recurring infrastructure, plugin upkeep and upgrade effort that follow. The open-source Jenkins project is distributed under the MIT License, so there is no license fee to remove, but you still pay for the people and infrastructure that run it. Cost rises with the number of controllers, the count of CloudBees-only plugins you must replace, the size of your agent fleet and whether you buy a support partner. Ask any vendor or partner for a written breakdown of one-time work and recurring work, with the controller count and plugin inventory stated as assumptions.
How long does a migration off the operations center take?
No duration is fixed by the researched facts, so treat any number a partner quotes as a claim to verify. The main factors are how many controllers you run, how many plugins are CloudBees-only, how much of your configuration lives in the UI rather than in code, and how many teams must test their pipelines. Controllers can move one team at a time, which lets you finish the riskiest team last. Ask for a schedule that lists each controller as its own milestone with its own cutover and rollback step.
What skills does the team need to run Jenkins on Kubernetes?
Your team needs working knowledge of Kubernetes, Helm and Jenkins administration, plus enough Git discipline to keep every job definition in source control. The official Helm chart and the Kubernetes plugin do much of the setup, but someone must own namespaces, resource limits, storage for $JENKINS_HOME and agent images. Plan for at least one person who can debug a failed controller and one who can review Jenkinsfile changes. Confirm these skills in your own environment before you commit to a schedule.
Who owns secrets after the move, and how do we handle them?
Your organization should own the secrets, held in a secrets manager you operate, with Jenkins reading them at runtime rather than storing copies in job configuration. Because CI secrets generally cannot be exported from hosted services, you should plan to re-create them from their original sources rather than copy them from the old platform. Document who may request each secret, how it rotates and which controllers can read it. Confirm the access model with your security team before cutover.
Can our in-house team do this without an implementation partner?
Yes, many teams can, provided they have the skills, time and clear ownership described above. The open-source components are documented, but the work includes plugin inventory, configuration as code, controller design, upgrade planning and runbooks that a team usually has not built before. A fixed-scope engagement can cover part of that work, such as the inventory, the design and the first controller, while your staff take over the rest. Decide which parts you will own before asking anyone for a quote.
How do we replace central audit and role-based access control?
Open-source Jenkins does not provide the operations center's central management, so you must rebuild those controls. Use Configuration as Code to store authorization and global settings in version-controlled YAML, use an open-source authorization plugin for role-based access, and send controller logs to a central store your security team already monitors. Central audit is the gap most likely to need extra work, because each controller records its own history. Confirm with your auditors which evidence they need, since DeployOpen prepares controls and evidence but does not issue audit reports.
What should we ask for in a written scope before signing?
Ask for a written scope that names each controller and team in scope, every CloudBees-only plugin and its replacement, the target Kubernetes environment, and the secrets integration. Require deliverables for the Configuration as Code repository, the Helm values, runbooks, backup and restore tests for $JENKINS_HOME, and a cutover and rollback plan per controller. Also ask how upgrades will be handled after handover, who approves plugin changes, and what the support terms are. DeployOpen issues a quote from a written scope, so the scope itself is what you should compare across bids.
Which governance gaps remain after the move
The main gap is that no single pane of view across controllers exists out of the box. The CloudBees operations center gives administrators one place to see and manage many controllers. With community Jenkins, you rebuild that view yourself, usually by exporting controller health, queue and build metrics to a monitoring stack and by keeping every controller's jenkins.yaml in one Git repository so configuration drift is visible in review. Confirm with your team who owns that dashboard, which alerts page whom, and how a new controller gets added to it, because none of these tasks are handled for you.
Authorization is the second gap. Role-based access control and folder-level permissions in community Jenkins depend on open-source plugins such as the Role-based Authorization Strategy plugin, which your team must select, configure and keep current. Each plugin has its own release cadence and its own security advisories, so the review burden moves from the vendor to your platform team. Before cutover, document which roles map to which folders, test that a team lead cannot change another team's credentials or jobs, and decide who approves plugin upgrades.
The third gap is high availability. Community Jenkins does not provide active/active high availability across controller replicas, so a controller failure stops the builds it runs until it is restored or a backup takes over. The primary and backup pattern and controller sharding described in the sibling high availability page reduce that exposure but accept some downtime and manual failover steps. Ask your business owners how long a controller outage can be tolerated for each team, and review the sibling pages on CloudBees CI features and high availability to see which of these capabilities you will need to rebuild or buy elsewhere.
How DeployOpen scopes and delivers a Jenkins controller migration
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For teams replacing the CloudBees CI operations center with open-source Jenkins, we start from an inventory of controllers, plugins and credentials, then agree the scope in writing before any build work begins.
How we scope
- Inventory every Jenkins controller, its plugins, jobs and credential references before agreeing the scope.
- Identify CloudBees-only features in use and record which open-source replacement or manual process covers each one.
- Agree controller layout, secrets manager integration and access model in a fixed-scope written document with deliverables and timelines.
How we build
- Express controller configuration as Configuration as Code YAML and deploy controllers from the official Helm chart.
- Connect controllers to the Kubernetes plugin so builds run on ephemeral agents, and source shared credentials from your secrets manager.
- Test each controller-per-team pattern against representative Jenkinsfile pipelines before any team's jobs are moved.
How we hand over
- Document the runbook covering controller creation, plugin updates, backup of $JENKINS_HOME and recovery steps.
- Record the governance gaps that remain, such as centralized RBAC and fleet-wide views, with the controls you will own for each.
- Walk your platform and security teams through the handover and confirm each deliverable against the agreed scope.
How we support
- Offer ongoing support, Jenkins LTS upgrades and plugin maintenance as a retainer after handover.
- Run continuous security testing of the Jenkins estate as a retainer if your risk model requires it.
- Ask any provider, DeployOpen included, to confirm support hours, response commitments and upgrade responsibilities in writing.
