Use case · DevOps & CI/CD
Jenkins hosting
Jenkins is a mature, open-source automation server for CI/CD, run as a controller coordinating agents that execute build and test jobs. Self-hosting it — its normal mode — gives control and sovereignty over builds and code. It needs a reliable controller and enough agent capacity for the job load. Dedicated, EU-hosted infrastructure keeps a Jenkins setup performant and sovereign.
Key points
- Jenkins is a mature, open-source automation server widely used for CI/CD.
- It runs as a controller that coordinates jobs and agents that execute them.
- The controller must be reliable; agents provide the capacity for build and test jobs.
- Its large plugin ecosystem makes it flexible but adds maintenance to manage.
- Self-hosting on EU infrastructure keeps builds, code, and secrets sovereign.
What is Jenkins, and why host it?
Jenkins is an open-source automation server, one of the most widely used tools for continuous integration and delivery, valued for its maturity, flexibility, and enormous plugin ecosystem. It automates the building, testing, and deployment of software, running the jobs of a CI/CD pipeline, and it has been a mainstay of software automation for many years, with a vast range of plugins letting it integrate with almost any tool. Jenkins is typically self-hosted, run on an organisation's own infrastructure, which gives control over it and the builds it runs.
Hosting Jenkins means providing the infrastructure it runs on — a controller that coordinates everything and agents that execute the jobs — resourced and arranged for the pipeline's work. Jenkins's architecture, its resource needs, and its self-hosted nature shape how it is hosted, and getting these right lets Jenkins run pipelines reliably and quickly. This page focuses on hosting Jenkins specifically; the general considerations of CI/CD pipelines are covered on that page, while what follows attends to Jenkins's architecture and what running it well needs, including honestly how it compares to newer alternatives.
Jenkins architecture: controller and agents
Jenkins runs as a controller that coordinates the automation and agents that execute the jobs, a distributed architecture that lets build work be spread across machines. The controller is the central Jenkins server: it holds the configuration, schedules jobs, serves the web interface, and coordinates the whole setup, but it is not usually where the heavy build work runs. The agents are separate machines that execute the build and test jobs the controller assigns them, doing the actual work of building and testing, so that the load is distributed across the agents rather than falling on the controller.
Understanding this division clarifies how to host Jenkins: the controller must run reliably as the coordinating brain, and the agents must provide the capacity to execute the jobs. The controller's role is coordination and configuration, so its reliability matters, while the agents' role is execution, so their compute and number determine the pipeline's build capacity. Separating them lets the build load scale across agents independently of the controller. We host both the Jenkins controller and its agents — a reliable controller to coordinate, and agents resourced and scaled for the build load — so that a Jenkins setup has the coordinating server and the execution capacity its architecture calls for.
The controller: reliability and resources
The Jenkins controller is the heart of a Jenkins setup, holding the configuration and coordinating everything, so its reliability is important — if the controller is unavailable, the whole Jenkins setup is disrupted. The controller holds the jobs' configuration, the setup's state, and the plugins, and it schedules and coordinates the jobs, so it is central to Jenkins working; its failure stops the coordination the pipeline depends on. This makes the controller's reliability, and the safety of its configuration and state, a real concern in hosting Jenkins, more so than for the individual agents which can be more readily replaced.
The controller needs adequate resources for its coordinating role and to serve its interface, and its configuration should be protected. While the controller does not usually run the heavy builds, it coordinates many jobs and serves the interface, needing enough resources for that; and its configuration and state, holding the setup's definition, should be backed up so they can be recovered. We host the Jenkins controller on reliable infrastructure with the resources its coordinating role needs, and support protecting its configuration, so that the controller — the brain of the Jenkins setup — runs dependably and its state is safe, which is important because the whole setup depends on the controller.
Agents: where builds run
The agents are where Jenkins's build and test jobs actually run, so they need the compute for the builds and tests, and enough of them for the job load. The heavy work of a pipeline — compiling code, running tests, building artifacts — happens on the agents, which the controller assigns jobs to, so the agents' compute, memory, and storage determine how fast the jobs run, and the number of agents determines how many jobs can run at once. Underpowered or too few agents make the pipeline slow or leave jobs queuing, so the agents are where much of the pipeline's performance and capacity lie.
Providing agents means machines resourced for the builds and tests, scaled to the job load, so jobs run quickly and in parallel. Build-heavy pipelines need agents with the compute to build fast; pipelines with many jobs need enough agents to run them without queuing; and parallel jobs need enough agents to run at once. Agents can be added to scale the build capacity as the load grows. We provide Jenkins agent infrastructure — machines resourced for the builds and tests, with the capacity to run jobs in parallel and scale with the load — so that the pipeline's work executes quickly across enough agents, rather than being slowed by agents too weak or too few for the jobs.
Plugins and Jenkins's flexibility
A defining feature of Jenkins is its enormous plugin ecosystem, which makes it highly flexible, able to integrate with a vast range of tools and adapt to almost any workflow. Plugins extend Jenkins to work with version-control systems, build tools, deployment targets, notification systems, and much more, so that Jenkins can be configured for nearly any pipeline and integrated with nearly any toolchain. This flexibility, built on plugins accumulated over Jenkins's long history, is much of why it is so widely used and able to fit diverse needs.
The flip side, which is worth being honest about, is that the plugins add maintenance: they must be managed, kept updated, and their compatibility watched, which is part of the effort of running Jenkins. The flexibility plugins provide comes with the responsibility of managing them, and a Jenkins setup with many plugins has more to maintain. This is a real consideration in running Jenkins, though the flexibility is often worth it. We host Jenkins with the infrastructure its plugins and their work need, supporting the flexible setups Jenkins's plugin ecosystem enables — while being clear that managing the plugins is part of running Jenkins, which the infrastructure supports but does not remove.
Self-hosting Jenkins, and security
Jenkins is designed to be self-hosted, run on an organisation's own infrastructure, which gives control over it and keeps the builds, code, and secrets it handles on infrastructure the organisation controls. Being open-source and self-hosted, Jenkins runs where the organisation puts it, under its control, without depending on an external service, and self-hosting on EU infrastructure keeps the code and builds under European jurisdiction. This control and sovereignty are much of why organisations run their own Jenkins rather than depending on a hosted CI/CD service.
Security matters for Jenkins because it is a frequent target and handles sensitive things — source code, credentials, and often deployment access — so securing it is important. Jenkins setups are attacked, and a compromised Jenkins could expose code and secrets or allow malicious builds and deployments, so the controller and agents must be secured, access controlled, and the credentials Jenkins holds protected. Self-hosting on controlled, isolated infrastructure supports this, keeping Jenkins and what it handles within the organisation's control. We host Jenkins on secure, isolated infrastructure under European jurisdiction, so that a self-hosted Jenkins setup keeps its code, secrets, and builds sovereign and supports the security a much-targeted automation server needs.
Jenkins or newer alternatives? — and where we fit
The honest position is that Jenkins is mature, powerful, and flexible, but its maintenance can be involved, and newer CI/CD tools offer more integrated experiences — so Jenkins is an excellent choice for some and not the obvious one for all. Jenkins's flexibility and plugin ecosystem let it do almost anything and integrate with almost anything, which is valuable, but running and maintaining it, including managing plugins, takes effort; newer CI/CD systems, often integrated with code hosting, can offer a more streamlined experience for common cases with less to maintain. Which suits depends on the needs: Jenkins for flexibility and control, newer tools for integration and simplicity.
Where we fit is providing the infrastructure for a self-hosted Jenkins, when Jenkins is the right choice: a reliable controller, agents resourced and scaled for the build load, and secure, isolated hosting for the code and secrets Jenkins handles — in EU datacenters under European jurisdiction, keeping the builds and code sovereign. We are candid that Jenkins is not the only option, and we host the infrastructure for other CI/CD approaches too; we will not pretend Jenkins is always the answer. We provide the dedicated infrastructure a self-hosted Jenkins runs on, not a managed Jenkins service. We are the dedicated, sovereign infrastructure for self-hosted Jenkins — and if Jenkins fits your needs, we can host it well.
Related use cases
Questions
Jenkins, answered plainly
Common questions about hosting for Jenkins.
How is Jenkins structured?
As a controller that coordinates the automation and agents that execute the jobs. The controller holds the configuration, schedules jobs, and serves the interface, but isn't usually where heavy build work runs; the agents are separate machines that execute the build and test jobs, distributing the load. The controller must be reliable; the agents provide the capacity for the jobs.
What makes Jenkins flexible, and what's the downside?
Its enormous plugin ecosystem, which lets it integrate with almost any tool and adapt to nearly any workflow — much of why it's so widely used. The downside, honestly, is that plugins add maintenance: they must be managed, kept updated, and their compatibility watched. The flexibility is often worth it, but managing the plugins is part of running Jenkins.
Is Jenkins still a good choice versus newer CI/CD tools?
It depends. Jenkins is mature, powerful, and flexible, excellent where that flexibility and control matter — but its maintenance can be involved. Newer CI/CD tools, often integrated with code hosting, offer more streamlined experiences for common cases with less to maintain. Jenkins suits flexibility and control; newer tools suit integration and simplicity. We host infrastructure for either.
Planning Jenkins infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.