Installing and configuring Jenkins on CentOS for CI pipelines
Continuous integration has become standard practice across Australian software houses, from the fintech clusters around Sydney's Barangaroo to agtech operations reshaping farms outside Bendigo. Jenkins remains one of the most flexible automation servers available, and pairing it with a CentOS host gives administrators a stable, long-supported platform for build pipelines. The following steps assume a fresh minimal install, but the workflow applies equally when rebuilding onto hardened templates common in regulated industries.
This walkthrough follows the same step-by-step approach used across the Linuxtpoint catalogue. Readers should be comfortable with sudo, systemctl, and basic firewall management, and ideally have a static IP or resolvable hostname ready for the controller node. A small test VM in Brisbane or a parked domain through a local registrar works equally well for a learning environment.
Before opening any ports, remember that the Privacy Act 1988 and the Notifiable Data Breaches scheme require organisations operating in Australia to safeguard build artefacts that may contain personal data. Treating the Jenkins controller as production infrastructure, complete with off-host backups and audit logging, keeps teams aligned with the ACSC Essential Eight maturity goals that many Sydney and Melbourne-based employers expect from their release engineers.
Prerequisites and initial system preparation
A working Jenkins controller needs Java 11 or 17, at least one gigabyte of RAM for small workloads, and a user account with sudo privileges. CentOS 7, CentOS Stream 8, or Stream 9 will all host the long-term support release that the upstream project maintains. Update the system with sudo dnf update -y, or yum update -y on older builds, and confirm the hostname resolves cleanly through DNS or the local /etc/hosts file.
Open the ports in firewalld that the controller and its agents require: 8080 for the web interface and 50000 for inbound agent traffic. If the host will store extensive build caches or container images, managing disk usage through quotas prevents runaway jobs from filling the root filesystem, a common oversight on CentOS deployments that share storage with other services.
| Method | Best for | Maintenance | Rollback control |
|---|---|---|---|
| DNF/YUM package | Bare-metal and VM controllers | YUM auto-updates | Snapshot before upgrade |
| Container image | Ephemeral or scaled nodes | Image rebuilds | Pin a tag in registry |
| Ansible playbook | Fleet of controllers | Centralised roles | Versioned in Git |
| Tarball install | Air-gapped networks | Manual updates | File-level restore |
Adding the Jenkins repository
Import the official GPG key so the package manager trusts future updates, then add the long-term support repository. The key step requires sudo rpm --import https://pkg.jenkins.io/jenkins.io.key followed by creating a repo file under /etc/yum.repos.d/jenkins.repo pointing at https://pkg.jenkins.io/redhat-stable/. Using the stable channel rather than the weekly release gives the predictable lifecycle that finance teams in Melbourne's Collins Street typically request during change-advisory reviews.
After adding the repo, run sudo dnf repolist to confirm Jenkins appears in the list. If the host sits behind a corporate proxy in Perth or Adelaide, configure dnf proxy settings in /etc/dnf/dnf.conf and rerun the repolist check before any package operations, since silent proxy failures are a frequent cause of stale metadata on centrally managed networks.
Installing the Jenkins package
Install Jenkins with sudo dnf install jenkins -y, then enable the service so it starts on boot using sudo systemctl enable jenkins. The package manager pulls Java automatically on minimal installs, but on hardened images where Java was removed for compliance reasons the dependency step surfaces that requirement early. Start the controller with sudo systemctl start jenkins and verify the listening socket with ss -tlnp | grep 8080.
Tail the log with sudo journalctl -u jenkins -f while the service warms up. The first launch generates the initial admin password, which can be read from /var/lib/jenkins/secrets/initialAdminPassword once the startup banner announces that Jenkins is fully online. The whole install generally settles within a minute on a modern VM in a Sydney datacentre or a remote Adelaide office link.
Post-install configuration
Browse to http://<server-ip>:8080 and unlock the controller with the printed password. The setup wizard offers two paths: install suggested plugins or pick them individually. Most Australian teams choose the suggested set, then add Git, Pipeline, SSH Agent, and Credentials Binding afterwards through Manage Jenkins > Plugins. Configuring the local AEST or AEDT timezone inside Global Properties keeps scheduled jobs aligned with standups in Sydney and reduces confusion when nightly builds stamp their logs.
Set up a dedicated build user rather than relying on the original admin account, store SSH keys in the credentials store, and connect to source control through deploy keys scoped to each repository. When troubleshooting, the common Linux commands reference on this site is a quick reminder for grep, find, and journalctl patterns commonly used during plugin debugging.
Securing and managing Jenkins in production
Once pipelines run reliably, harden the controller by disabling the insecure setup wizard, enforcing Matrix authorisation, and enabling CSRF protection in Configure Global Security. Restrict agent JNLP to known subnets and front the web UI with a reverse proxy that handles TLS termination, ideally with certificates issued through a trusted Australian Certificate Authority or the organisation's internal PKI. Rotation of secrets, scheduled plugin updates, and nightly backups of /var/lib/jenkins complete the baseline, and storing those backups on object storage in-region addresses the data-residency concerns that arise under APRA CPS 234 obligations.
The controller's REST API and webhook output slot neatly into wider delivery dashboards that teams already maintain, including tools such as myeasyprojects.net for cross-team visibility across Sydney, Melbourne, and regional offices. Active monitoring of JVM heap, agent count, and build queue length gives capacity problems a chance to surface before nightly pipelines grind to a halt.
The four habits that stay constant regardless of tooling are secure firewalld rules, offline backups, scheduled plugin reviews, and tested upgrade paths on a stable RHEL-family base. Together they turn a fresh Jenkins install into infrastructure that holds up through every Australian financial year-end, every APRA review, and every change of build platform over the long term.