Jenkins pipelines and delivery
Jenkins is still running the pipelines of a large part of the industry, particularly where builds touch on-premise systems or hardware. We maintain those pipelines, and we modernise them when there is a reason to.
Jenkins in practice
Jenkins has a poor reputation earned by a specific failure mode: jobs configured by hand in a web interface, understood by one person, and impossible to recreate. Jenkins with declarative pipelines in version control is a different tool — one that runs anywhere, reaches systems no hosted runner can, and costs nothing per build minute.
That reach is why it persists. Builds that need to touch on-premise systems, sign with hardware security modules, or drive physical test devices are not going to run on a hosted runner. Where none of that applies, hosted CI is usually less work — and we will say so rather than defending the incumbent.
What we build with Jenkins
Declarative pipelines in version control rather than jobs configured by hand and known only to whoever made them.
Scheduled and per-commit suites — including Selenium and Appium jobs against real devices and browsers.
Pipelines inside a private network, where a cloud-hosted runner is not an option for policy reasons.
Is Jenkins right for you?
Ask usA good fit when
- Builds that must run inside a private network
- Pipelines driving physical devices or specialised hardware
- Heavy build workloads where per-minute billing would hurt
- Organisations with existing Jenkins investment and expertise
Probably not when
- Small teams who would be better served by hosted CI
- Projects with nobody to maintain the controller and agents
- Straightforward cloud-native builds with no special access needs
What we run alongside Jenkins
The rest of the setup, and why each piece is there. We keep this list short on purpose — every dependency is something someone has to maintain.
- Declarative pipelines
- Jenkinsfile in the repository, so the build is versioned with the code it builds.
- Shared libraries
- Common pipeline logic across projects, rather than copy-paste between jobs.
- Configuration as Code
- Controller configuration in a file, so it can be rebuilt rather than reconstructed.
- Ephemeral agents
- Containers or cloud agents per build, so state never accumulates.
- Credentials plugin
- Secrets managed centrally, never in job configuration.
Why Jenkins
Let’s talkRuns anywhere
On your own hardware, inside your network, next to systems a hosted runner cannot reach.
A plugin for everything
Two decades of ecosystem means the integration you need almost certainly exists already.
No per-minute billing
On heavy build workloads, self-hosted economics can be dramatically better than hosted CI.
What we get called in to fix
Get a second opinionFreestyle jobs configured by hand
Builds that exist only in the controller’s database. Moving them into pipelines is the single highest-value change.
Snowflake agents
Build machines configured manually over years, where nobody can say what is installed.
Plugin sprawl
Dozens of plugins, several abandoned, each a maintenance and security consideration.
Secrets in job config
Credentials in plain text in job definitions or build scripts.
Jenkins or the alternative
The comparisons we are actually asked to make, answered the way we would answer them on a call.
Actions for cloud-native projects already on GitHub. Jenkins when builds need private network access or specialised hardware.
GitLab CI for an integrated platform. Jenkins when you need its plugin reach or already run it well.
Self-hosted for cost at heavy volume and network access. Hosted for one less thing to operate.
CircleCI
GitHub
GitLab
Ansible
Appium
ArgoCD
AWS
Azure
Cypress
Datadog
DockerGot an idea? Let’s make it real.
Tell us the short version
This could be the first step towards a new and successful collaboration. A one-line idea and a finished spec are both fine — tell us the problem, the deadline you’re working to and what’s in your way.
Keep looking
Frequently asked questions
Only with a reason. If the pipelines are in code and the agents are maintained, Jenkins is not the problem people assume it is.
Yes. Getting job definitions into version control is usually the highest-value change we make to a Jenkins setup.
Yes — controller and agent upgrades, plugin hygiene and the credential handling that tends to be neglected.
Not automatically. Pipelines in code with maintained agents is a perfectly good setup. Migrate when hosted CI would genuinely be simpler for what you do.
Yes — controller and agent upgrades, plugin hygiene, credential handling and converting legacy jobs into pipelines.