Jenkins LTS Installation, Java 21/25 Runtime Planning, Packages, Containers, and Initial Setup: Configuration, Design Choices, and Tradeoffs

1. Installation design is a set of coupled tradeoffs

There is no universal “best Jenkins install.” A development laptop, a regulated enterprise service, and an ephemeral test controller have different constraints. The useful question is not “container or package?” in isolation. It is: who owns Java, process supervision, persistent state, patching, network exposure, and rollback?

2. LTS versus weekly: stability cadence versus feature cadence

As of this lesson’s verification date, 2.568.3 is the current LTS point release. The decision rule should outlive that number: select a supported line, track advisories, test upgrades, and record the exact version actually deployed.

3. Java 21 versus Java 25

4. Package versus container versus WAR: who owns what?

5. Direct HTTP in a lab versus TLS reverse proxy in production

Direct HTTP on loopback is appropriate for this disposable chapter because the browser and controller are on the same machine. It is not a production recommendation. Production Jenkins normally requires a stable external URL, TLS termination, correct forwarded headers, deliberate firewall rules, and proxy timeouts appropriate for Jenkins/WebSocket behavior.

flowchart TD
  U[Browser / webhook client] --> P[TLS reverse proxy / load balancer]
  P --> J[Jenkins controller HTTP listener]
  J --> H[JENKINS_HOME]
  J --> A[Agents / external services]
  P -. owns TLS + external exposure .-> U
  J -. owns Jenkins authz + application routes .-> P

Do not disable CSRF, authentication, or authorization to “make the proxy work.” Proxy correctness and Jenkins security are different layers.

6. Mutable tags versus pinned versions and digests

Human-readable tags are convenient for operations and documentation. Digests are better evidence of exact pulled content. A sound workflow often records both:

docker pull jenkins/jenkins:2.568.3-jdk21
docker image inspect jenkins/jenkins:2.568.3-jdk21 \
  --format 'Tag=jenkins/jenkins:2.568.3-jdk21 RepoDigests={{json .RepoDigests}}'

For production automation, you can reference an approved digest or otherwise enforce an image promotion policy. But remember that pinning the image does not pin every Jenkins plugin installed into JENKINS_HOME. Core/image identity and plugin baseline are separate configuration surfaces.

7. Rollback: process bytes are easy; controller data may not be

Containers encourage a dangerous oversimplification: “If the upgrade fails, just run the old image.” Jenkins upgrades can migrate data or plugins can update stored formats. Therefore a real rollback plan includes a tested pre-upgrade backup/snapshot of controller state and the old core/Java/plugin baseline, not only an old image tag.

8. Worked decision table

9. Anti-patterns and why they fail

• Always use latest. You lose a stable human version anchor.
• Pin core but ignore plugins. Plugin/core compatibility remains mutable state.
• Run Windows Jenkins as LocalSystem. It unnecessarily expands compromise impact; use a dedicated service identity when possible.
• Run Linux Jenkins as root. The controller rarely needs host-root authority.
• Publish the setup wizard to the internet. Bootstrap is not a hardened public onboarding endpoint.
• Call a volume a backup. Persistence without independent recovery testing is not disaster recovery.

10. Summary

• Choose release line, Java, distribution, state, network exposure, and rollback as one operational design—not independent defaults.
• LTS is the course default; weekly is a deliberate high-change path, not “better because newer.”
• Java 21 is the lab baseline; Java 25 is supported but should be validated against the actual plugin/tool environment.
• Use direct loopback HTTP for local labs and deliberate TLS/reverse-proxy architecture for production.
• Record both readable version tags and immutable/resolved identities; core/image pinning does not pin plugins or controller data.

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.