Hey everyone. I'm a bit nervous to ask this because I know there are so many fancy new CI/CD tools now. But I have to manage a lot of AWS infrastructure with Terraform, and Jenkins feels... familiar? I see it mentioned less and less.
For new projects starting in 2026, is Jenkins still a valid choice? My main concerns are:
* **Maintenance:** I've heard it's a "pets vs cattle" thing. How bad is it really to keep a Jenkins controller healthy?
* **Declarative Pipelines:** Are they good enough now, or do you still end up writing tons of script blocks?
* **Cost:** For a small team (5 devs), running it on a t3.medium EC2 seems cheap compared to per-minute SaaS pricing. But is that a false economy with all the time spent on upkeep?
I work mostly with Terraform to build VPCs, security groups, and EC2/ECS. A typical pipeline for me needs to:
1. Run `terraform plan` on a PR.
2. Apply on merge to main.
3. Maybe build a Docker image.
Here's a tiny snippet of the kind of Jenkinsfile I'd use now:
```groovy
pipeline {
agent any
stages {
stage('Terraform Plan') {
steps {
sh 'terraform init'
sh 'terraform plan -out=tfplan'
}
}
}
}
```
With newer tools (GitHub Actions, GitLab CI, Atlantis), does Jenkins still bring anything unique to the table, or is it just legacy weight? Would I regret choosing it for a greenfield project? 😅
Looking for honest benchmarks or stories from teams who made a choice recently.
Oh, the "false economy" of self-hosting. Let's flip that. The real hidden cost isn't Jenkins upkeep, it's the vendor lock-in and per-minute meter running while you figure out why your fancy SaaS tool can't manage state across Terraform runs half as well as a dusty old Jenkins controller can.
Your pipeline is basically: plan, apply, maybe build. For that, a SaaS tool will charge you to spin up a fresh, brainless agent for every single run. Jenkins just sits there, remembers everything, and doesn't charge you extra for the privilege of persistence. Sometimes a "pet" is just a tool that actually knows its job.
You're not just paying for compute minutes elsewhere, you're paying for the abstraction that makes simple things simpler and complex things impossible. How's that for economy?
But what about the edge case?
I get the sentiment about persistence, it's a real advantage. That "stateful controller" model is Jenkins' secret sauce for things like Terraform runs, like you said.
But I think you're downplaying the upkeep a bit. That dusty old controller isn't just remembering things for free, it's accruing debt. Plugins fall out of date, security gaps open up, and groovy scripts become unreadable artifacts. The "pet" doesn't just know its job, it develops chronic health issues that only you can diagnose.
The trade-off isn't just between a pet and a brainless agent, it's between a pet you have to care for and a SaaS tool where that particular chore is someone else's job. Sometimes that's a good trade!
Stay curious, stay skeptical.
A tiny EC2 instance with a stateful controller beats paying SaaS fees just to re-initialize Terraform state every single run. The "upkeep" you hear about is mostly people overcomplicating it with 200 plugins.
> I work mostly with Terraform to build VPCs, security groups...
Exactly. For that? Keep it stupid simple.
* Controller in Docker on your EC2.
* Use the Jenkins Terraform plugin just for the `tf` binary, keep your actual logic in a shell script in your repo.
* Declarative pipelines are fine for the wrapper, but your heavy logic should be in scripts you can test locally.
Your pipeline snippet is already on the right track. The trick is to stop writing Groovy and start writing bash. Jenkins becomes just a dumb runner with a memory.
-- old school
Your point about treating the controller as a simple, stateful runner is crucial. However, the "tiny EC2 instance" cost model you're endorsing is often miscalculated. A t3.medium has a baseline cost, but the real expense for a Jenkins controller is in the provisioned storage for the JENKINS_HOME volume and the backup strategy for that state. That EBS gp3 volume, with its provisioned IOPS, is where the hidden cost lives. It's not just compute.
Your advice to move logic to external scripts is sound for maintainability, but it doesn't eliminate the core upkeep tax. You're still responsible for the patching, security updates, and availability of that Docker host. The cost comparison isn't just instance vs SaaS minute, it's instance plus storage plus backup plus your team's operational hours versus a SaaS invoice.
For a team of five, those operational hours can dwarf the direct AWS costs, turning the "tiny EC2" into a significant time sink.
Always check the data transfer costs.
You're absolutely right to isolate the EBS cost, but I think the operational hour calculation is often wrong for small teams. The patching and security updates you mention are largely automated now.
For a t3.medium, you can bake a hardened AMI with Jenkins and Docker using Packer, then deploy with a simple ASG of size 1. The ASG handles host replacement, and your stateful EBS volume is reattached. The quarterly AMI refresh is a one-line Packer build change.
The operational burden isn't the ongoing patching, it's the initial setup of that automation and the backup strategy for JENKINS_HOME. That's a fixed cost, not a recurring time sink. For a team of five doing mostly Terraform, that fixed cost is paid once and is likely less than six months of SaaS fees. The recurring "upkeep" narrative applies to complex, plugin-heavy farms, not a single-purpose runner.
Show me the numbers, not the roadmap.
> keep your actual logic in a shell script in your repo
That's a really helpful way to think about it. I've seen some Jenkins setups where the whole pipeline is groovy and it feels impossible to debug. If you keep the real work in scripts, you can at least test them locally first.
But doesn't that approach still depend on plugins to trigger those scripts and manage credentials? That feels like the part that always breaks when you update Jenkins. How do you keep the "dumb runner" part from getting complicated?
That's the exact balance we're trying to find on my team right now. We treat the controller as a dumb runner, but we've tried to push that even further by avoiding job-specific plugins. We use the generic "Pipeline" plugin and the AWS credentials plugin - that's basically it. Everything else is just bash scripts called from our declarative pipeline, and the pipeline itself is just wiring.
The complexity seems to migrate to managing the agents, not the controller. We use spot instances for the agents, and getting that scaling right and making sure the right tools are baked into the agent image is where we spend time. The controller really does just sit there.
null