Jenkins LTS Installation, Java 21/25 Runtime Planning, Packages, Containers, and Initial Setup: Concepts, Architecture, and Mental Model

1. Installation is a dependency graph, not a download button

A Jenkins controller can appear healthy in a browser while still being operationally unreproducible. If the team cannot say which Jenkins core build is running, which Java starts it, which account owns the process, where JENKINS_HOME lives, which image/package produced the process, and which network path exposes the UI, then a restart or upgrade becomes guesswork.

Chapter 01 separated controller state from queue, agent, workspace, artifact, and external state. Chapter 02 narrows that model to the controller bootstrap itself. The goal is not merely “get Jenkins on port 8080.” The goal is a controller whose runtime identity, durable state, exposure, and recovery assumptions are explicit.

2. The installation mental model

flowchart TD
  A[Choose Jenkins release line and exact LTS] --> B[Choose supported Java runtime]
  B --> C[Choose package, container, WAR, or platform installer]
  C --> D[Define process/service identity]
  D --> E[Bind persistent JENKINS_HOME]
  E --> F[Bind HTTP port / reverse proxy path]
  F --> G[Start controller and read bootstrap logs]
  G --> H[Unlock setup wizard locally]
  H --> I[Install/record plugin baseline + admin identity]
  I --> J[Verify restart, version, persistence, and health evidence]

The sequence matters. Choosing a package before checking Java can yield a service that installs successfully but cannot start. Starting a container before defining a persistent volume can yield a controller that works until the container is replaced. Publishing the setup wizard on an uncontrolled network can expose the one-time bootstrap surface before authentication is established.

3. The seven installation states you must keep separate

4. Java 21/25: runtime compatibility is a controller prerequisite

For current Jenkins LTS releases beginning with 2.555.1, the Jenkins system requires Java 21 or Java 25. That requirement applies to controller and Jenkins system components; it is distinct from the JDK a later build might use to compile an application. A Java 8 or 17 application can still be built with a separately selected toolchain even though Jenkins itself runs on Java 21.

java -version
# Record vendor, major/minor version, and architecture before launch.

5. Package, container, WAR, and platform installer are delivery mechanisms—not different Jenkins products

6. JENKINS_HOME is the durable control-plane boundary

JENKINS_HOME contains controller configuration and operational state. A container image is replaceable; the home directory is not. In a container installation the canonical location is /var/jenkins_home, so a named volume or carefully owned bind mount must be attached there.

docker volume create jenkins-ch02-home
docker volume inspect jenkins-ch02-home

Later chapters will treat backup and restore rigorously. For now, learn the simpler rule: if removing a process/container destroys the only copy of the controller state, you did not create a recoverable installation.

7. Bootstrap exposure is a temporary high-risk state

A fresh controller exposes the setup wizard before a normal administrator account and final plugin baseline exist. In a lab, publish only to loopback:

docker run --name jenkins-ch02-controller --detach \
  --publish 127.0.0.1:8080:8080 \
  --volume jenkins-ch02-home:/var/jenkins_home \
  jenkins/jenkins:2.568.3-jdk21

Binding to 127.0.0.1 is intentionally different from -p 8080:8080, which may expose the listener on all host interfaces. Production deployments normally place Jenkins behind a deliberately configured TLS reverse proxy/load balancer and restrictive network policy; Chapter 29 covers those controls.

8. What to record before clicking through setup

9. Common misconceptions

• “The image tag is the version.” It is a useful human label, but the resolved digest is stronger byte identity.
• “Java 21 means my application must target Java 21.” Jenkins runtime Java and build toolchain JDK are separate decisions.
• “A Docker volume is a backup.” It is persistence, not an independently validated backup.
• “Port 8080 works, so networking is finished.” Production exposure still needs TLS, proxy headers, firewalling, and access-control design.
• “Suggested plugins are a fixed reproducible set.” Their contents evolve; capture the actual installed plugin versions as evidence.

10. Summary

• A reproducible Jenkins installation identifies core/LTS, Java, distribution bytes, service identity, persistent home, network exposure, and bootstrap baseline separately.
• Current Jenkins 2.568.3 LTS is tested with Java 21 and 25; this chapter uses Java 21 for the executable baseline.
• The controller process is replaceable; JENKINS_HOME is durable state and must be mounted/persisted deliberately.
• Bootstrap credentials and the setup wizard are sensitive temporary surfaces; keep them local and out of retained evidence.
• A healthy HTTP response is one piece of evidence, not proof of persistence, compatibility, or security.

Knowledge check

Official references and version notes

• Installing Jenkins — official entry point for supported installation methods and new-installation scope.
• Docker installation — official Jenkins container image, persistent /var/jenkins_home, ports, and setup-wizard workflow.
• Linux installation — current Debian/Ubuntu, Fedora, and RHEL-family package instructions and service management.
• Windows installation — MSI/service-account guidance, Java selection, port configuration, and setup.
• WAR-file installation — standalone Java launch, port selection, and JENKINS_HOME override.
• Java Support Policy — authoritative controller/agent/CLI Java runtime matrix.
• Jenkins LTS changelog — exact LTS release dates, fixes, and tested JDKs.
• Jenkins LTS Upgrade Guide — mandatory reading before upgrades or skipped LTS lines.
• Jenkins Security Advisories — current core/plugin security fixes and affected versions.