Most of what I write is on TheServerSide.
Yes you can run Jenkins in Docker and no it will not instantly fix your automation problems. What it will do is give you reproducible builds fewer "it works on my machine" fights and a cleaner way to manage CI and CD on local hosts or servers. This guide walks through picking a base image creating a Dockerfile building and running the container and keeping data and secrets intact while you sleep or panic politely.
Start with the official Jenkins image unless you enjoy surprises and dependency scavenger hunts. The official image bundles a compatible Java runtime and common entrypoints which makes plugin compatibility less dramatic. If you prefer to shrink layers pick a minimal Linux image with Java preinstalled but expect to add more packages yourself.
FROM jenkins/jenkins:ltsOfficial images save time and sanity in most devops environments where plugin compatibility matters.
Keep layers small avoid running as root and automate plugin installation. The jenkins-plugin-cli is handy for repeatable plugin installs. Use build arguments to pin versions so your image does not magically change tomorrow.
FROM jenkins/jenkins:lts
USER root
RUN apt update && apt install -y git curl && rm -rf /var/lib/apt/lists/*
COPY plugins.txt /usr/share/jenkins/plugins.txt
RUN jenkins-plugin-cli --plugin-file /usr/share/jenkins/plugins.txt
USER jenkins
COPY init.groovy.d /var/jenkins_home/init.groovy.d
Keep plugin lists in a separate file and inject them with a build arg if you want version control for your automation setup.
Use docker build with a clear tag so your CI pipelines are not guessing what to deploy. Watch the logs for missing dependencies and use build args for plugin versions.
docker build -t myorg/jenkins-custom:2025-10-01 .
# optionally
docker build --build-arg PLUGIN_LIST=plugins.txt -t myorg/jenkins-custom:stable .
Map ports mount persistent storage and set a restart policy. Resource limits stop runaway jobs from turning your CI host into molten lava.
docker run -d --name jenkins \
-p 8080:8080 -p 50000:50000 \
-v jenkins_home:/var/jenkins_home \
--restart unless-stopped \
--memory 2g --cpus 1.0 \
myorg/jenkins-custom:stable
Use a named volume or host path for /var/jenkins_home. That directory contains job configs credentials and plugin state so losing it is not a good look.
Open the web UI on the mapped port unlock Jenkins with the initial admin secret found at /var/jenkins_home/secrets/initialAdminPassword or in the container logs. Install recommended plugins and create an admin user. When possible use Configuration as Code for reproducible setups and to avoid a thousand tedious clicks.
Mount a persistent volume at /var/jenkins_home and back it up regularly. Do not put long lived secrets in environment variables. Use the credentials store and consider external secret managers for production. For TLS terminate at a reverse proxy and require authentication for sensitive endpoints.
If you are using this image in CI CD pipelines bake reproducibility into your build steps. Use build args and immutable tags so your pipelines do not change under your feet. In kubernetes mount the Jenkins home as a PersistentVolume and set resource requests and limits to keep agents from eating cluster resources.
Containers make Jenkins easier to manage but they do not replace good configuration hygiene. Keep plugins pinned backups automated and your Jenkins Dockerfile in source control. Do that and you will have a stable CI system that is slightly less likely to ruin your day.
I know how you can get Azure Certified, Google Cloud Certified and AWS Certified. It's a cool certification exam simulator site called certificationexams.pro. Check it out, and tell them Cameron sent ya!
This is a dedicated watch page for a single video.