Introduction

Sharing a named volume between containers is one of the simplest ways to persist and exchange files in a Docker Compose application. The rule is straightforward: declare the volume once at the top level, then mount the same named volume into every service that needs access to that data.

The Basic Compose Pattern

A named volume is not tied to a single container. Docker manages it separately, which means multiple containers can mount it at the same time.

Here is a minimal Compose example with one writer container and one reader container:

1services:
2  writer:
3    image: alpine:3.20
4    command: sh -c "echo hello from writer > /shared/message.txt && sleep 3600"
5    volumes:
6      - shared-data:/shared
7
8  reader:
9    image: alpine:3.20
10    command: sh -c "sleep 2 && ls -l /shared && cat /shared/message.txt && sleep 3600"
11    volumes:
12      - shared-data:/shared:ro
13
14volumes:
15  shared-data:

Both services mount the same named volume, shared-data. The writer mounts it read-write. The reader mounts it read-only, which is a good safety measure when the second container only needs to consume files.

Start it with:

docker compose up

The reader container will see the file created by writer because both containers are looking at the same volume contents.

Why Use a Named Volume Instead of a Bind Mount

A bind mount points to a specific host path, while a named volume is managed by Docker. Named volumes are useful when you want:

• data persistence without caring about the exact host directory
• a portable Compose file that behaves similarly across machines
• easier lifecycle management through Docker commands

Bind mounts are often better for live source-code editing during development. Named volumes are usually better for application data such as uploaded files, database contents, or generated artifacts.

Sharing the Same Volume at Different Paths

The mount point inside each container does not have to be identical. The volume name is what matters.

1services:
2  app:
3    image: alpine:3.20
4    command: sh -c "echo data > /app/data/out.txt && sleep 3600"
5    volumes:
6      - shared-data:/app/data
7
8  backup:
9    image: alpine:3.20
10    command: sh -c "ls -l /backup && sleep 3600"
11    volumes:
12      - shared-data:/backup:ro
13
14volumes:
15  shared-data:

The same files appear at /app/data in one container and /backup in the other.

Reusing an Existing Volume

If the volume already exists outside the Compose project, declare it as external.

1services:
2  app:
3    image: alpine:3.20
4    volumes:
5      - shared-data:/shared
6
7volumes:
8  shared-data:
9    external: true

That tells Compose not to create or delete the volume automatically. It should attach to the existing Docker-managed volume named shared-data.

What Volume Sharing Does Not Solve

A shared volume gives containers a shared filesystem view. It does not handle coordination for you.

If multiple containers write to the same files, you still need application-level rules around:

• file locking
• atomic writes
• ownership and permissions
• startup ordering

For example, if one container expects a file to exist immediately, but another creates it only after a long initialization step, you need health checks, retries, or explicit orchestration. A shared volume does not magically create synchronization.

Common Pitfalls

The most common mistake is defining separate volume names for each service and expecting the data to be shared. The names must match.

Another mistake is forgetting that named volumes persist after containers stop. If you test repeatedly, old files may still be there. Use docker volume ls and docker volume rm carefully when you want a clean slate.

A third pitfall is ignoring permissions. If one container writes files as one user and another runs as a different user, the second container may fail to read or modify them.

Summary

• Declare the named volume once and mount the same volume into each container that needs it.
• The volume name controls sharing, not the in-container path.
• Use read-only mounts where a service should not modify shared data.
• Named volumes are good for persistent application data and cross-container file sharing.
• Shared storage does not replace coordination, locking, or permission management.