Open-source alternative to CloudBees CI high availability: the short answer
If your CloudBees CI renewal depends on active/active high availability, the short answer is that community Jenkins has no active/active controller replicas. Availability is achieved with a primary and backup controller behind a proxy such as HAProxy or F5, with controller sharding across teams or projects, and with ephemeral Kubernetes agents that keep builds off the controller. Each pattern accepts a different amount of downtime: a failover pattern accepts an interruption while the backup takes over, sharding limits the blast radius of one failed controller, and ephemeral agents make individual build failures cheap to retry. The Jenkins scaling guide, published on Jenkins architecting for scale, describes these patterns, and Jenkins itself is distributed under the MIT License, so the software carries no license fee for any of them.
Recovery design starts with where state lives. The Jenkins scaling guide states that all configuration, plugins and secrets to back up sit in $JENKINS_HOME on the controller, so a backup controller is only as current as the replication or restore process that feeds it. Before you choose a pattern, confirm three things in your own environment: how often $JENKINS_HOME can be copied without losing job history, whether your secrets can be restored to a second controller without a manual rekey, and whether a proxy health check can detect a failed primary. Ask the CloudBees account team which of their availability features your team actually uses, then map each one to one of these patterns. That mapping, not the license line item, is what determines the downtime you can accept.
Which CloudBees CI availability capabilities map to open-source Jenkins
This table maps each availability capability in CloudBees CI to the open-source Jenkins pattern that covers it, with notes on where active/active behavior is not matched. Read the coverage column first, since it shows what you must design, test and confirm yourself before accepting downtime.
| Capability | Open-source Jenkins option | Coverage notes and what to confirm |
|---|---|---|
| Active/active controller replicas | No native equivalent in open-source Jenkins. Run a primary and backup controller behind HAProxy or F5 for failover. | Not matched. Open-source Jenkins does not run concurrent active controllers on one job set. Confirm the downtime window you accept and how in-flight builds are handled during a switch. |
| Failover to a standby controller | Primary and backup controller arrangement, with a proxy routing traffic to the backup if the primary fails, as described in the Jenkins scaling guide. | Partial. Failover is a manual or scripted process you build and test. Confirm who performs the switch, how the backup stays current with $JENKINS_HOME, and how long a recovery takes in your environment. |
| Build capacity on dedicated agents | Dedicated build agents so the controller handles HTTP requests and manages the build environment, per the Jenkins scaling guide. | Matched for capacity, not for controller uptime. Agent loss does not stop the controller, but queued builds wait. Confirm agent monitoring and replacement procedures. |
| Ephemeral Kubernetes agents | Jenkins Kubernetes plugin, which starts agent pods per build and removes them afterward. | Matched for agent recovery, not for the controller. Confirm cluster capacity, pod security settings and how the controller reconnects after a cluster incident. |
| Horizontal growth by adding controllers | Controller sharding: separate controllers for new teams or projects, as described in the Jenkins scaling guide. | Matched for isolation and load, but each controller is still a single point of failure for its own jobs. Confirm ownership boundaries and which shared services each controller depends on. |
| Controller configuration backup | Back up $JENKINS_HOME, which holds configuration, plugins and secrets, and rebuild settings with Configuration as Code from YAML files. | Partial. Configuration as Code does not install plugins, so pin plugin versions in images or the Helm chart. Test restores, and confirm how secrets are stored and encrypted in your backups. |
Three open-source availability designs and the downtime each accepts
Open-source Jenkins has no built-in active/active controller mode like CloudBees CI, so availability comes from the architecture you build around it. The three designs below trade failover speed, operational effort and the handling of in-flight builds against each other, and none of them removes downtime entirely.
Primary and backup controller behind a proxy
A second Jenkins controller runs as a standby, and a proxy such as HAProxy or F5 routes traffic to it when the primary fails. The Jenkins scaling guide describes this arrangement. It fits a single team or a small set of teams that need a quick recovery path without many controllers. Check that $JENKINS_HOME is replicated to the backup, since all configuration, plugins and secrets live there. Measure the failover window in your own environment, because the time depends on health checks, storage replication and plugin startup. Builds running on the failed controller are lost or must be restarted, and the backup must not run as an active writer on the same data.
Controller sharding by team or project
Each team or project gets its own Jenkins controller, so a failure affects only that group's pipelines. This matches the scaling guide's horizontal growth model and suits organizations where teams have different plugins, credentials or release calendars. The downtime accepted is partial: one controller can be down while the others keep building. The trade-off is operational load, because each controller needs its own backups, upgrades, plugin management and access rules. Shared state such as credentials and global libraries must be managed consistently across shards, and cross-team pipelines may need extra coordination.
Ephemeral Kubernetes agents with a recoverable controller
Build work runs on short-lived agent pods created by the Kubernetes plugin, so the controller holds no build state beyond its configuration. If the controller fails, you restore it from a backup and reconnect the agents, rather than keeping a live standby. This fits teams already operating Kubernetes with a tested restore procedure. The restart window is the time to rebuild the controller from backup and resume scheduling, which you must measure. Builds in flight at the failure point stop and must be rerun. Plan for the Kubernetes cluster itself, since agent scheduling depends on the API server and its etcd backups, and confirm that Secrets used by the controller are encrypted at rest.
Why the controller's $JENKINS_HOME decides how much downtime you accept
In open-source Jenkins, the controller's $JENKINS_HOME decides how much work you can lose during a failover, because it holds the configuration, installed plugins, jobs and secrets for the whole instance. The Jenkins scaling guide says all of this lives on the controller, so a backup or standby controller is only as current as the copy of $JENKINS_HOME it has. A primary and backup pair behind HAProxy or F5 fails over quickly only if the backup already holds a recent copy. If the copy is hours old, every job configuration change, credential and plugin update made since then must be recreated by hand, and the recovery point is set by how often you replicate, not by the proxy.
The practical lever is to shrink what must be replicated. Store controller settings in a jenkins.yaml file loaded through the Configuration as Code plugin, which reads the path set in CASC_JENKINS_CONFIG (default $JENKINS_HOME/jenkins.yaml), and keep every pipeline in a Jenkinsfile in source control. Jobs and settings then rebuild from Git, and only runtime state such as build history and secrets must be copied. Confirm which secrets your team will source from an external store, since Jenkins credentials are still held on the controller unless you move them out.
Configuration as Code does not install plugins, a point the plugin documentation makes explicitly. Plugin provisioning therefore has to be part of the design, usually by baking a pinned plugin set into a controller image or deploying through the official Helm chart, so that a replacement controller starts with the same plugins. Check the plugin list against the LTS changelog before each upgrade, because Jenkins LTS 2.580.1 stopped bundling several plugins, including the SSH server and JUnit plugins, and those must now be installed explicitly.
Moving high availability from CloudBees CI to open-source Jenkins
This sequence replaces CloudBees CI active/active high availability with a documented primary and backup controller pair, dedicated or ephemeral agents and a tested failover path, so the team knows what downtime it accepts before cutover.
Measure current availability and failover needs
The platform owner and the teams that depend on Jenkins record which pipelines must keep running during a controller failure, how long a stalled build queue is tolerable, and how the current CloudBees CI active/active setup behaves when a replica fails. Write these as numbers the business has signed off, such as recovery expectations for release pipelines and nightly jobs. Done when each critical pipeline has a named owner and an agreed maximum interruption that the open-source design must meet or openly exceed.
Inventory CloudBees-only HA features and plugins
The engineering team lists every CloudBees CI feature the current HA design relies on, including replica coordination, managed controller settings and any CloudBees-only plugins, and maps each one to an open-source equivalent or to a gap. Check the Jenkins LTS 2.580.1 changelog, which stopped bundling several plugins including the SSH server and JUnit plugins, so any installation that depends on them must install them explicitly through the plugin manager. Done when a spreadsheet shows each feature with its replacement, its owner and any gap that needs a decision.
Build the primary and backup controller pair
The platform team deploys a primary Jenkins controller and a backup controller in separate failure domains, with the shared configuration kept in code so both can be rebuilt from the same source. The Jenkins scaling guide describes a proxy such as HAProxy or F5 routing traffic to the backup when the primary fails, and the team should confirm that the chosen proxy and failover method fit its network. Done when both controllers start from the same configuration, and the proxy sends a test request to the active controller.
Set up backup and sync of JENKINS_HOME
The operations team defines how the controller state is copied to the backup and how it is backed up separately. The Jenkins scaling guide notes that configuration, plugins and secrets live in $JENKINS_HOME on the controller, so this directory and its encryption keys must be included in backup scope and kept out of unprotected storage. Restore one backup to a scratch host and confirm that jobs, credentials and plugins come back. Done when a documented restore succeeds and the team records how long it took.
Move builds to dedicated or ephemeral Kubernetes agents
The platform team moves build execution off the controllers onto dedicated agents or ephemeral agents created by the Kubernetes plugin, so the controller only handles HTTP requests and coordination. Pipeline definitions stay in Jenkinsfiles in source control, and the team confirms that build tools, cloud access and secrets reach agents through the approved path. Done when pipelines run on agents, the controllers show no build load, and a failed agent pod is replaced without manual work.
Test failover and rollback before cutover
The team runs planned failover tests where the primary controller is stopped, the proxy shifts traffic to the backup, and a representative pipeline completes. Record the time to recover, any builds lost or re-queued, and whether webhooks and credentials still work. Rehearse the rollback too, returning traffic to the original CloudBees CI environment and keeping it running until the open-source design has passed several tests. Done when the failover results are written down and the rollback has been performed once in a test window.
Export build history and cut over traffic
Before the CloudBees CI license end date, the team exports build logs, test results and artifacts that the organization must retain, because hosted and managed CI retention periods are limited and not designed for long-term records. Point webhooks and user access at the new proxy, announce the window to dependent teams, and watch the first production pipelines. Done when traffic runs on the open-source controllers, exported history is stored in the agreed archive, and the CloudBees CI environment is kept only for the rollback period.
Which availability design fits which environment
When the platform team already runs Kubernetes, the usual pattern is a single Jenkins controller deployed with the official Helm chart or the installation guide for Kubernetes, paired with the Kubernetes plugin so build agents start as ephemeral pods that disappear after each job. Availability then depends on the cluster more than on Jenkins itself: the controller pod is restarted by the scheduler, and its state lives on a persistent volume that holds $JENKINS_HOME. Losing a controller pod interrupts running builds, which is the downtime this design accepts.
- Controller state: Back up
$JENKINS_HOMEon a schedule and test restores, because configuration, plugins and secrets all live there. - Control plane: If you need a highly available cluster, you operate its etcd members, load balancer and certificate lifecycle yourselves.
- Upgrades: You own Kubernetes version upgrades, Jenkins LTS upgrades and plugin compatibility checks across both.
- Secrets: Kubernetes Secrets are stored unencrypted in etcd by default, so enable encryption at rest or use an external store.
- Agent pods: Define pod security settings and resource limits for agent templates.
Confirm with your Kubernetes distribution vendor which control plane high availability options and storage classes they support, and confirm your storage vendor's snapshot behavior before relying on it for controller recovery.",
On traditional virtual machines, the design Jenkins documents for availability is a primary controller and a backup controller behind a proxy such as HAProxy or F5, which routes traffic to the backup if the primary fails. The backup is not an active peer: it must be kept current with the primary's $JENKINS_HOME data, and in-flight builds on the failed controller are lost. Growth is usually handled by adding controllers per team or project rather than by making one controller active/active.
- Replication: You choose and operate the mechanism that keeps the backup's home directory current, and you verify it.
- Failover: Failover is a runbook you write and rehearse, including how and when someone switches the proxy.
- Agents: Keep build agents on separate machines so the controller only handles HTTP requests and manages the build environment.
- Configuration drift: Use Configuration as Code so the backup can be rebuilt from YAML and plugin lists rather than manual edits.
- Monitoring: Alert on controller health so the failover decision is not left to chance.
Confirm with your hypervisor and load balancer vendors how they handle health checks, session persistence and virtual IP failover, and confirm the recovery point and recovery time your own business continuity plan requires.",
In air-gapped or tightly regulated networks, Jenkins still runs entirely inside your boundary, but every dependency must be mirrored in. Plugins, Java runtimes, base images and Kubernetes or virtualization packages reach the network through an approved transfer process, so upgrades take longer to plan. Many regulated teams accept a primary and backup controller design here because it needs no external service, and keep the Kubernetes plugin for ephemeral agents where the cluster is already approved.
- Dependency mirror: You maintain internal copies of plugins, Jenkins LTS packages and Java builds, with a record of what was imported and when.
- Java support: Check the Jenkins Java support policy against your approved runtime before each LTS upgrade.
- Evidence: Keep change records for controller configuration, plugin versions and failover tests, since these support compliance assessments.
- Access control: Restrict who can change controller configuration, because the controller holds credentials for every connected system.
- Backups off site: Store controller backups in a location that meets your residency and encryption rules.
Confirm with your security and compliance owners which failover evidence auditors will request, and confirm with each vendor whether their installers or images can be fully mirrored without calling external registries.
What your operations team takes on after replacing active/active
Replacing CloudBees CI active/active high availability with a primary and backup controller moves the failover work from the vendor's design to your operations team. The Jenkins scaling guide describes a proxy such as HAProxy or F5 routing traffic to the backup when the primary fails, but it does not make that switch automatic in every case. Someone must monitor the primary controller, define what counts as a failure, and decide when to fail over. Confirm how your proxy health checks work and who receives the alert at night and on weekends. All configuration, plugins and secrets live in $JENKINS_HOME on the controller, so the backup must receive a current copy of that directory, and you should test that a restored copy starts cleanly.
Failover only works if it is rehearsed. Schedule failover tests that move traffic to the backup, run a set of representative pipelines, then fail back and check that build history, credentials and agent connections are intact. Each test should record what was switched, how long builds were queued, and which steps needed manual work. Patching is the other recurring duty. Jenkins LTS releases ship in four-week cycles with backported fixes, and each new baseline arrives about every 12 weeks, so your team must decide how quickly to move each controller and which plugins to update with it. Plugin updates are the most common source of breakage, so stage them on a non-production controller first. The Java support policy also sets the runtime: Java 21 is listed with a planned end of support in September 2027, and Java 25 is listed as supported with a planned end of support in September 2029. Track these dates against your own upgrade calendar.
If agents run as ephemeral pods on a Kubernetes cluster through the Kubernetes plugin, the cluster adds its own upgrade obligation. The Kubernetes version skew policy requires the API server to be upgraded one minor version at a time and before the kubelets, and kubelets may be up to three minor versions older than the API server. Kubernetes publishes three supported minor releases at once, so plan cluster upgrades before a version falls out of support. Your team also owns the etcd backups that protect the cluster state, which the Kubernetes etcd guidance calls for, and the control plane must sit behind a load balancer if you build a highly available cluster. Ask your platform team who owns each layer, because a controller outage can come from the proxy, the controller, the plugin set, the cluster or etcd.
Questions buyers ask about replacing CloudBees CI high availability
Can open-source Jenkins run active/active like CloudBees CI?
Not in the same way. Open-source Jenkins does not ship CloudBees' active/active high availability for controllers, so the usual open-source design is a primary and backup controller behind a proxy such as HAProxy or F5, which routes traffic to the backup if the primary fails. The Jenkins scaling guide describes this arrangement. Only one controller serves jobs at a time, so a failover interrupts in-flight coordination and the backup must be brought up with current state. Growing capacity is handled differently, by adding controllers for new teams or projects (sharding), with dedicated build agents doing the work. Confirm the failover behavior, recovery time and job disruption with your own tests before you rely on it.
What does running open-source Jenkins cost, and what drives it?
The Jenkins software itself is MIT-licensed, so there is no per-controller license fee. The recurring costs are the components you run: compute and storage for controllers, backup and standby controllers, build agents, the Kubernetes cluster that hosts them, plugin upkeep and testing, upgrades, and staff time or a support partner. Costs rise with the number of controllers, the number of plugins, the size of build fleets and how often you patch. Ask any provider for a quote that separates one-time setup from monthly operations, lists each component, and states which plugins and integrations are included. Compare that with your CloudBees CI licensing and support terms line by line.
How long does a migration off CloudBees CI high availability take?
The duration depends on the number of controllers, the CloudBees-only features in use, the size of the plugin set and how many pipelines depend on operations center or RBAC configuration. Other factors include whether Jenkinsfiles are already in source control, whether secrets can be recreated in a secrets manager, and how much testing the team requires before cutover. No duration can be stated without a scoped inventory. Ask for a written plan with phases, a rollback point for each controller and the criteria that must pass before cutover, and confirm the timeline against your own environment before accepting it.
What must our team do itself, and what does DeployOpen scope?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Your team typically keeps decisions on business ownership, change approval, access policy and which pipelines must move first. Ongoing upgrades and support are available as retainers. Ask for a responsibility matrix in the written scope that shows who performs each task, who approves it and who holds the on-call duty after handover.
Can controller state be restored from backup, and how do we test it?
Yes, provided the backup covers everything that defines the controller. The Jenkins scaling guide notes that configuration, plugins and secrets live in $JENKINS_HOME on the controller, so that directory and the credentials it holds must be backed up and encrypted. Configuration as Code can reduce what lives only in the UI by keeping settings in YAML (located through CASC_JENKINS_CONFIG), though it does not install plugins. Test restores on a separate cluster at a set cadence, measure how long a restore takes, and confirm that jobs, credentials and agent connections work afterward. Record each test as evidence for your auditors.
How do etcd backups and Kubernetes Secrets encryption affect the design?
They shape the recovery plan. Kubernetes stores Secrets unencrypted in etcd by default, so Jenkins credentials that are projected into the cluster need encryption at rest, least-privilege RBAC on list and watch access, or an external store through the Secrets Store CSI Driver. The kubeadm high availability guide describes stacked or external etcd topologies with at least three control plane nodes and a TCP load balancer in front of the API server on port 6443. Kubernetes documentation recommends a five-member etcd cluster in production and a backup plan using etcdctl snapshot save, with etcdutl for restores. Your etcd backup and encryption keys must be protected separately from the Jenkins backup. Confirm these choices with your Kubernetes platform team.
Which CloudBees CI high availability features need replacing?
The main gaps are the operations center, centrally managed controllers, role-based access control at scale, and the active/active failover behavior. Open-source Jenkins covers much of the pipeline layer through Jenkinsfiles, the Kubernetes plugin for ephemeral agents, Configuration as Code and the plugin manager. You will need to rebuild or source the remaining pieces: governance across many controllers, centralized credential handling, audit trails that meet your policies, and a monitoring and alerting setup for failover. Ask each provider to map every CloudBees feature your organization uses to a named replacement, a named owner and a verification step, and confirm the mapping against your own configuration.
The cost components of a self-hosted HA design
The main cost of a self-hosted high availability design is recurring engineering time, not licensing. Open-source Jenkins has no license fee, so the budget for a primary and backup controller behind a proxy such as HAProxy or F5 is made up of infrastructure, Kubernetes capacity, storage, and the people who keep the design working. Ask any quote to break these out separately: the standby controller and its proxy, the Kubernetes cluster that hosts the agents, the storage and backup for $JENKINS_HOME, and the staff time for failover tests and upgrades. Confirm with the vendor or integrator whether each line is one-time or recurring, because a design that is cheap to build can still be expensive to run.
The cluster has a fixed floor of components. The kubeadm high availability guide calls for at least three control plane nodes behind a TCP load balancer on port 6443, and a production etcd cluster should have an odd number of members, with five recommended. Each node, load balancer and etcd member adds hardware or cloud capacity that recurs every month. Etcd also needs a tested backup plan, using etcdctl snapshot save for backups and etcdutl for restores, so budget storage for snapshots and time for periodic restore drills. Kubernetes Secrets are stored unencrypted in etcd by default, so encryption at rest, least-privilege RBAC or an external secrets store should appear as explicit line items. Ask whether these controls are included in the fixed scope or charged as extra work.
Upkeep is where most of the recurring effort sits. Jenkins LTS releases arrive in a regular cycle, and the Java support policy sets dates for each Java version, so each upgrade means testing both controllers, the plugins and the agent images. Plugin upkeep is also ongoing, and the 2.580.1 LTS release stopped bundling several plugins that some teams depend on. Kubernetes minor versions are supported for a limited window, so the cluster itself needs upgrades on a fixed schedule. When requesting a quote, ask for the number of planned failover tests per year, the upgrade process for both Jenkins and Kubernetes, and who owns plugin updates after handover. A written retainer, if chosen, should state exactly which of these tasks it covers.
How DeployOpen scopes, delivers and supports a Jenkins high availability design
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Jenkins high availability design, that means agreeing in writing which controller topology, failover path and agent model fits your recovery targets and team, then building and testing it in your environment.
How we scope
- Written scope lists the controller topology, proxy or failover design, and agent model agreed before work starts
- Current CloudBees CI high availability behavior is inventoried, including plugins, jobs and shared dependencies
- Downtime accepted by a primary and backup design or a sharded design is recorded for your sign-off
How we build
- Primary and backup controllers are built with $JENKINS_HOME backup and restore procedures defined
- Ephemeral Kubernetes agents and their cluster prerequisites are configured and load tested in your environment
- Failover is exercised in test runs so the switch from primary to backup is observed rather than assumed
How we hand over
- Configuration as Code files, Helm or container definitions, and runbooks are delivered as project documentation
- Operators are trained on failover steps, controller upgrades and plugin management under the LTS release line
- Handover records list open risks, such as single-controller dependencies, so your team can decide on them
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainer scope, including Jenkins LTS upgrade cycles and failover retests, is agreed in writing
- Compliance readiness work prepares controls and evidence, while independent auditors issue any assessment outcome
