Your own Jenkins server: the right box, a private first login, builds on agents

What will your Jenkins server have to hold?

Everything your team builds with: job settings, build history, plugins and the stored credentials your pipelines use, all in one folder Jenkins calls JENKINS_HOME (/var/lib/jenkins once the Ubuntu package is installed). It also answers the web pages your team clicks through all day.

• The floor: it will start with 256 MB of memory and a single GB of disk.
• A small team: 4 GB+ of memory and 50 GB+ of disk, per the install guide.
• As it grows: every connected agent costs the main box 2-3 threads, roughly 2 MB or more, and busy web use adds CPU load.
• At the extreme: the Jenkins hardware page mentions single installations running past 70 GB of memory.

Notice what is missing: the builds themselves. Compiling, testing and packaging happen on agents, so that is where you spend cores.

Which Java, and which release line?

Pick a supported Java before anything else: Jenkins says a controller started on an unsupported version will not run. Then pick a release line. Weekly releases bring fixes and new features about every week. LTS releases start from a baseline chosen every 12 weeks and get a stable update every 4 weeks with backported bug and security fixes. For a server your colleagues rely on, follow LTS; at the time of writing that is 2.580.1, released 30 September 2026 and tested with JDK 21 and 25.

The server that fits

Think of it as two jobs. The main box needs to be steady and well backed up; the agents need raw cores. Our dedicated servers cover both: every one of them is an entire machine, you log in as root, and nobody else is on the hardware.

• For Jenkins itself: one of the everyday single-processor servers, the kind that runs most apps and databases, has room to grow.
• For the builds: the desktop machines pair a fast desktop processor with NVMe and are listed for build jobs; the two-processor servers can run several agents as virtual machines.
• Something unusual: have it built for you; a build from parts we hold takes 4 to 24 hours.

A ready server is yours within 30 minutes of the payment being approved. The port is unmetered, so plugin downloads and artifacts never show up as a bandwidth line. IPv6 costs nothing, there is no contract, and if an install goes wrong you can reinstall the system yourself from the control panel.

Installing it, in the right order

1. Switch the firewall on before Jenkins exists. Allow SSH, check that /etc/default/ufw says IPV6=yes so IPv6 is covered as well, then enable it. The Jenkins package installs a service that launches by itself and listens on port 8080 on every interface (the default address is 0.0.0.0), so have the firewall dropping that port before you run the install.
2. Install Java 21 first. Jenkins warns that adding Java after the package can stop the service from starting because it finds no usable Java.
3. Add the Jenkins signing key and the stable repository, then install the package. The key's filename carries a year, so check the Linux install page for the current one.

grep IPV6 /etc/default/ufw          # should say IPV6=yes
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

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

sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \
  https://pkg.jenkins.io/debian-stable/jenkins.io-2026.key
echo "deb [signed-by=/etc/apt/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 jenkins

One more step, and this one is our addition, built from two documented settings: the --httpListenAddress option from Jenkins' initial-settings page, passed through the JENKINS_OPTS override shown on its systemd page. Run sudo systemctl edit jenkins, type the two lines below into the editor (they are settings, not commands), save, then run sudo systemctl restart jenkins.

[Service]
Environment="JENKINS_OPTS=--httpListenAddress=127.0.0.1"

It pins Jenkins to 127.0.0.1, so even with a firewall mistake later the web interface only answers on the machine itself. If something will not start, journalctl -u jenkins.service shows why.

Your first login, kept to yourself

A fresh Jenkins asks for a one-time password and then lets you create the administrator. Do that through a tunnel on your own SSH login, so nobody else can reach the page while it is waiting.

1. From your computer, run ssh -L 9090:127.0.0.1:8080 you@your-server and leave it open.
2. In that session, print the password with sudo cat /var/lib/jenkins/secrets/initialAdminPassword.
3. Browse to http://localhost:9090, paste it into Unlock Jenkins and press Continue.
4. Take Install suggested plugins if you are unsure; you can add or remove plugins later.
5. Create your own admin account. Skipping it leaves an account called admin whose password is that one-time code.

Giving it a proper web address

When the admin account exists, put nginx in front so your team reaches Jenkins on a normal name. Below is the reverse proxy part of the example in the Jenkins docs, plus one line of ours; it forwards to 127.0.0.1:8080 and passes the headers that WebSocket agents rely on.

upstream jenkins {
  keepalive 32;
  server 127.0.0.1:8080;
}
map $http_upgrade $connection_upgrade {
  default upgrade;
  '' '';
}
server {
  listen 80;
  listen [::]:80;   # IPv6: our addition
  server_name ci.example.com;
  ignore_invalid_headers off;
  location / {
    sendfile off;
    proxy_pass http://jenkins;
    proxy_redirect default;
    proxy_http_version 1.1;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_max_temp_file_size 0;
    client_max_body_size 10m;
    proxy_request_buffering off;
  }
}

The listen [::]:80; line is our addition, so the site also answers over IPv6; once the certificate is in, give it an IPv6 twin, listen [::]:443 ssl, beside the certificate settings. Leave proxy_pass without a trailing slash. Because this listens on plain HTTP, add a certificate before anyone signs in from the internet, allow ports 80 and 443 in ufw, and enter the final address as the Jenkins URL in Manage Jenkins » System.

Keep the builds off the main box

Out of the box Jenkins runs jobs on its own built-in node, and those jobs can read and change the same files Jenkins itself uses. Once your first agent is connected, open Manage Jenkins » Nodes, pick Built-In Node, choose Configure and set executors to 0.

• Only one server for now? The docs accept an agent on the same machine if it runs as a separate user that cannot read or write JENKINS_HOME and cannot use sudo.
• Agents can connect over WebSocket (Jenkins 2.217 onward) through the nginx above, so no extra port has to be opened. The older inbound TCP port stays off unless you switch it on.
• The setup wizard leaves an authorization strategy that gives any signed-in account full control. That is fine while every account belongs to someone you fully trust, and wrong the moment you allow sign-ups or less trusted users; switch to a matrix-based strategy first.
• Keep CSRF protection on. For scripts that call Jenkins, use an API token, which skips the crumb check.

Backups you can bring back

Copying the whole JENKINS_HOME folder keeps everything. To keep copies smaller, the backup guide lists what matters: the .xml settings files, the jobs folder with build records (archived artifacts can be huge), and plugin packages. You can skip workspaces and the unpacked war, cache and tools folders, since they come back by download or rebuild. Store the result away from the server.

Leave secrets/master.key out of the regular backup. That file is the controller key, used to encrypt secrets/hudson.util.Secret, the file that secures your saved credentials, so anyone with both this key and a backup could get at everything. Keep it in a separate, secure place, and check each backup by restoring it into a spare folder and starting it on a spare port.

Questions people ask

Can I start on one server and add agents later?

Yes. Start with Jenkins and one agent on the same machine, the agent under its own user with no access to the Jenkins folder. When builds slow things down, connect a second server as an agent and move the work there.

Where is the password the setup page asks for?

On the server, in /var/lib/jenkins/secrets/initialAdminPassword; Jenkins also prints it in its log at first start. Read it with sudo from your SSH session. It is needed once, to unlock the wizard.

Locked out by your own firewall rule, then what?

You get a console of your own on rack servers and blades, and on two cartridge models (m510 and m710x): the screen and the power button, even when the network is down. On other cartridges you have power control and the reinstall in the control panel.

Is the weekly release a bad idea?

Not for testing new features, but it changes every week. A server your whole team waits on is easier to live with on LTS, which only takes fixes that have already proved themselves in a weekly release.

My code is on GitHub, GitLab or Gitea. Do I still need Jenkins?

Maybe not. If one Git host runs everything, its own pipelines may be simpler: read about a GitHub Actions runner, self-hosted GitLab or Gitea and its runners. Jenkins earns its place when builds span several systems or need its plugins.