When CloudBees CI or open-source Jenkins fits better
If you are facing a CloudBees CI renewal, a license review or a need for tighter control over many Jenkins controllers, the decision turns on how much central governance and vendor-backed high availability you need, and how much operating work your team can absorb. CloudBees CI fits better when you run many controllers across teams and need the operations center to manage them centrally, role-based access control applied consistently, vendor support with defined escalation, or active/active high availability so builds keep running across controller replicas. Those are capabilities you would otherwise have to design, build and maintain yourself.
Open-source Jenkins fits better when license cost is the main pressure and the footprint is modest, with a small number of controllers, a clear owner for each and a team able to run Configuration as Code with the Configuration as Code plugin, manage plugin upgrades and keep the Kubernetes plugin's agent pool healthy. Jenkins is distributed under the MIT License, so the software itself carries no license fee. Your recurring costs then shift to infrastructure, staff time and any support contract you choose to buy. Ask your CloudBees account team to itemize what the renewal covers per controller, then compare that list against the work your own engineers would take on.
Four decision drivers should settle the choice: governance scale (how many controllers and teams must follow one set of rules), HA downtime tolerance (whether a short outage during a controller failover is acceptable or whether builds must never stop), in-house operating skills (who will own upgrades, plugin upkeep and backups in $JENKINS_HOME), and support needs (whether your auditors or internal policy require a contracted vendor to answer for the platform). Score each driver honestly before you negotiate, because a weak score on governance or HA usually means the open-source path needs a funded operating model, not just a free download.
Which option fits which scenario
This table matches common operating conditions to the option that usually fits them better, with the reason tied to that condition. Read each row against your own estate, then check the gaps in the last column before deciding. The main takeaway is that open-source Jenkins suits most small and mid-sized estates with capable platform staff, while CloudBees CI earns its license where central governance and uptime requirements are strict and must be met without custom tooling.
| Scenario | Better fit | Why, and what to confirm |
|---|---|---|
| A single team running a few controllers | Open-source Jenkins | Few controllers means little central management work, and each controller can be backed up from $JENKINS_HOME with Configuration as Code. Confirm that your plugin set is available in the community plugin catalog. |
| A platform team running dozens of controllers | CloudBees CI, or a deliberate open-source pattern | The operations center manages many controllers from one place. Open-source needs Configuration as Code, the official Helm chart and a controller-per-team model, which adds ongoing platform work you must staff. |
| A regulated estate needing audit trails and RBAC | Depends on the evidence your assessor expects | CloudBees CI includes centrally managed role-based access control. Open-source Jenkins needs authorization plugins and external logging, so confirm with your assessor which audit records they will accept before choosing. |
| A strict uptime requirement | CloudBees CI for active/active builds | CloudBees CI supports active/active high availability across controller replicas. Open-source Jenkins usually offers a primary and backup controller behind a proxy, so a failover interrupts running builds. Confirm the downtime you can accept. |
| A team with strong Kubernetes skills | Open-source Jenkins with the Kubernetes plugin | The Kubernetes plugin runs ephemeral agents as pods, so build capacity scales without a license. Your team can operate the cluster, agent images and controller storage without vendor support. |
| A team with limited Jenkins administration experience | CloudBees CI, or a support partner for open-source | Vendor support and packaged management reduce the upgrade and plugin troubleshooting load. Open-source is viable only if you budget for a support arrangement, which you should request as a written scope. |
| A team that must keep build history and secrets in-house | Open-source Jenkins | Your controllers, plugins and credentials stay under your own administration. Confirm where backups of $JENKINS_HOME and credentials are stored and who can restore them. |
What open-source Jenkins covers without a license
Open-source Jenkins is distributed under the MIT License, so the core automation server carries no license fee and no per-controller charge. The features that remain in the open-source distribution are the ones most teams use every day: pipelines defined in a Jenkinsfile committed to the project's source control repository, written in Declarative or Scripted syntax made of stages and steps. Keeping that file next to the code means the build definition moves with the repository and goes through the same review as application changes. Teams replacing CloudBees CI should confirm which of their current jobs already live in Jenkinsfiles, because jobs configured only through the web interface will not carry over without rework.
The Configuration as Code plugin covers much of the controller setup that teams might otherwise buy through a central management layer. It reads YAML from the file named by the CASC_JENKINS_CONFIG variable, which defaults to $JENKINS_HOME/jenkins.yaml, so security realm, authorization and system settings can be versioned and reviewed. Its documentation states that it does not install plugins, so the plugin list must be pinned separately, through Docker images or the official Helm chart. The Kubernetes plugin covers the agent side by starting build agents as ephemeral pods, which removes the need to maintain a fixed fleet of agent machines. Before relying on it, confirm the plugin versions you need against the Jenkins LTS changelog, since the 2.580.1 release stopped bundling several plugins, including the SSH server and JUnit plugins.
The Jenkins scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment. The operational consequence is that the controller holds state that cannot be rebuilt from code alone. All configuration, plugins and secrets live in $JENKINS_HOME on the controller, so that directory is the backup scope. A backup plan should cover it on a schedule, include credential stores encrypted with the instance's master key, and be tested with a restore into a clean environment. Ask the platform owner who holds the master key and where it is kept, because a backup without it cannot recover stored credentials.
What CloudBees features you must rebuild or buy elsewhere
CloudBees CI uses an operations center to manage many controllers from one place, pushing shared configuration, plugin baselines and folder structures to each controller. Open-source Jenkins has no equivalent central console. The usual replacement is a controller per team or product, with each controller's configuration held in 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 plugin lists are managed separately through Docker images or the official Helm chart. Teams then keep one Git repository of controller definitions and roll changes out with the same review process they use for application code.
- Controller-per-team pattern: Each team gets its own controller, which keeps blast radius small but multiplies upgrades and backups.
- Configuration as Code: Global settings, security realms and job definitions can be reviewed in Git, but you must write and maintain the YAML.
- Plugin baseline: Plugin versions are pinned through images or charts, so you need a process to test and promote them.
- Central visibility: Without an operations center, cross-controller dashboards and fleet health checks have to come from your monitoring stack.
- Remaining gap: Fleet-wide policy enforcement and a single pane for controller status are not provided by community Jenkins.
Before committing, confirm with your platform team how many controllers you expect to run and who owns the fleet tooling that replaces the operations center.
CloudBees CI adds role-based access control and governance features on top of Jenkins security, including folder-level role management and audit-oriented controls that are managed centrally. Open-source Jenkins provides authorization through its built-in matrix and folder permissions and through community plugins, but the depth and administration model differ. Many organizations rebuild the parts they need by combining Configuration as Code for authorization settings, an external identity provider for group membership, and credentials held in a secrets manager rather than in Jenkins itself. The approach works best when group rules are simple and reviewed as code.
- Authorization model: Matrix-based and folder-level permissions cover common team separation, but complex inheritance rules need careful testing.
- Identity integration: Group mapping from your identity provider is typically done with community plugins, so confirm which realm and group plugins your security team approves.
- Shared credentials: Pulling credentials from a secrets manager at runtime keeps values out of
$JENKINS_HOME, which matters because the scaling guide places all secrets to back up on the controller. - Audit trail: Jenkins logs and build records exist, but centralized audit reporting across controllers usually needs shipping logs to a SIEM.
- Remaining gap: Policy reports that a CloudBees customer would generate from the product must be assembled by your own team or a support partner.
Ask your security and audit teams which control evidence they need from the CI platform and map each item to a specific Jenkins setting, plugin or external log source.
CloudBees CI offers active/active high availability, which keeps builds running across controller replicas. Open-source Jenkins does not offer an equivalent active/active controller design. The Jenkins scaling guide describes a primary and backup controller arrangement in which a proxy such as HAProxy or F5 routes traffic to the backup if the primary fails, and it recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment. Teams that need less downtime often combine this with controller sharding and ephemeral Kubernetes agents, so that build capacity can be replaced without restoring the controller.
- Primary and backup controller: Failover is handled by a proxy, and the backup must be kept in step with the primary's
$JENKINS_HOME. - Controller sharding: Splitting teams across several controllers limits how much one failure affects, but it adds operational work.
- Ephemeral agents: The Kubernetes plugin runs build agents as pods, so agent failures do not lose a controller's state.
- Backup discipline: Configuration, plugins and secrets all live in
$JENKINS_HOME, so backup and restore testing carry most of the recovery burden. - Remaining gap: In-flight builds on a failed controller may stop, and the recovery window depends on your proxy, storage and runbook design, so test it in your environment.
Before you accept this design, ask your operations team to define the downtime your builds can tolerate and run a failover test against that target.
Data location, hosting models and compliance implications
Moving from CloudBees CI to open-source Jenkins changes where controllers, secrets, logs and artifacts sit, and who operates them. The cards below cover each data type and the identity, audit and vendor questions that follow from the hosting model you choose.
Controllers and configuration
In either model, the Jenkins controller holds job definitions, plugin state and configuration. Open-source Jenkins keeps everything you need to back up in $JENKINS_HOME on the controller, so the backup scope is yours to define and test. With CloudBees CI, confirm which parts of configuration sit in the operations center and which sit in each managed controller, and where those backups are stored and encrypted. Document both locations before you decide where the controllers run.
Secrets and credential storage
Secrets are the highest-risk data in a CI system. Hosted CI providers have had incidents in which customer environment variables and keys were exfiltrated, and the vendor instructed customers to rotate them. Self-hosted Jenkins stores credentials on the controller unless you connect it to an external secrets manager. Ask CloudBees how credentials are encrypted at rest, who holds the keys, and whether a self-managed edition lets you keep key material in your own key management system.
Build logs and artifacts
Logs and artifacts can contain source excerpts, internal hostnames and test data, so they fall under your data classification rules. Self-run Jenkins keeps them on storage you control, and retention is whatever your own policy and disk allow. For CloudBees CI, confirm where logs and artifacts are written, whether they are replicated across controllers, and how long they are kept by default. Plan retention in writing before you migrate any build history.
Identity integration
Access to controllers is a control your assessor will test. Open-source Jenkins can authenticate against your directory through plugins and maps roles through authorization plugins, which you must select, install and maintain. CloudBees CI bundles centrally managed role-based access control, so confirm which identity providers it supports, how group mappings are audited, and how deprovisioning a user removes their access to every controller.
Audit evidence
Auditors ask who changed a pipeline, who approved a deployment and who read a secret. Open-source Jenkins records these events only as far as the plugins you install record them, so build an audit trail deliberately and forward it to your log platform. Ask CloudBees which audit events its operations center records, how long they are retained, and whether they can be exported into your own SIEM.
Vendor support and compliance scope
Whether the support contract, data processing terms and self-managed packaging satisfy your obligations depends on the contract and on the frameworks you are assessed against. This page does not make compliance claims for any product. Ask CloudBees in writing for its support terms, its data handling commitments and what it will provide for evidence. Then confirm your exact compliance scope with your assessor before choosing a hosting model.
Cost components: what you pay for on each side
Comparing these two options means comparing who gets paid for what. CloudBees CI bundles licensing and vendor support into a per-controller commercial relationship, while open-source Jenkins moves those costs onto your own staff, infrastructure and any support partner you choose. Ask for each component separately so the quotes can be compared line by line.
CloudBees licensing and support
This is the recurring subscription, typically priced per controller and tied to the support tier you select. It drives the largest single line on the commercial side, so the quote should state the controller count, the operations center scope, the support hours and whether the price renews automatically. Ask how a controller added mid-term is billed and what happens to pricing if you retire controllers during the term.
Open-source Jenkins infrastructure
The community Jenkins software carries no license fee, so the recurring cost is compute, storage and network for controllers and build agents. Dedicated agents keep the controller free for HTTP requests and configuration, which makes agent sizing a major cost driver. Ask your platform team to estimate agent hours from your current CloudBees usage before comparing with any quote.
Plugin upkeep and testing
Community plugins are maintained by many independent authors, so upkeep is recurring engineering time: reviewing updates, testing them against your Jenkins baseline and removing plugins you no longer need. Plugins that CloudBees supplied or supported may need replacements, and each replacement adds a review and maintenance line. Count CloudBees-only features in your environment before estimating this cost.
Upgrades and LTS planning
Jenkins LTS baselines move on a fixed cycle, and each upgrade requires regression testing of pipelines and plugins. The Java support policy also forces periodic runtime changes. Budget recurring staff time for these upgrades on both sides, and confirm with CloudBees how its release train and support windows apply to your version.
Backups and disaster recovery
All configuration, plugins and secrets for a Jenkins controller live in its home directory, so backup is a required recurring job, along with restore testing. Storage, retention and the frequency of restore drills drive this cost. Ask CloudBees what backup tooling and support it provides, and plan equivalent backup and restore tests for open-source Jenkins.
On-call and support partner
Commercial support gives you a vendor escalation path, while open-source Jenkins relies on internal on-call rotations, community channels and, optionally, a paid partner on a retainer or fixed-scope engagement. The main cost drivers are hours of on-call coverage, the severity levels you must meet and how much of the operations work you outsource. Request any partner quote with written scope, response expectations and deliverables.
How a move from CloudBees CI to Jenkins proceeds
The sequence below turns a CloudBees CI estate into community Jenkins controllers that run the same Jenkinsfiles, with credentials moved deliberately and a cutover you can verify before the license ends.
Inventory CloudBees-only plugins and features
Your platform team lists every controller, its plugins, its credentials, and each CloudBees-specific feature in use, including the operations center, centrally managed controllers, role-based access control and any active/active high availability setup. Each item is marked as one of three things: replaced by an open-source plugin, rebuilt through Configuration as Code, or without a direct equivalent that needs a decision. Check each plugin against the Jenkins LTS changelog, because the 2.580.1 LTS release stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins, which must now be installed through the plugin manager. The step is done when every controller has a written inventory signed off by the teams that own its jobs.
Stand up controllers with Configuration as Code
Platform engineers build new community Jenkins controllers and define their settings in YAML files loaded by the Configuration as Code plugin, which reads from the path set in CASC_JENKINS_CONFIG and defaults to $JENKINS_HOME/jenkins.yaml. The plugin does not install plugins, so the plugin list is pinned separately, for example in a Docker image or the official Helm chart. Keep the YAML under version control and review changes the same way as application code. The step is done when a freshly built controller reproduces the inventoried configuration from code alone, without manual clicks in the web interface.
Pick a Java runtime and LTS baseline
Before controllers go live, confirm the Java runtime against the Jenkins Java support policy. The policy lists Java 21, with planned end of support in September 2027, and Java 25, with its first LTS 2.541.1 in January 2026 and planned end of support in September 2029, as supported. It lists 2.541.3 in March 2026 as the final LTS release for Java 17. Jenkins picks a new LTS baseline every 12 weeks and ships three LTS releases per baseline in four-week cycles, so schedule a standing upgrade window for patch releases. The step is done when the runtime, the LTS line and the upgrade calendar are written down and agreed with the team that runs the controllers.
Move credentials through a secrets manager
Credentials are the step that cannot be copied directly. Most CI platforms do not let you export secret values: GitHub's REST API returns secret names without values, CircleCI does not show environment variable values after they are set, and Bitbucket secured variables can only be replaced or deleted. Recreate each credential at its source and store it in your secrets manager, then reference it from Jenkins through a credentials provider so the controller reads values at runtime. Record which secrets were rotated, since the CircleCI January 4, 2023 incident report told customers to rotate secrets after an exfiltration. The step is done when every job that needs a credential resolves it from the new store in a test run.
Keep Jenkinsfiles unchanged and run in parallel
Jenkinsfiles live in each project's source control repository and define stages and steps in Declarative or Scripted syntax, so they move with the code rather than with the controller. Point the new controllers at the same repositories and run the same pipelines in parallel with CloudBees CI, comparing results job by job. Where a Jenkinsfile depends on a CloudBees-only step, fix it in the inventory list from step one rather than editing pipelines ad hoc. Build agents should be dedicated machines or ephemeral Kubernetes agents, so the controller stays focused on HTTP requests and environment management. The step is done when parallel runs match the CloudBees results for a full set of representative jobs.
Export build history and artifacts
Build history and artifacts are kept for limited periods on hosted CI services, so export them before the old system is shut down rather than relying on the platform to hold them. For Jenkins, back up $JENKINS_HOME on the CloudBees controllers, since it holds configuration, plugins and secrets, and archive the job logs and artifacts your audit or release process needs. Confirm with your compliance owner which records must be retained and for how long. The step is done when an archived copy of each required record is stored in your own infrastructure and a restore has been tested.
Cut over and plan the license end date
Cut over team by team, moving the trigger webhooks and job ownership to the new controllers once parallel runs have been clean for the agreed period. Keep the CloudBees controllers read-only and available for rollback until the last team has confirmed its pipelines. Then set the license end date with CloudBees, asking in writing for the end date, support terms for the final period and any data export assistance. Retire the old controllers only after the rollback window closes. The step is done when no production job depends on CloudBees, the license end date is confirmed in writing, and the decommissioning record is filed with the platform owner.
Questions buyers ask before switching from CloudBees CI
What drives the cost of moving from CloudBees CI to open-source Jenkins?
The biggest cost drivers are the number of controllers, the number of CloudBees-only plugins you depend on, and how much of your operations center governance you must rebuild. Open-source Jenkins carries no license fee, so the recurring costs shift to infrastructure, plugin upkeep, upgrades and any support contract you choose to buy. Your team pays for the compute that runs controllers and agents, the engineering time to replace features, and the ongoing work to test and apply Jenkins releases. Ask any implementation partner for a quote that lists one-time work (inventory, migration, configuration as Code design) separately from recurring work (patching, plugin updates, on-call). Also ask which CloudBees license end date you are planning around, because overlap periods add cost.
How long does a migration from CloudBees CI to Jenkins take?
Duration depends mainly on how many controllers you run, how many CloudBees-specific features they use, and how many pipelines depend on them. Teams with a small number of controllers and mostly standard plugins can move faster than teams with a large operations center and custom role-based access rules. Other factors include how cleanly Jenkinsfiles are written, how credentials are stored, and whether you need to run both systems in parallel during cutover. No duration is stated here because none has been verified for your environment. Ask for a scoped estimate that lists controllers, plugins, pipelines and test cycles, and that names the assumptions behind each phase.
What does the work need from our internal team?
Your team needs people who understand your current CloudBees controllers, your Jenkins plugin set and the applications built through those pipelines. You will also need someone who owns the target design, including Configuration as Code files, the Kubernetes plugin or Helm deployment, and how credentials are provided. Security and identity staff must agree on how access will be granted without the operations center, and release owners must sign off on pipeline behavior. Plan time for testing each pipeline against the new controllers. Ask the implementation partner which of these roles they will fill and which must stay with your staff.
Can our team migrate from CloudBees CI without outside help?
Yes, a team with Jenkins administration experience can perform the migration in-house, especially for a small number of controllers. The hard parts are usually the CloudBees-only features, such as operations center governance and centrally managed controllers, which need replacement designs rather than direct copies. Open-source Jenkins documentation covers Configuration as Code, Pipeline and Kubernetes deployment, so the learning curve is manageable for experienced staff. Outside help is most useful for scoping, for a documented cutover plan and for security review. A fixed-scope engagement sets deliverables and timelines in writing before work starts, so you can compare that against doing it internally.
Do our Jenkinsfiles carry over unchanged?
In most cases, Jenkinsfiles carry over because Jenkins Pipeline defines builds as code in a Jenkinsfile committed to source control, using Declarative or Scripted syntax made of stages and steps. Problems appear when a Jenkinsfile calls a CloudBees-only step, plugin or shared library, or relies on a credential store that does not exist on the target controller. Inventory those calls before cutover and test each pipeline on the new controller. Keep the Jenkinsfiles in the repository so the build definition moves with the code, not with the controller.
Which plugins and settings must be checked before the migration?
Check every plugin that CloudBees controllers use, and confirm whether each one exists in the community plugin index and is maintained. Also check the Java version your controllers run. The Jenkins Java support policy lists Java 21, with a planned end of support in September 2027, and Java 25, with a planned end of support in September 2029. Jenkins LTS 2.580.1 also stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins, so you must install them through the plugin manager. Review the LTS release line, which picks a new baseline every 12 weeks, so your upgrade plan matches that cadence.
What happens to high availability after the switch?
Open-source Jenkins does not offer CloudBees-style active/active high availability out of the box, so the design changes. The Jenkins scaling guide describes a primary and backup controller arrangement, where a proxy such as HAProxy or F5 routes traffic to the backup if the primary fails. Another option is adding controllers for separate teams, which limits the blast radius of an outage but does not keep one pipeline running across replicas. Expect a short interruption during failover and plan for it with your application owners. Confirm the accepted downtime, recovery steps and backup of $JENKINS_HOME with your team before you commit to a design.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports open-source Jenkins inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. We start by mapping which CloudBees CI features your teams rely on, then agree what the replacement must cover before any work begins.
How we scope
- Inventory every CloudBees CI controller, operations center setting, role and CloudBees-only plugin your teams depend on today
- Agree in writing which controllers, pipelines and access rules move to open-source Jenkins and which stay out of scope
- Confirm the controller, agent, backup and high availability design with your platform and security owners before build work starts
How we build
- Configure Jenkins with the Configuration as Code plugin so controller settings live in version-controlled YAML files
- Deploy Jenkins on Kubernetes with ephemeral agents and secrets sourced from your own secrets manager rather than stored on the controller
- Test migrated Jenkinsfiles and authorization rules against the agreed scope, including the failover behavior you accept
How we hand over
- Document the Jenkins configuration, backup procedure for the Jenkins home directory, upgrade steps and access model for your team
- Deliver runbooks for controller recovery, plugin updates and LTS upgrade cycles, so operators can run the platform without us
- Provide evidence of configuration and access controls that your internal or external assessors can review, without us issuing any audit or certification
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, LTS upgrades and continuous security testing are available as a retainer after handover
- Request a quote based on the written scope, which sets the effort and cost components for your environment
