Getting Started with Jenkins

Jenkins is an open-source automation server you run on your own machine. CI/CD (Continuous Integration / Continuous Delivery — the practice of automatically building, testing, and shipping your code on every change) needs something to actually do the work, and for nearly two decades Jenkins has been that something. It is old, it is everywhere, and even in 2026 a huge number of companies still run it. This page shows you what Jenkins is, when to reach for it, and how to install it on Ubuntu and run your very first job.

What is Jenkins and when should you use it?

Jenkins is a self-hosted CI/CD server. “Self-hosted” means you install and run it on a server you control, instead of using a cloud service that someone else manages. You give Jenkins your build steps (compile, test, deploy), and it runs them automatically — on a schedule, on a button press, or whenever you push code to Git.

Its superpower is plugins. A plugin is a small add-on that teaches Jenkins a new trick (talk to Slack, build Docker images, deploy to AWS, and thousands more). There are over 1,800 of them. Almost anything you can imagine, a plugin already does.

Its weakness is its age. Jenkins predates the cloud-native world. It can feel clunky, the UI is dated, and you are responsible for patching, backups, and security. Compare it to the modern options:

Tool	Hosting	Config	Best when
Jenkins	Self-hosted (your server)	UI or Jenkinsfile	You need full control, on-prem builds, or unusual plugins
GitHub Actions	Cloud (GitHub)	YAML in your repo	Your code already lives on GitHub
GitLab CI	Cloud or self-hosted	YAML in your repo	You use GitLab

When NOT to use Jenkins: if you are a small team already on GitHub or GitLab, use their built-in CI instead. You will skip the entire job of running and securing a server. Reach for Jenkins when you need on-premises builds, air-gapped networks, or a plugin nothing else has.

Step 1 — Install Java

Jenkins runs on the JVM (Java Virtual Machine — the runtime that executes Java programs), so you need Java first. Jenkins 2.x needs Java 17 or 21. We will use the OpenJDK 21 package on Ubuntu 22.04 / 24.04 LTS.

sudo apt update
sudo apt install -y fontconfig openjdk-21-jre
java -version

Output:

openjdk version "21.0.7" 2026-04-15
OpenJDK Runtime Environment (build 21.0.7+6-Ubuntu-0ubuntu124.04)
OpenJDK 64-Bit Server VM (build 21.0.7+6-Ubuntu-0ubuntu124.04, mixed mode, sharing)

Step 2 — Add the Jenkins apt repository

Jenkins is not in Ubuntu’s default repositories, so we add the official one. We first download Jenkins’ signing key (a file that lets apt verify the packages are genuine), then point apt at the repo.

sudo wget -O /usr/share/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key

echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian-stable binary/" \
  | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null

sudo apt update
sudo apt install -y jenkins

The package ships a systemd service (systemd is the program Ubuntu uses to start and manage background services). The installer starts Jenkins for you. Confirm it is running:

sudo systemctl status jenkins

Output:

● jenkins.service - Jenkins Continuous Integration Server
     Loaded: loaded (/usr/lib/systemd/system/jenkins.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-06-15 10:12:03 UTC; 8s ago
   Main PID: 4821 (java)
      Tasks: 41 (limit: 4677)
     Memory: 412.3M

If it is not running, start and enable it (so it survives reboots):

sudo systemctl enable --now jenkins

Step 3 — Open the firewall

Jenkins listens on port 8080 by default. If you use ufw (Uncomplicated Firewall — Ubuntu’s simple firewall tool), allow that port:

sudo ufw allow 8080
sudo ufw reload

Security gotcha: never expose raw port 8080 to the public internet. In production, put a reverse proxy (a server that sits in front of your app and forwards requests to it) like Nginx in front of Jenkins, terminate HTTPS there, and restrict 8080 to localhost. Plain HTTP means your admin password travels in clear text.

Step 4 — Unlock and set up Jenkins

Open http://your-server-ip:8080 in a browser. Jenkins asks for an initial admin password to prove you own the server. It wrote that password to a file on disk during install:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Output:

a1b2c3d4e5f64789a0b1c2d3e4f50617

Paste it into the web page. Jenkins then offers two choices:

• Install suggested plugins — the safe default. It installs the common essentials (Git, Pipeline, credentials, etc.).
• Select plugins to install — pick your own. Choose this only if you know exactly what you need.

For your first install, click Install suggested plugins. After that finishes, create your admin user (username, password, email) and confirm the Jenkins URL. You land on the dashboard.

Step 5 — Create your first freestyle job

A freestyle job is the simplest kind of Jenkins task: a named set of build steps you configure with point-and-click forms. (Later you graduate to pipelines defined in a Jenkinsfile, covered on the next page.)

1. On the dashboard, click New Item.
2. Enter a name like hello-job, choose Freestyle project, click OK.
3. Scroll to Build Steps, click Add build step, choose Execute shell.
4. Paste a simple command:

echo "Hello from Jenkins!"
echo "Build number: $BUILD_NUMBER"
date

5. Click Save, then click Build Now on the left menu.

Under Build History, a new build appears. Click it, then Console Output to see what ran:

Output:

Started by user admin
Running as SYSTEM
Building in workspace /var/lib/jenkins/workspace/hello-job
[hello-job] $ /bin/sh -xe /tmp/jenkins123.sh
+ echo Hello from Jenkins!
Hello from Jenkins!
+ echo Build number: 1
Build number: 1
+ date
Mon Jun 15 10:20:41 UTC 2026
Finished: SUCCESS

That green SUCCESS is your first automated build. From here you would connect this job to a Git repository, add a test command, and have Jenkins build on every push.

Best practices

• Run Jenkins behind a reverse proxy with HTTPS — never serve the dashboard over plain HTTP in production.
• Keep Jenkins and its plugins updated — outdated plugins are the most common Jenkins security hole. Patch monthly.
• Back up /var/lib/jenkins — this one directory holds all your jobs, config, and credentials. Snapshot it regularly.
• Use a dedicated build agent, not the controller, for real builds — keep the main Jenkins server lean and secure.
• Prefer pipelines as code (Jenkinsfile) over freestyle jobs once you are comfortable — your build lives in Git, reviewed like any other code.
• Lock down security in Manage Jenkins → Security: enable authentication and matrix-based permissions from day one.

Related Topics

• What is CI/CD?
• Jenkins pipelines
• GitHub Actions intro
• Building Docker images in CI
• CI/CD best practices