We've been running a monorepo with 53 microservices for two years. The CI/CD choice wasn't academic; it was a cost and performance constraint. We benchmarked CircleCI and Jenkins on the same hardware (8-core, 32GB nodes). The results are specific, but the patterns are universal.
**The Setup:** A single monorepo, push triggers a build matrix for affected services. Average commit touches 2-3 services, but full rebuilds happen nightly. Docker builds, unit tests, and integration tests per service.
**Jenkins (Pipeline-as-Code)**
We used Jenkins with the Job DSL plugin and shared libraries. The pipeline is a directed acyclic graph (DAG) to handle dependencies. The core logic for determining changed services lives in a shared library.
```groovy
// Simplified example from our shared library
def buildMatrix = changedServices.collect { svc ->
return [
name: svc,
parallelSteps: [
{ buildDocker(svc) },
{ runUnitTests(svc) }
]
]
}
buildParallelMatrix(buildMatrix) // Custom function to fan-out
```
*Performance:* Full rebuild (53 services) took ~42 minutes on 5 agents. Incremental builds (~3 services) took ~7 minutes. Main cost is agent upkeep and scaling logic (we used EC2 auto-scaling). Zero per-minute fees, but operational overhead is real.
**CircleCI (Orbs + Workflows)**
Config is more declarative. We used dynamic configuration via `setup` workflows and the `path-filtering` orb to generate the matrix.
```yaml
# .circleci/config.yml snippet
jobs:
build-test:
parameters:
service-name:
type: string
docker:
- image: cimg/go:1.19
steps:
- checkout
- run: ./scripts/build.sh <>
workflows:
discover-changes:
jobs:
- path-filtering/filter:
mapping: |
microservices/<>/.* true
config-path: .circleci/affected.yml
```
*Performance:* Full rebuild ~38 minutes using their `medium`+ class containers (4 vCPUs). Incremental builds ~5 minutes. The queue time for free agents was a bottleneck; paid concurrency removes this. Cost scales linearly with concurrent tasks.
**The Trade-Off**
*Jenkins* wins on pure infra cost and control. You manage the agents, so you can optimize for your stack (e.g., large memory instances for Java services). The pain is in monitoring and maintaining the Jenkins master, securing it, and scaling agents. It's a part-time job.
*CircleCI* wins on reduced operational overhead and faster incremental builds due to better caching semantics out-of-the-box. The cost model is predictable but can become significant with high concurrency needs. You are bound to their execution environment.
For a team with dedicated platform engineers, Jenkins can be optimized to be more performant and cheaper. For a team wanting to focus on shipping features, CircleCI reduces cognitive load but introduces vendor lock-in and recurring cost. Our benchmark showed a 15% raw time advantage for CircleCI on incremental builds, but at 3x the monthly cost given our concurrency needs.
What's your team's tolerance for operational work versus flexible spending? The answer dictates the choice.
-- ow
I'm a marketing tech lead at a mid-sized SaaS company, and I run the CI/CD for our marketing platform stack, which includes our main app and all the supporting services. Our team moved from Jenkins to CircleCI about a year ago for a similar monorepo setup, though we're at about 30 microservices.
My take on the two from a practitioner's view:
1. **Initial Setup and Developer UX:** Jenkins required a dedicated half-week for me to get the pipeline-as-code with shared libraries working correctly, especially for dependency graphs. CircleCI had us pushing builds in a few hours because the monorepo and matrix logic fit their orb/concept model. The trade-off is that Jenkins is infinitely customizable if you have time, while CircleCI gives you a faster path to a standard, clean UI for the team.
2. **Real Cost Beyond Sticker Price:** With Jenkins on your hardware, your main cost is engineer time to maintain the master and agents. I tracked about 5-8 hours a month of our team's time just keeping plugins compatible and agents healthy. CircleCI's main cost is compute minutes; for your 50+ services, watch for the "parallelism" upcharge. Our bill jumped from $1.5k/mo to nearly $4k/mo when we needed more concurrent builds, which happens often with monorepos.
3. **Where It Clearly Breaks:** Jenkins breaks on plugin conflicts and scaling logic - you have to build your own caching and fan-out logic, as your snippet shows. CircleCI breaks when you need fine-grained control outside their model, like complex approval flows between service groups or integrating with on-prem artifacts. Their caching is great until you hit a monorepo with massive node_modules, then you need custom logic anyway.
4. **Maintenance and Vendor Support:** Jenkins has zero vendor support unless you pay for CloudBees, and you'll be on Stack Overflow a lot. CircleCI support is responsive but often gives templated answers until you escalate. For a business-critical pipeline, the lack of immediate, expert support for Jenkins was our final push to switch.
Given your numbers and monorepo focus, I'd actually recommend CircleCI if your team values velocity over absolute cost control. But the recommendation flips if you have the in-house Jenkins expertise and your main constraint is budget. To make it clean, tell us if you have a dedicated platform engineer and whether your finance team cares more about cloud spend or internal payroll cost.
trial junkie