Where CloudBees CI cost vs self-hosted Jenkins actually differs
Jenkins itself carries no license fee. Open-source Jenkins is distributed under the MIT License, so the comparison with CloudBees CI turns on what replaces the per-controller CloudBees licensing, the vendor support contract and the centrally managed features that come with the commercial distribution. A platform team facing a renewal should first list every controller, every team that relies on the operations center or role-based access control, and every CloudBees-only capability in use, then price each of those against an in-house or partner-delivered replacement. Ask CloudBees for a written breakdown of what the renewal includes, and confirm which features are tied to the license rather than to the support contract. Self-hosting moves the recurring cost from the vendor invoice into infrastructure, plugin upkeep and people. The controllers, build agents, storage, backups and monitoring run in your own cloud accounts or data centers, so those bills continue. Plugin maintenance is a recurring task: Jenkins offers more than 2,300 community plugins, and each one needs version tracking and testing. The LTS release line ships a new baseline every 12 weeks, with three LTS releases per baseline in four-week cycles, and Java support is also on a schedule. Java 21 has a planned end of support in September 2027 and Java 25 in September 2029, so upgrades must be planned around those dates. Confirm these dates against the Jenkins Java support policy before you commit to a timeline. One-time migration effort is real and should be budgeted separately. Inventory CloudBees-only plugins, rebuild operations center governance with Configuration as Code and an authorization plugin, and decide who owns the open-source upgrade calendar after go-live. Ask any implementation partner for a fixed-scope written plan that names the controllers, plugins, credentials and the license end date, because those inputs drive the quote more than the number of users does.
Cost components on each side
This table sets each cost component of CloudBees CI against the same component in self-hosted open-source Jenkins, showing who is paid and whether the cost is one-time or recurring. CloudBees pricing is set by its quote and is not stated on this page, so ask CloudBees for a written quote that lists controllers, support tier and any operations center or high availability terms. The main takeaway is that the license line is only one of several recurring costs on the Jenkins side, and those costs need an owner.
| Cost component | CloudBees CI (commercial side) | Open-source Jenkins (self-hosted side) | One-time or recurring |
|---|---|---|---|
| Subscription or license | Paid per controller and support tier, set by the CloudBees quote; confirm whether operations center and HA are included | No license fee; Jenkins is MIT-licensed, so the cost is labor and infrastructure | Recurring (CloudBees); none (Jenkins) |
| Support | Vendor support for the CloudBees distribution, scoped by the chosen tier | Community support, or a paid support partner if you need response commitments; the partner is your choice and fee | Recurring |
| Infrastructure (controllers, agents, storage, backup) | Runs on your infrastructure in either model; confirm which hosting and scale the quote assumes | You pay for controller and agent compute, build storage, artifact retention and backup of $JENKINS_HOME | Recurring, scales with build volume |
| Implementation and migration | Installation and configuration, sometimes included in the engagement; confirm in writing | Build out controllers, Configuration as Code, Kubernetes agents and pipelines, paid to your team or a partner under a fixed-scope agreement | One-time |
| Plugin upkeep, upgrades and testing | Plugin set maintained within the CloudBees distribution; confirm which plugins are CloudBees-only | Your team updates plugins and LTS lines, tests them, and handles plugins dropped from bundling in newer LTS releases | Recurring |
| Internal skills | Smaller platform burden for the operations layer, but admins still need Jenkins and Jenkinsfile skills | Staff who run controllers, agents, RBAC and Java runtime support; budget time for ongoing training | Recurring |
| Replacement of CloudBees-only features | Operations center, centrally managed controllers, RBAC and active/active HA come with the product | Rebuilt with Configuration as Code, the Kubernetes plugin, a primary and backup controller behind a proxy, and open-source authorization plugins | One-time build, then recurring upkeep |
| Support partner (if used) | Not applicable unless you add a partner on top of CloudBees support | Fixed-scope partner work for design, hardening, backup and upgrades; ask for deliverables and timelines in writing | One-time or retainer |
What moves the comparison most
The licence line is only part of the total. Six drivers decide how large the gap between CloudBees CI and self-hosted Jenkins becomes, and most of them are set by your own estimate of controllers, builds, availability needs and skills. Work through them before you request a quote, so the scope you agree on matches the cost you are comparing.
Controllers and teams
Every CloudBees CI controller is a licensed unit, and each team that gets its own controller adds to the licence and to the operations work behind it. Open-source Jenkins has no per-controller fee, but each extra controller still needs backups of $JENKINS_HOME, plugin updates and upgrade testing. Count controllers, then count the people who will patch them. Ask the vendor how controllers are licensed before you agree on a team layout.
Build volume and agent count
Build volume drives the agent fleet, and the fleet drives compute cost in both models. Jenkins recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment. Under open-source Jenkins, you pay for the agent infrastructure directly, so peak parallel demand and autoscaling choices become your cost. Ask for peak concurrency figures from the last year, not averages, before sizing either option.
Availability requirements
The cost of availability depends on whether you need a primary and backup controller or active/active high availability. A primary and backup pair behind a proxy such as HAProxy or F5 is cheaper to run, but failover is not instant, so the downtime it accepts must be stated in writing. CloudBees CI active/active replicas remove that gap at the price of a higher licence and more complex operations. Decide the acceptable outage window first, then price each design against it.
Data residency and secrets
Where credentials live affects both the security review and the migration effort. Jenkins keeps configuration, plugins and secrets in $JENKINS_HOME on the controller, so you must back up and encrypt that path and decide how credentials are sourced. Hosted CI services hold deployment secrets for every connected project, and CI secret values generally cannot be exported when you change platforms. Confirm where secret values sit today and who can read them before you estimate the move.
Staff skills on Kubernetes and Jenkins
Skills are a recurring cost that often outweighs the licence. Running Jenkins on Kubernetes with the Kubernetes plugin, Configuration as Code and dedicated agents requires people who can operate both Jenkins and the cluster. If that skill is missing, the cost of hiring, training or a support partner moves into the open-source column. Inventory who owns Jenkins today, how many are cross-trained, and what on-call coverage you need, then request a quote that prices that gap explicitly.
CloudBees-only features in use
The number of CloudBees-only features you rely on sets how much you must rebuild. Features such as the operations center, centrally managed controllers and role-based access control have no direct open-source equivalent in the core product, so each one needs a replacement built from Configuration as Code, open-source authorization plugins or your own processes. List every feature and plugin that is in active use, then mark which ones have a tested replacement. Each unmatched item becomes a build, buy or accept decision with its own cost.
How to build the comparison with your own numbers
This sequence turns a CloudBees CI renewal into a like-for-like cost model for open-source Jenkins, using your own controllers, build load and staff time instead of generic estimates.
Inventory controllers, plugins and jobs
Start by listing every CloudBees CI controller, the Jenkins version it runs, the plugins installed on each one, and the job count and build frequency per controller. Platform engineering owns this list, with input from team leads who run the pipelines. Export the plugin list from each controller's plugin manager and record which plugins are CloudBees-only. You are done when every controller has a row with its version, plugin count, job count and average daily builds, and someone outside the platform team has reviewed it for gaps.
List the CloudBees features in use
Record which CloudBees-specific capabilities your organization actually depends on, such as the operations center, centrally managed controllers, role-based access control, active/active high availability and any support for specific plugins. Ask each team which of these they touch day to day, and which are configured but unused. Security and compliance staff should confirm which access controls and audit behaviors are required. You are done when each feature is tagged as required, convenient or unused, because only the required ones will need a replacement cost in the model.
Price the CloudBees quote by controller and tier
Ask your CloudBees account representative for a written quote that breaks the price out by controller, support tier, term length and any add-ons, and confirm whether the quote covers the operations center and high availability. Finance or procurement should own this request, since only your contract shows what you pay and when it renews. Note which costs are one-time, such as onboarding, and which recur each year. You are done when the quote's line items map one-to-one to the controllers in your inventory.
Estimate infrastructure from build load
Size the open-source side from your build data: peak concurrent builds, average build duration and agent demand. The Jenkins scaling guidance recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment, so model controllers and agents as separate line items. Also model the backup target for $JENKINS_HOME, since all configuration, plugins and secrets live there on the controller. Infrastructure and platform engineering should own this, with cloud or data center finance confirming unit costs. You are done when you have a monthly infrastructure estimate per controller, agent pool and backup location, each tied to a measured build load.
Estimate effort for each recurring activity
Break recurring work into named activities: Jenkins LTS upgrades, plugin updates and security advisories, Java runtime changes, backup restore tests, on-call response and access reviews. For each one, record who performs it, how many hours it takes internally, and what a partner would charge if you outsource it. Use the Jenkins LTS release line as the cadence source, since it ships new baselines on a fixed schedule with backported fixes in between. You are done when every activity has an owner, an effort estimate in hours and a partner option, so the internal and external columns can be compared directly.
Add the one-time migration and replacement costs
Add the work that happens once: inventorying CloudBees-only plugins, replacing operations center and RBAC functions, moving shared credentials and keeping Jenkinsfiles in source control. Configuration as Code can cover much of the configuration, but it does not install plugins, so budget for plugin installation through images or the Helm chart. Also include any secrets migration, since CI secrets generally cannot be exported from hosted services, so confirm how your CloudBees instance stores them before you plan. You are done when each one-time item has an estimate, a named owner and a recorded assumption.
Compare totals over the same period
Choose one comparison window and state it in the model, then total the CloudBees licensing and support costs for that window against the open-source totals: infrastructure, recurring effort, partner fees and one-time migration. Include a sensitivity row for build growth, because licensing that scales by controller behaves differently from infrastructure that scales by load. Have finance review the model and the platform lead challenge each assumption. You are done when the two totals use the same window, every line is traceable to a source in steps one to six, and the model has been reviewed by someone who did not build it.
Which CloudBees features you would rebuild or buy elsewhere
CloudBees CI's operations center manages many Jenkins controllers from one place. Open-source Jenkins has no equivalent product. The usual substitute is Configuration as Code, which defines each controller's settings in YAML files, combined with the Kubernetes plugin so builds run on ephemeral agents, and a controller-per-team pattern so each group owns its own instance. The Configuration as Code plugin reads its files from the path set in CASC_JENKINS_CONFIG and does not install plugins, so plugin lists must be managed through Docker images or the Helm chart.
- Configuration drift: Your team builds and reviews the YAML, and nothing in the community distribution reports drift across controllers without extra tooling.
- Fleet visibility: Dashboards and health checks across controllers must be assembled from monitoring tools you select and operate.
- Plugin versions: Each controller's plugin set is a separate upkeep item unless you pin versions in code.
- Backups: All configuration, plugins and secrets live in
$JENKINS_HOMEon each controller, so backup jobs must cover every instance. - Work to budget: Expect platform engineering time to design the pattern and keep it current.
Before committing, ask your CloudBees account team and your implementation partner to show how many controllers you run today and how each would be configured in code.
CloudBees CI adds centrally managed role-based access control across controllers and folders. In open-source Jenkins, authorization is handled by the core security settings and by plugins you choose and configure. Teams usually combine the built-in matrix authorization with folder-level permissions and Configuration as Code, then map groups from your identity provider. The result can meet many access rules, but it is assembled by you, not inherited from a product with a single policy view.
- Policy design: Role definitions, folder structure and group mappings must be written and reviewed by your team.
- Central enforcement: Keeping permissions identical across controllers depends on the code and review process you build.
- Audit evidence: Exports of who had which role on which date must be produced from configuration history and logs.
- Identity integration: Single sign-on and group sync rely on plugins that require maintenance and testing.
- Review cadence: Access reviews become a recurring operational task with a named owner.
Ask your security team which access model your auditors expect and whether it can be expressed in configuration files and produced as evidence from the open-source setup.
CloudBees CI offers active/active high availability, which keeps builds running across controller replicas. Open-source Jenkins does not provide active/active controllers. The documented alternative is a primary and backup controller arrangement, where a proxy such as HAProxy or F5 routes traffic to the backup if the primary fails, combined with controller sharding and ephemeral Kubernetes agents to limit how much work any one controller carries. This design accepts a window of disruption during failover, and running builds on the failed primary may need to be restarted.
- Failover design: Health checks, proxy configuration and shared storage must be built and tested.
- Accepted downtime: Plan for an interruption during switchover and document the recovery steps.
- Backup freshness: The backup controller must receive current configuration, plugins and secrets.
- Testing: Failover drills need scheduled time and a rollback plan.
- Scale limits: Sharding across teams spreads load but adds more controllers to operate.
Ask your platform team to state the maximum acceptable interruption for each pipeline class, then compare that figure with what a primary and backup design can meet.
CloudBees CI includes commercial support and a vendor-maintained distribution. Open-source Jenkins is supported by the community, and the project publishes LTS releases on a fixed cycle. Jenkins LTS 2.580.1 stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins, so they must be installed through the plugin manager. Java support also changes over time: Java 21 has a planned end of support in September 2027, and Java 25 has a planned end of support in September 2029. A support partner can supply the response commitments that the community does not offer.
- Upgrade cadence: Your team must schedule LTS upgrades, Java moves and plugin compatibility checks.
- Plugin remediation: Security advisories for plugins need triage and patching by your staff or partner.
- Partner scope: A retainer covers upgrades, hardening and on-call support, and its fees depend on the written scope.
- Internal skills: Someone must own Jenkins administration, not only the pipelines.
- Community access: Forums and documentation are free but carry no response obligation.
Ask any partner for a written scope covering upgrades, plugin patching, backups and incident response, and ask CloudBees for the support terms it currently offers so the two can be compared line by line.
Why the license end date matters for the business case
The business case for leaving CloudBees CI depends on one date that many teams leave open: the written end date of the CloudBees contract. Until that date is fixed, every month of overlap is a choice made by default, and the parallel run of CloudBees CI and open-source Jenkins can quietly cost more than the migration itself. Ask the CloudBees account team for the subscription end date, the renewal notice period and whether support continues during any grace period, then write those dates into the migration plan before any controller is moved.
Jenkins upgrades set the pace of the overlap. Jenkins publishes a new LTS baseline every 12 weeks from a recent weekly release, then ships three LTS releases for that baseline in four-week cycles that contain only backported fixes. Plan the cutover around that rhythm so the team does not start a migration on a baseline that is about to change. The Java support policy matters just as much: Java 21 has a planned end of support in September 2027, and Java 25 has a planned end of support in September 2029. Confirm the Java version each controller and agent image runs, because an upgrade that is blocked by the JDK can extend the overlap without anyone noticing.
Tie the decision to a dated milestone rather than to a general intention to migrate. A practical plan has three gates: a controller inventory with CloudBees-only plugins identified and replaced, a pilot team running its Jenkinsfile on open-source Jenkins for a full release cycle, and a go or no-go review scheduled before the CloudBees notice deadline. If the pilot is not finished by that deadline, the team should decide in advance whether to renew for a short term or accept a parallel run, and price that option explicitly. Record the chosen end date, the owner of each gate and the cost of each month of overlap in the same document.
Questions buyers ask before comparing CloudBees CI and Jenkins costs
How much effort does self-hosting open-source Jenkins take?
Effort depends mostly on how many controllers you run, how many plugins you depend on and how much build load sits on agents. Jenkins keeps all configuration, plugins and secrets to back up in $JENKINS_HOME on the controller, so backup and restore are recurring duties from day one. The Jenkins scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment, which adds agent capacity to plan for. Ask your team to inventory controllers, plugins, agents and the people who own each one before estimating effort.
Can our team run Jenkins without an outside support partner?
Many teams run Jenkins in-house, but the answer depends on whether you already have people who can upgrade controllers, manage plugins and operate build agents. Jenkins LTS releases arrive on a fixed cycle, and the LTS changelog shows that some plugins stop being bundled, so administrators must install them separately. Confirm whether your team can absorb those upgrades within your change windows. A partner is one option for planning, implementation, hardening, backup and upgrades, and DeployOpen offers these as fixed-scope engagements or retainers, with the scope agreed in writing before work starts.
How long does a migration from CloudBees CI to Jenkins take?
Duration is driven by the number of controllers, the number of CloudBees-only features in use, how many jobs rely on them, and how much change control your organization requires. Start with an inventory of controllers, plugins and shared credentials, because that list sets the scope. We cannot give a reliable duration without that inventory, so ask any provider, including DeployOpen, for a timeline in the written scope rather than relying on a general figure.
What Jenkins and Kubernetes skills does the work require?
Plan for skills in Jenkins administration, Pipeline syntax, Kubernetes and Configuration as Code. Jenkins Pipeline defines builds as a Jenkinsfile committed to source control, so developers need Declarative or Scripted syntax. The Configuration as Code plugin reads YAML from the location set by CASC_JENKINS_CONFIG, which defaults to $JENKINS_HOME/jenkins.yaml, and it does not install plugins, so your team also needs a method such as Docker images or the Helm chart for that. If Kubernetes agents are part of the design, the Kubernetes plugin and the official installation guide are the natural starting points.
Does open-source Jenkins have a license fee?
Jenkins is distributed under the MIT License, so the software itself carries no license fee. The cost of running it is in infrastructure, staff time, plugin and upgrade upkeep, backup, and any support partner you choose. CloudBees CI adds a commercial license with a per-controller model and vendor support on top of Jenkins. Confirm the current CloudBees terms directly with CloudBees, since licensing terms can change and this page does not restate them.
What does a support partner cover for open-source Jenkins?
A support partner covers the work your internal team does not have time or skills for. For DeployOpen, that means planning, implementing, customizing, integrating, hardening, backing up, upgrading, documenting and supporting self-hosted open-source platforms inside your own infrastructure. Ongoing support, upgrades and continuous testing are available as retainers. Ask what is included in fixed scope, what is in a retainer, who responds to incidents, and which items are excluded. DeployOpen does not issue audit reports or certifications, so compliance evidence still comes from independent auditors.
What should we ask for in a quote for this move?
Ask for a written scope that lists each controller, plugin set, agent pool and integration in the migration. Request separate line items for one-time work such as inventory, build, migration and hardening, and for recurring work such as upgrades, backup testing and support. Ask how each CloudBees feature, such as the operations center, RBAC and high availability, will be replaced, and what remains a gap. Also ask for the acceptance criteria, the change plan, and how secrets will be handled. DeployOpen provides quotes that follow from the written scope and does not publish a price list.
How should we move secrets when we leave CloudBees CI?
Plan to recreate secrets in your new store rather than export them, because CI platforms often do not return secret values once they are set. Jenkins keeps credentials in $JENKINS_HOME on the controller, so confirm how existing credentials will be re-entered and who approves each one. Rotate any credential that was exposed to a hosted CI service, and consider a secrets manager for shared credentials. Ask your provider to document this step in the scope so that it is tested before cutover.
What a fixed-scope cost review covers
A fixed-scope cost review starts with a written scope agreed before any work begins, so the comparison between CloudBees CI and self-hosted Jenkins is built on your own numbers rather than a generic model. The scope sets out the inventory, the cost components, the migration plan and the handover of runbooks, and it names who signs off each deliverable. DeployOpen does not publish a price list. A quote follows from that written scope, and the cost review is not a replacement for the CloudBees CI quote you receive from CloudBees or its partners. Its purpose is to give you a like-for-like view you can put next to that quote.
The inventory covers every Jenkins controller, the number of agents and where they run, the plugins in use (including any that are CloudBees-only), the credentials and secrets stored in each controller's $JENKINS_HOME, and the Jenkinsfiles that depend on them. Each item maps to a cost line. For example, a controller that relies on CloudBees operations center features will need a different replacement than one that only runs pipelines, and the review records that difference. Ask for the inventory to be confirmed by your platform team before costing starts, because undocumented controllers are the most common reason a comparison drifts from reality.
The cost components are split into one-time work (planning, plugin replacement, Configuration as Code design, pipeline migration and testing) and recurring work (infrastructure, plugin and Java upkeep, LTS upgrades, backups, on-call and any support partner). The review states who is paid for each line, your staff, your cloud provider, CloudBees or DeployOpen, so you can see where spend moves rather than disappears. Confirm the CloudBees license end date and renewal terms with CloudBees directly, since they determine when the recurring line stops.
How DeployOpen scopes a fixed-price Jenkins implementation
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from CloudBees CI to open-source Jenkins, we start with a written scope that lists every controller, plugin, credential store and pipeline to be carried over before any work begins.
How we scope
- Inventory every CloudBees CI controller, its installed plugins and any CloudBees-only features in use
- Record which deployment secrets, credentials and build artifacts must be exported or re-created before cutover
- Agree deliverables, timelines and the license end date in writing before work starts, since engagements are fixed-scope
How we build
- Build Jenkins controllers, dedicated agents and Configuration as Code files inside your cloud accounts, data centers or air-gapped networks
- Replace operations center and role-based access controls with open-source configuration and authorization plugins, and test each change
- Keep Jenkinsfiles in source control and verify pipeline runs against the original CloudBees CI results before switching traffic
How we hand over
- Document the architecture, backup of the Jenkins home directory, upgrade steps and the plugin list pinned for your environment
- Provide the runbooks, configuration files and test evidence your team and internal auditors need to review the new setup
- Walk your platform and security teams through operations, so ownership of the running system stays with your organization
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing
- Plan Jenkins LTS upgrades and plugin updates with your change management process rather than on an ad hoc basis
- Ask for a written quote that separates one-time implementation work from recurring retainer work and infrastructure you pay for directly
