Jenkins was our CI/CD server for four years. It worked. It was also, honestly, a beast to maintain. Plugin dependency hell, the occasional inexplicable build failure that required SSHing into the Jenkins server to diagnose, security updates that broke things, and a UI that looks like it was designed in 2011 because it mostly was.
When we started a new project in July last year, we decided to go native with GitHub Actions rather than bring Jenkins along. Six months in, here's the full picture.
What Got Better
Zero infrastructure maintenance. No Jenkins server to patch, no plugin updates to manage, no disk space to monitor. This alone recovered probably half a day per month of developer time that was going to infrastructure babysitting.
YAML co-located with code. Workflow files live in the repository. They're version controlled, reviewed in PRs, and changed with the same workflow as everything else. With Jenkins, the pipeline configuration was in a separate system that wasn't always in sync with the code. PR reviews now include CI changes.
The Marketplace. The GitHub Actions Marketplace has actions for almost everything. Deploying to ECS, building Docker images, running security scans, posting Slack notifications — all of these are three-line configurations referencing a community action rather than an installed plugin requiring server-level maintenance.
What We Miss (or Lost)
Build history and analytics. Jenkins has better long-term build history and analytics than GitHub Actions. We could see trend data on build times, flaky test patterns, and failure rates over months. GitHub Actions' retention is 90 days by default and the analytics are more limited.
Self-hosted runners are more work than expected. We use self-hosted runners for builds that need specific hardware or access to internal network resources. Setting these up and maintaining them is not dramatically simpler than maintaining Jenkins build agents. This surprised us.
Concurrency controls. Jenkins had sophisticated job concurrency controls for things like "only run one deploy at a time per environment." GitHub Actions' concurrency controls are improving but we've had a few cases where they didn't behave as expected.
The Cost
For our usage, GitHub Actions costs roughly the same as our Jenkins server did, factoring in the EC2 instance and EBS storage. Not a significant cost driver either way. The operational maintenance saving is the real cost win.
Would We Do It Again?
Yes. The reduction in infrastructure maintenance overhead and the improvement in developer workflow (PRs that include CI changes, faster onboarding because new devs already know GitHub) are real and ongoing benefits. If you're starting a new project, GitHub Actions is the obvious default. If you're on Jenkins and it's working fine, the migration cost is real — don't do it just because it's new.
