Selectel Walks Through Installing Jenkins on a Cloud Server: From Resources to a Pipeline

Manual builds and deployment stop working once a project grows faster than its team. Every change to the codebase triggers the same steps: build, run the tests, roll out. The more often you repeat them, the higher the chance of a mistake. Zavur, a frontend developer at Selectel, has posted a guide on Habr that shows how to solve this with Jenkins on a cloud virtual server, from choosing resources to a working pipeline.

The guide appeared on Selectel's corporate blog, and the server in it is ordered through that provider's panel. But the setup itself depends on the provider very little. You can carry it over to any Linux virtual machine.

Why Jenkins instead of built-in CI

GitHub Actions and GitLab CI have an obvious advantage: they live right next to the repository. The price is platform lock-in. Jenkins works differently. It is a standalone, open-source automation server that pulls code from any Git repository and does not care where that repository is hosted.

The project has a long history. It appeared in 2011 as a fork of Hudson and has since grown an ecosystem of more than 1800 plugins. Plugins connect build systems, code scanners, messenger notifications, and cloud APIs. For teams with a mixed stack or a closed network perimeter, this is often the deciding argument.

According to the author, Jenkins can:

• build projects from any Git repository;
• run automated tests;
• build Docker images;
• deploy applications to target servers.

What the guide covers

The article follows the order in which a CI server is usually set up:

• estimating resources for different scenarios, from a small project to heavy builds;
• ordering a virtual server in the Selectel panel;
• preparing the system for installation;
• installing and doing the initial configuration of Jenkins;
• a simple pipeline for building an application automatically.

The resource breakdown is more useful than it might seem. Jenkins is written in Java, and the project's documentation recommends at least 4 GB of RAM and about 10 GB of disk for small teams. A minimum of 256 MB is only good for an experiment. Builds with Docker and heavy tests raise CPU and disk requirements further. If you skimp on the server, the pipeline will fail with out-of-memory errors at the worst possible moment. The announcement does not include the figures from the guide itself, so check the full text of the article.

Where the pitfalls are

Installing Jenkins takes a few minutes. The problems start afterward. Current versions require a supported Java version (17 or 21), and the web interface opens on port 8080 without HTTPS by default. If you leave it that way, the server is accessible to anyone who has its address. Plugins also need regular updates, since vulnerabilities are routinely patched through them.

Another trap is configuration storage. A pipeline assembled by clicking through the interface cannot be reviewed or rolled back. It is better to define it in a Jenkinsfile and keep it in the repository next to the code.

What to do with this in practice

For a team of a few people, this setup covers the basic CI/CD need without extra infrastructure. A sensible order of steps:

• start with a small server and watch memory during builds;
• lock down access to the interface with HTTPS and an IP restriction or VPN;
• define the pipeline in a Jenkinsfile and store it in Git;
• move heavy builds to separate agents once a single server stops keeping up.

The guide is not about AI and not about a new release. It is a practical how-to, useful for junior DevOps engineers and frontend developers who want to stop deploying by hand. Any modern AI coding assistant runs into the same question anyway: where and how to ship the result. Without automated builds and tests, all the speed gained from code generation quickly gets eaten by manual review.