Introduction

If Jenkins runs in Docker, the most important mount is usually not source code or build output. It is JENKINS_HOME, because that directory stores jobs, plugins, credentials, and controller state. Without a persistent volume, recreating the container also recreates an empty Jenkins controller.

The Core Mount You Usually Need

The official Jenkins image uses /var/jenkins_home as the main data directory. A named Docker volume is the standard way to persist it:

1docker volume create jenkins_home
2
3docker run -d \
4  --name jenkins \
5  -p 8080:8080 \
6  -p 50000:50000 \
7  -v jenkins_home:/var/jenkins_home \
8  jenkins/jenkins:lts

This gives you:

• a persistent Jenkins home directory
• a controller that survives container replacement
• a cleaner separation between runtime image and state

If the container is removed and recreated with the same volume, Jenkins keeps its configuration.

Named Volume Versus Bind Mount

There are two common mounting patterns.

Named volume:

-v jenkins_home:/var/jenkins_home

Bind mount:

-v /srv/jenkins_home:/var/jenkins_home

Named volumes are simpler and Docker manages their location. Bind mounts are useful when you want direct visibility into the files on the host or need to integrate with existing backup tooling.

For most local and server setups, a named volume is the easier default.

Understand What Lives in JENKINS_HOME

That mounted path contains more than just a few config files. It usually includes:

• installed plugins
• job definitions
• credentials store
• user configuration
• build history metadata

That is why losing the volume is operationally much more serious than losing the container. The container can be recreated from an image. The Jenkins home directory is the real state.

Mounting Extra Paths

Sometimes you also need other mounts. Common examples include:

• a host directory for backups
• a Docker socket for Docker-based builds
• certificates or trust stores

Example with a bind mount for backups:

1docker run -d \
2  --name jenkins \
3  -p 8080:8080 \
4  -p 50000:50000 \
5  -v jenkins_home:/var/jenkins_home \
6  -v /srv/jenkins_backups:/backups \
7  jenkins/jenkins:lts

Each extra mount should have a clear purpose. Do not mount arbitrary host paths just because a job might need them someday.

Be Careful with the Docker Socket

A common pattern is:

-v /var/run/docker.sock:/var/run/docker.sock

This allows Jenkins jobs to talk to the host Docker daemon. It is convenient, but it also gives Jenkins strong control over the Docker host. That is a real security decision, not a harmless convenience flag.

If possible, prefer isolated agents or purpose-built build containers rather than letting the controller container manage the host Docker engine directly.

Permissions Matter

Mount problems are often really permission problems. If Jenkins cannot write to the mounted directory, plugin installation and job state persistence will fail in confusing ways.

This matters especially with bind mounts. The host directory ownership and the container user must be compatible. If Jenkins starts but cannot save configuration, check filesystem permissions before blaming Jenkins itself.

Verify Persistence

After starting the container, create a small visible change such as a test job, then restart the container:

docker restart jenkins

If the job is still present afterward, the volume is doing its job. If the controller comes back empty, the wrong path was mounted or the container was using ephemeral storage instead.

Common Pitfalls

• Running Jenkins in Docker without mounting /var/jenkins_home at all.
• Confusing a named volume with a bind mount and backing up the wrong thing.
• Mounting host paths without checking file permissions.
• Assuming the container is the important asset when the real state lives in JENKINS_HOME.
• Mounting the host Docker socket without understanding the security implications.

Summary

• The main Jenkins Docker mount is usually /var/jenkins_home.
• Use a named volume or bind mount so Jenkins state survives container replacement.
• The volume stores plugins, jobs, credentials, and controller metadata.
• Extra mounts should be deliberate, especially the Docker socket.
• If persistence or plugin installs fail, check path selection and filesystem permissions first.