When CircleCI or Jenkins is the better fit for your CI/CD
CircleCI stays the simpler choice when a small platform team does not want to run build infrastructure, and the renewal, credit or concurrency change is the main pressure. Jenkins fits when your team will operate a controller and build agents, must keep secrets and artifacts inside its own network, and accepts ongoing plugin and LTS upgrade work. The decision turns on three questions: who will run the platform day to day, where deployment secrets and build artifacts must physically live, and how much plugin and upgrade work the team is willing to carry.
Start with ownership. A hosted service moves patching, scaling and availability to the vendor, while Jenkins moves them to you. Jenkins expects a controller that only handles HTTP requests and configuration, with builds running on dedicated agents, and all configuration, plugins and secrets stored in $JENKINS_HOME on the controller, so that directory and its backups become a critical asset. Ask who will own controller upgrades, plugin compatibility testing and backup restores, and whether that work is budgeted. Note that Jenkins LTS 2.580.1 stopped bundling several plugins, so upgrade runbooks must account for installing them separately.
Next, map where secrets and artifacts must live. CircleCI's January 4, 2023 incident report told customers to rotate secrets after exfiltration of environment variables and tokens, which is a concrete reason many security teams want deployment credentials held in their own vault. In Jenkins, credentials sit on the controller, so confirm your encryption, access and backup controls for it. Also confirm artifact retention: CircleCI sets 30 days as both default and maximum, so any build history you need for audit must be exported before cutover. If a Jenkins plugin will hold cloud credentials, check its maintenance status and the Jenkins Java support policy before committing, because Java support windows affect the controller itself. Keep a parallel run going until both results and rotated secrets match.
Which scenarios favor CircleCI and which favor Jenkins
This table matches common team situations to the platform that usually fits better, and names the condition that tips the decision. Read each row against your own constraints; where a row depends on facts only your environment can confirm, the condition column says what to check. The main takeaway is that CircleCI suits teams that want the service run for them, while Jenkins suits teams that will own a controller, plugins and build hosts in exchange for control over where builds run.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| Small team that wants zero CI server operations | CircleCI | The team will not staff upkeep of a controller, plugin updates or build agents, and accepts a hosted service that holds its deployment secrets. |
| Regulated team that must run build hosts inside its own network | Jenkins | Build agents must sit in the organization's network and the team can document controller, plugin and secret handling for its assessors. |
| Team with many legacy Java builds and Maven or Ant jobs | Jenkins | Existing Jenkinsfiles, shared libraries or Java-specific plugins already encode the build, so rewriting them into CircleCI config would be the larger task. |
| Team with an existing Kubernetes platform and operations staff | Jenkins | Kubernetes pod agents can run on clusters the team already operates, and the team has capacity to maintain the Kubernetes plugin and LTS upgrades. |
| Team whose builds use CircleCI orbs heavily | CircleCI | Orbs cover most of the pipeline and rebuilding them as Jenkins plugins or shared libraries would take significant engineering time, so confirm orb coverage first. |
| Team that must control build hosts for licensing or hardware reasons | Jenkins | Builds need specific hardware, licensed tools or GPUs that hosted resource classes do not provide, and the team can run its own agents. |
| Team that needs hosted credit-based scaling with little capacity planning | CircleCI | Build volume is spiky and the team prefers paying for hosted capacity over sizing and patching its own agents, after comparing the credit model in a written quote. |
| Team planning a long-term, self-owned CI estate | Jenkins | The organization accepts recurring work on LTS baselines, Java support dates and plugin maintenance, and has named owners for those tasks. |
Where secrets, artifacts and build data live under each option
Moving CI off a hosted service changes where deployment secrets, build artifacts and pipeline configuration sit, and who is responsible for backing them up and protecting them. The cards below set out the exposure and retention limits of CircleCI against what a Jenkins controller in your own network holds and what your team must run around it.
Secrets held by a hosted service
A hosted CI service stores environment variables, tokens and keys for every connected project on its side. In its January 4, 2023 incident report, CircleCI told all customers to rotate secrets after an attacker exfiltrated customer environment variables, tokens and keys along with the encryption keys needed to read them. Before any move, rotate every secret that CircleCI has held, then check whether the old values were ever readable in the app, because CircleCI does not display environment variable values after they are set.
Artifact retention on CircleCI
CircleCI sets 30 days as both the default and the maximum retention for stored build artifacts. Anything older than that window is gone, so release binaries, test reports or compliance evidence needed for an audit must be downloaded through the API or copied to your own storage before the window closes. Ask your team which artifacts are needed for past releases and assign an owner for the export.
Jenkins state in JENKINS_HOME
On Jenkins, the controller holds the configuration, plugins and secrets in $JENKINS_HOME, and the scaling guide keeps build agents separate so the controller handles only HTTP requests and manages the build environment. This makes the controller the item to protect: schedule backups of $JENKINS_HOME, store them off the controller, and test a restore. Retained artifacts and logs also live on your storage, so retention is set by your own policy.
SSO and audit logs under your control
With Jenkins you decide which identity provider signs engineers in, which groups receive build and deploy rights, and where authentication and audit records are kept. Confirm with your identity team how the Jenkins security realm and authorization strategy will map to existing groups, and whether administrative actions are logged to a store your security team can query. Hosted CircleCI access follows the vendor's identity setup, so compare the controls it offers with the ones you need before deciding.
Compliance evidence and its owner
DeployOpen prepares systems, controls and evidence for compliance assessments, including the backup, access and retention records above. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those decisions, so ask your auditor which evidence they expect for secrets rotation, artifact retention and controller backups, and confirm which of these records your chosen platform can export.
What running Jenkins moves onto your team
Running Jenkins means your team owns the upkeep that a hosted CircleCI account handles for you. The main recurring task is the LTS upgrade cycle. Jenkins picks 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 a standing window each cycle to read the Jenkins LTS changelog, test the new controller build against your pipelines in a staging instance, and roll it to production. Budget that work as recurring, not as a one-time migration cost.
Plugin maintenance rides alongside the core upgrades. Jenkins has more than 2,300 community plugins, and the LTS 2.580.1 release stopped bundling several plugins, including the SSH server and JUnit plugins. Any pipeline that relied on them must now have them installed through the plugin manager, or it will fail after upgrade. Keep an inventory of installed plugins and their versions, and confirm which ones your Jenkinsfiles and shared libraries depend on before each upgrade. Java also sets a clock: Java 21 has a planned end of support in September 2027, and Java 25 is supported with a planned end of support in September 2029, according to the Jenkins Java support policy. Confirm the current Java requirements for your Jenkins version before you schedule the next runtime change.
Dedicated build agents add a third area of ownership. The Jenkins scaling guide recommends agents so the controller only handles HTTP requests and manages the build environment, which means your team must provision, patch and retire those agents, whether they are VMs or Kubernetes pods. The controller is the critical asset: all configuration, plugins and secrets live in $JENKINS_HOME on the controller, so it needs tested backups and a restore drill. The primary and backup controller pattern, with a proxy such as HAProxy or F5 routing traffic to the backup, is a design choice rather than a default. Decide whether your recovery target justifies a second controller and the licensing, sync and failover testing it brings.
What drives the cost of CircleCI and Jenkins
What do I pay CircleCI for each month and how do I check it?
CircleCI billing combines a plan, credits consumed by builds and any overage, so the recurring cost depends on how many credits your pipelines use each month. No CircleCI prices were supplied for this page, so take plan fees, credit consumption, per-user charges and overage figures directly from your own invoices and usage reports for the last three to six months. Ask your CircleCI account team to confirm the credit rate for each resource class you use, and to explain how credits change if you add parallelism or larger machines. Those invoice lines form the baseline you compare against the Jenkins side.
What does running Jenkins cost in servers and Kubernetes capacity?
Jenkins itself is MIT-licensed, so the recurring cost is the infrastructure it runs on. The main components are:
- A controller, which the scaling guide says should only handle HTTP requests and manage the build environment
- Build agents, either static machines or Kubernetes pod agents that scale with demand
- Compute, storage for workspaces and caches, and network egress
Your cloud or data center bill for these resources is the figure to quote against CircleCI credits. Ask your team to size peak concurrency from current build logs, since agent capacity is what drives this cost up or down.
Who maintains Jenkins plugins and LTS upgrades, and what does that cost?
Your team pays for plugin and LTS maintenance, which recurs for as long as you run Jenkins. The LTS release line ships a new baseline every 12 weeks, with fixes backported in four-week cycles, and some plugins that were once bundled, such as the SSH server and JUnit plugins, now must be installed separately through the plugin manager. Java support also changes over time, so the Java support policy determines when you must move your runtime. Budget engineering time for each upgrade window and for testing plugin compatibility, and ask any external provider to quote this as a recurring retainer or as a fixed-scope upgrade.
What one-time work is needed to move pipelines from CircleCI to Jenkins?
The one-time costs cover setup, migration and pipeline rewrite. The main items are:
- Converting
config.ymlworkflows and executors into Jenkinsfile stages and Kubernetes pod agents - Replacing orbs with plugins or shared libraries and moving contexts into Jenkins credentials
- Standing up the controller, agents, Configuration as Code files and backup of
$JENKINS_HOME - Running both systems in parallel until builds match
The size of this work depends on how many pipelines, orbs and custom images you have. Ask for the migration inventory and a parallel-run plan to be written into the scope before any work starts.
What recurring operations cost comes from backup, monitoring and storage?
These costs recur because Jenkins holds its configuration, plugins and secrets on the controller. Back up $JENKINS_HOME on a schedule and test restores, because the scaling guide places all configuration, plugins and secrets there. Monitoring controller health, agent availability and queue length also needs tooling and on-call time. Artifact and build log storage grows without limit unless you set retention, and that storage cost recurs. Ask for the expected retention policy, backup frequency and monitoring scope as line items in any quote.
How much staff time does a self-hosted Jenkins need each month?
Staff time is usually the largest recurring cost and the hardest to see on an invoice. Estimate it from the work you will actually perform: plugin updates, LTS upgrades, agent image maintenance, security patches, pipeline support for developers and incident response. Track hours for the first two or three upgrade cycles to get a figure from your own team rather than a generic estimate. Compare that effort with the time your engineers spend today on CircleCI configuration, credit management and support tickets.
What should I ask for in a quote for Jenkins implementation or support?
Ask for a written, fixed scope that lists each deliverable, the environment it runs in and the acceptance criteria. Request separate line items for one-time work (architecture, migration, pipeline rewrite, hardening and documentation) and recurring work (LTS upgrades, plugin maintenance, backups, monitoring and support hours). Ask how each item is priced, what is excluded, who owns the cloud or data center accounts and what happens if the scope changes. DeployOpen does not publish a price list, and a quote follows from the written scope, so provide your pipeline inventory, current CircleCI usage and expected agent capacity first.
Can my team run Jenkins without outside help, and when is support worth buying?
Your team can run Jenkins without an outside provider if it has people who can handle Kubernetes or VM operations, Jenkins administration, backup testing and upgrades on a regular schedule. Outside support becomes worth comparing when those skills are thin, when migration must happen before CircleCI credits run out, or when you need continuous testing or a retainer for upgrades. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope. Compare the cost of a retainer against the staff hours you would otherwise spend on the same tasks.
How a move from CircleCI to Jenkins proceeds
The sequence turns CircleCI pipelines, secrets and build history into a Jenkins setup that has been checked in parallel before CircleCI access ends. Each step closes with an output the team can verify.
Inventory pipelines, contexts and dependencies
The platform or DevOps lead lists every repository with a .circleci/config.yml file, the workflows and jobs in each, the orbs and executors they use, and the CircleCI contexts that hold shared variables. Each project is tagged by owner, deployment target and whether it builds for production. The output is a migration register that names every pipeline, its dependencies and the team that signs off on its cutover. Confirm the list with each owning team, because a pipeline nobody inventoried is usually the one that breaks after cutover.
Export build artifacts before retention closes
Before any pipeline is retired, the team downloads the artifacts and test reports that the business needs to keep, using the CircleCI API or the app. CircleCI sets 30 days as both the default and the maximum artifact retention, so this export has to happen inside that window and cannot wait for cutover. Store the exports in your own compliance-approved location with the build number, commit and date in the file path. The check is a manifest that matches each retained artifact to a build record.
Stand up Jenkins controller and build agents
The infrastructure team deploys a Jenkins controller inside your network, with its $JENKINS_HOME on storage that is backed up, and connects build agents that run on Kubernetes pod agents through the Kubernetes plugin. The controller should only handle HTTP requests and build management, and the scaling guide recommends dedicated agents for that reason. Plugins are installed deliberately from a reviewed list, and Jenkins configuration is kept as code where possible. The output is a controller that can run a test job on an agent pod and restore from backup.
Convert workflows into Jenkinsfile pipelines
Developers rewrite each config.yml pipeline as a Jenkinsfile committed to the same repository, using Declarative syntax where possible. CircleCI workflows become Jenkins stages, Docker executors become Kubernetes pod agents with the required container images, and orbs are replaced with plugins, shared libraries or explicit steps. Contexts are recreated as Jenkins credentials with access limited to the jobs that need them. The output is a Jenkinsfile per project that passes on the agent and has a reviewed diff against the original CircleCI behavior.
Recreate secrets and rotate them
CircleCI does not display environment variable values after they are set, so the team cannot copy them out of the app. The security team obtains the values from the system that owns each credential, enters them into Jenkins credentials, and then rotates every deployment secret, token and key that CircleCI held. CircleCI told customers to rotate secrets after its January 4, 2023 incident, and the same reasoning applies to a planned migration. The check is a log of rotated secrets per system, with CircleCI tokens revoked after cutover.
Run both systems in parallel
For each pipeline, the team runs the Jenkins job and the CircleCI job against the same commits, and compares build status, test results, artifacts and deployment effects. Parallel runs continue while CircleCI credits and plan terms remain in force, so discrepancies can be fixed without a service gap. Developers record each difference and its fix in the migration register. The output is a sign-off per pipeline that the Jenkins result matches the expected outcome for a defined set of builds.
Cut over and retire CircleCI
Once each pipeline is signed off, the team switches webhooks and branch protection rules to Jenkins, disables the CircleCI project, and confirms that deployments and notifications are coming from Jenkins. Access to CircleCI is then reduced to read-only for the audit period, and the subscription is closed only after the team has confirmed that nothing else depends on it. The output is a closed migration register, a record of rotated secrets and a confirmed list of exported artifacts. Ask your security and compliance leads which retention obligations apply before you close the account.
When staying on CircleCI still makes sense
Staying on hosted CircleCI is the right choice when your team does not have spare engineers to run a CI platform. A Jenkins controller needs someone to patch it, manage plugins, back up $JENKINS_HOME and keep build agents healthy, and that work does not stop when a sprint gets busy. CircleCI removes those operations and gives you a managed orb ecosystem, so common tasks such as cloud deployments or notifications can be added with a short config change instead of a plugin review. If your platform team is one or two people, that trade is often worth more than the control Jenkins offers.
The second case is a workload that does not force builds into your network. If your source code, build logs and deployment credentials can sit with a SaaS provider under your existing contracts, and no residency or air-gap rule requires in-house execution, the operational argument for Jenkins weakens. CircleCI also has a Preview that runs existing GitHub Actions workflow files on CircleCI compute, which can reduce the rewrite if you already maintain those files. Confirm the Preview's current status and supported features with CircleCI before you plan around it.
If you need CI inside your own network but do not want to run Jenkins, evaluate CircleCI Server 4.10, which installs into a customer's Kubernetes cluster. Ask CircleCI for the current component list, the supported Kubernetes versions, the licensing terms and the upgrade path, because the cost of that edition is not published and it carries its own operational footprint. Compare it with a Jenkins deployment using Kubernetes pod agents on the same cluster before you decide. Staying on hosted CircleCI is still a weaker answer if the secrets exposure question matters to your auditors, since the 2023 incident described in CircleCI's own report is a reason to ask for detailed secret-handling evidence either way.
Questions buyers ask before switching from CircleCI to Jenkins
How much effort and staff time does moving from CircleCI to Jenkins take?
The effort depends mainly on how many pipelines, orbs, contexts and environment variables you run today, and on how much of your build estate depends on Docker executors or custom images. Jenkins moves the upgrade and plugin work onto your team: you will maintain the controller, the agents, the plugin set and the LTS upgrade cycle, which the Jenkins LTS release line describes as a new baseline every 12 weeks with three LTS releases per baseline. Ask any provider for a written inventory of pipelines, plugins and secrets before agreeing a figure, and ask who will carry the recurring upkeep after handover.
How long does a CircleCI to Jenkins migration take?
No duration is given here because a credible timeline depends on the inventory of pipelines, the number of repositories and the testing needed before cutover. A scoped plan should state the phases, such as converting config.yml workflows to Jenkinsfile stages, rebuilding credentials, running both systems in parallel and retiring CircleCI credits once builds match. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the timeline follows from that scope rather than from a generic estimate.
What do we need to provide for a Jenkins migration?
Plan to provide access and time from several owners at once. Repository owners must grant access to the source and approve changes to build files. Secret owners must be available because CircleCI does not show environment variable values after they are set, so those values must be re-created from their source systems and rotated. Your platform team should supply a Kubernetes cluster if you plan to use pod agents, plus storage and network access for artifacts. Confirm each of these with your own environment before the work begins.
Can our internal team migrate to Jenkins without outside help?
Yes, an experienced internal team can migrate to Jenkins, provided it has people who can write Jenkinsfile pipelines, operate a Kubernetes cluster and own the plugin and LTS upgrade cycle after go-live. The main risks are rebuilding secrets safely, keeping the controller configuration in code and maintaining the backup of $JENKINS_HOME, which holds configuration, plugins and secrets. If those skills or hours are not available, a fixed-scope engagement can cover the gap for the migration phase while your team takes over operations.
Does Jenkins licensing allow us to use it commercially?
Jenkins is distributed under the MIT License, which permits use, modification and redistribution, including inside commercial products and internal business use, provided the license notice is kept. The license text in the jenkinsci/jenkins repository credits Kohsuke Kawaguchi, Sun Microsystems, Inc. and other contributors. Plugins are separate projects with their own licenses, so check the license of each plugin you install. Have your legal team review the full plugin list before production use.
Can Jenkins run in an air-gapped network?
Jenkins can be installed and run without internet access if you mirror its packages, plugins and container images into your network and supply the build tools your pipelines need. The plugin manager and update sites must be served from an internal mirror, and any pipeline step that downloads dependencies must point at an internal repository. Confirm the exact mirroring steps for your Jenkins version, Java version and plugin set during planning, because the air-gapped design depends on your environment and approval process.
How does the Jenkins plugin ecosystem compare with CircleCI orbs?
Jenkins offers more than 2,300 community-contributed plugins, according to the Jenkins homepage, which cover source control, build tools, notifications, cloud providers and deployment targets. CircleCI orbs are reusable packages of configuration, commands and jobs, which are narrower in scope but versioned and shared through the CircleCI platform. The practical difference is ownership: each Jenkins plugin adds maintenance, security review and compatibility checks to your upgrade cycle, while orbs are consumed as CircleCI-managed packages. Inventory the orbs you use and map each to a plugin, a shared library or an in-house pipeline step.
How DeployOpen scopes a CircleCI to Jenkins evaluation
DeployOpen can plan and implement a self-hosted Jenkins environment inside your own cloud account, data center or air-gapped network, so the controller, build agents and their storage stay under your administrators. In scoping, the first decision is the agent model: whether builds run on dedicated agents, on Kubernetes pod agents, or on a mix, because the Jenkins scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment. The written scope should name the agent platform, the storage behind it, and which CircleCI workflows, executors and contexts are in or out of the first phase. Ask for those items to be listed explicitly so the quote can be checked against them.
Beyond the build environment, DeployOpen can convert CircleCI pipelines to Jenkinsfiles, replace orbs with plugins or shared libraries, and move contexts into Jenkins credentials. It can also harden and back up the controller, since all configuration, plugins and secrets live in $JENKINS_HOME on the controller and must be captured in a tested backup routine. Where your auditors expect evidence, DeployOpen can prepare systems, controls and records for compliance readiness, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Confirm with your assessor which evidence they will accept before the work starts.
Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work begins. Ongoing upgrades, including Jenkins LTS and plugin maintenance, and continuous security testing are available as retainers rather than bundled into the initial build. DeployOpen does not publish a price list; a quote follows from the written scope, so the inputs that move cost are the number of pipelines, the plugins that must be installed, the target network model and the testing depth. Ask for those inputs to be priced separately, and ask which upgrade and support items are one-time and which recur.
How DeployOpen helps you evaluate and move off CircleCI
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a CircleCI to Jenkins decision, we start with a written scope that reflects your pipelines, controller and agent layout, and the plugins your teams depend on before any build server is changed.
How we scope
- Inventory the CircleCI config.yml files, orbs, contexts and resource classes that each team relies on today.
- Agree in writing which pipelines, repositories and environments move to Jenkins and which stay on CircleCI during a transition.
- Map the Jenkins plugins, LTS baseline and Java version your builds need before choosing a controller design.
- Define acceptance criteria and the parallel-run period in the written scope, then quote from that scope.
- Engagements are fixed-scope, so deliverables and timelines are agreed before work starts.
How we build
- Stand up a Jenkins controller in your environment with dedicated build agents, keeping the controller free of build workloads.
- Convert representative pipelines into Jenkinsfiles using Declarative or Scripted syntax, stored in your source control.
- Express controller configuration as code with the Configuration as Code plugin, with plugins pinned through your image or Helm chart process.
- Re-create credentials and secrets in Jenkins, since CircleCI does not display stored environment variable values.
- Test each converted pipeline against the parallel-run plan before any cutover is approved.
How we hand over
- Document the $JENKINS_HOME layout, backup scope and restore procedure for the controller, plugins and secrets.
- Deliver a pipeline inventory showing each migrated CircleCI workflow, its Jenkinsfile equivalent and its owner.
- Record the secret rotation completed during migration and export any build artifacts still needed before the CircleCI retention window closes.
- Walk your platform and security teams through the runbooks for upgrades, plugin updates and agent scaling.
- Provide the evidence and configuration records your internal or independent auditors may request for CI controls.
How we support
- Offer ongoing support, LTS upgrades and plugin maintenance as a retainer after handover.
- Plan Jenkins upgrades around the LTS release line and the Java support policy so your team has a dated schedule.
- Run security testing of the Jenkins controller, agents and pipeline definitions as part of continuous testing if you choose.
- Review plugin advisories and bundled-plugin changes before each LTS baseline is adopted in your environment.
- Confirm support terms, response expectations and retainer scope in writing before the engagement starts.
