What is Jenkins? CI/CD and self-hosting
Author: Domeny.ForSale editorial team Published
In brief: Jenkins is an open-source automation server that helps development teams build, test and deploy applications. It is most commonly used for CI/CD processes: regularly checking code changes and preparing new versions for release. You can run it on your own server with Linux, but you then take responsibility for maintenance, updates and security.
What Jenkins does—and what it does not do
Jenkins runs tasks according to a defined sequence: it fetches code, runs commands, saves results and reports success or failure. A task can start after a change in the repository, on a schedule or at a user’s request. A repository stores code along with its change history.
However, Jenkins is not a system for managing developers or a replacement for a work-planning tool. It automates technical tasks rather than assigning responsibilities or assessing the team. Nor does it replace a version control system such as Git, though it can work with one.
Typical uses include:
- building applications, which means turning code into a form ready to run or distribute;
- running tests and code quality checks;
- preparing packages or container images;
- publishing results and deploying applications to a chosen environment.
Jenkins coordinates these activities but usually relies on other tools to perform them. It does not compile every language itself or include tests for a particular application—it runs commands prepared by the team.
How Jenkins supports CI/CD
CI, or continuous integration, involves frequently merging code changes and automatically checking whether the application still builds correctly and passes its tests. This helps the team detect sooner when a new change has broken an existing feature. However, passing these checks does not guarantee that there are no bugs: it depends on the scope and quality of the tests.
CD can mean continuous delivery or continuous deployment. With continuous delivery, a verified version is ready for release, but making it available to users may require approval. With continuous deployment, a change that meets the defined conditions goes into production automatically. Production is the environment used by real users.
Jenkins does not dictate which of these models to use. You can configure tests alone, a complete deployment or a process requiring manual approval before release. Simply installing the tool does not create a CI/CD process—you still need to define the steps, success criteria and how failures will be handled.
Pipeline: a recipe for getting work done
A pipeline describes the successive stages of automation. In Jenkins, it is often written in a Jenkinsfile file stored alongside the application code. This allows changes to the build process to be reviewed and versioned much like changes to the program itself.
Imagine a team developing an online shop. After a change is pushed to the repository, Jenkins can carry out the following procedure:
- Fetch the specified version of the code.
- Install dependencies and build the application.
- Run tests, such as checks on shopping cart total calculations.
- Save an artifact—the output of the build, such as an application package.
- Deploy that package to a test environment.
- Wait for approval from an authorized person before deploying to production.
If the shopping cart test fails, a correctly configured pipeline will stop the subsequent stages. The team will receive the execution result and logs: records of how the commands ran that help identify the cause of the problem.
A practical rule is to deploy the same artifact that previously passed testing. Rebuilding the application before release can produce a different result, for example if the dependencies being downloaded have changed.
Self-hosting Jenkins on Linux: what needs maintenance
You can host Jenkins yourself on Linux, including as a service or in a container. It requires a compatible Java environment. Before installation, check the official documentation for the requirements of your chosen Jenkins version, supported Java versions and the recommended installation method.
In larger setups, Jenkins separates coordination from execution. The controller manages jobs and configuration, while agents run build and test operations. This separation lets you match execution environments to projects and reduce the load on the controller.
Self-hosting gives you control over the environment, but also brings specific responsibilities:
- updating Jenkins, the operating system and the plugins that extend its functionality;
- managing access and credentials, such as tokens;
- creating backups and checking that the configuration can be restored;
- monitoring disk space, logs and resource usage.
Running code from untrusted people requires particular care. An automation job executes commands, so it should not receive unnecessary access to secrets or production infrastructure.
When to choose Jenkins
Jenkins can be a good choice when a team needs flexible processes, integration with various tools or the ability to run tasks on its own infrastructure. It is also useful when the application release process includes unusual steps that do not fit easily into a simple workflow.
That flexibility comes at a cost: someone has to maintain the configuration and troubleshoot the server and plugins. If a small team only needs a few tests after each change, a CI/CD service provided alongside its repository may require less maintenance.
Before choosing a tool, start with one process: fetching the code, building the application and running tests. Check whether you can reproduce it reliably and decide who will be responsible for maintaining it. Add automatic deployment only after defining permissions and how to roll back a faulty version.
See also: What is API?
Read also
