Docker Mount: Volumes, Bind Mounts, and tmpfs Explained

So you’ve just stopped the Docker container to update a configuration file, but when you restarted it, every piece of data was gone. I've been there.

This happens because containers are ephemeral by default – when they’re removed, any data stored inside their writable layer disappears. Real applications can't work this way. You need databases that persist, config files that survive restarts, and logs you can actually access.

Docker mount solves this problem by connecting container storage to external locations. There are three types: volumes for production data, bind mounts for development workflows, and tmpfs for temporary files stored in memory.

In this article, I’ll walk you through how to choose the right mount type for your use case and implement it correctly. To understand everything covered in this article, you’ll need a decent grasp of Docker and containerization. Take our Intermediate Docker course to quickly get up to speed.

How Docker Handles Storage

Docker containers use a layered filesystem that treats everything as temporary by default.

When you build a Docker image, each instruction in your Dockerfile creates a new read-only layer. These layers stack on top of each other like a deck of cards. If you pull an Ubuntu image with Python installed, you’ll get one layer for the base OS and another for Python.

The catch is that all these layers are read-only. You can't modify them.

The container filesystem and writable layer

When you start a container, Docker adds one more layer on top - the writable container layer.

This is where all changes happen. Every file you create, config you modify, and table record you add lives here.

It sounds great, but the problem is that this layer is tied to the container's lifecycle.

When you stop and remove the container with docker rm, the writable layer is gone. Everything you’ve worked on is gone. Docker won’t ask for confirmation. It just deletes everything.

This design makes sense for stateless apps that don't need to remember anything between runs. But real applications aren't stateless.

Why mounts are necessary

The writable layer has two major problems for production environments.

First, you lose data when containers stop. What’s the use of a database container that forgets all rows after a restart? I can’t think of any besides running integration tests for your app.

Second, you can't share data between containers. Say you're running a web app and a background worker that both need access to the same files. If those files live in the writable layer of one container, the other container can't see them.

Docker mounts solve both problems by connecting containers to storage that exists outside the container lifecycle. You can mount a directory from your host machine or a Docker-managed volume. Your data persists even when containers are removed. Multiple containers can mount the same location and share files in real time.

That's why you need to use mounts. Let’s go over mount types next, and then I’ll show you how they work.

Docker Mount Types at a Glance

Docker gives you three ways to handle persistent data, and each one solves different problems. Here's what each type does and when you should use it.

Volumes

Volumes are Docker's default answer to persistent storage.

Docker creates and manages volumes for you in a dedicated directory on your host machine. You don't need to know where that directory is, it’s all handled for you. This makes volumes portable across different systems and safe to use in production.

When you remove a container, the volume stays intact. If you start a new container and attach the same volume, all your data will be right where you left it.

Volumes work best for production databases, application state, and any data you can't lose.

Bind mounts

Bind mounts connect a specific directory on your host machine directly to a container.

You pick the exact path on your host - like /home/user/project - and Docker maps it into the container. When you change a file on your host, the container will see the change immediately. Change a file in the container, and it shows up on your host.

This real-time sync makes bind mounts perfect for development.

But bind mounts come with risks. They expose host paths to containers and depend on specific directory structures that might not exist on other machines.

tmpfs mounts

tmpfs mounts store data in your host's memory instead of on disk.

Nothing gets written to the filesystem. When the container stops, the data disappears completely. This makes tmpfs mounts useful for temporary data you don't want to persist - think authentication tokens, session data, or cache files you'll rebuild anyway.

That said, tmpfs mounts are limited by available RAM and only work on Linux hosts.

Docker Volumes for Persistent Data

Volumes are Docker's production-ready storage solution, and you should default to using them unless you have a specific reason not to.

They're managed entirely by Docker, work consistently across different platforms, and survive container removal by design. If you're running databases, storing application state, or handling any data that needs to outlive a single container, volumes are the answer.

How Docker volumes work

Docker stores volumes in a dedicated directory on your host machine:

• Linux: /var/lib/docker/volumes/
• macOS: ~/Library/Containers/com.docker.docker/Data/vms/0/data/
• Windows: \\wsl$\docker-desktop-data\data\docker\volumes\, assuming WSL2 backend

You don't manage this directory directly. Docker handles creation, permissions, and cleanup through its own API. This separation means volumes work the same way whether you're on Linux, Mac, or Windows, which in turn makes your container setup portable across development and production environments.

The thing to remember here is that volumes exist independently of any container. When you create a volume, attach it to a container, run your app, then stop and delete that container, the volume stays exactly where it is with all your data intact.

If you start a new container and attach the same volume, your data will still be there.

Creating and reusing volumes

You can create a named volume before starting any container:

docker volume create mydata

Then attach it when you run a container using the --mount flag:

docker run -d \
  --name postgres-db \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

This mounts the mydata volume to /var/lib/postgresql/data inside the container, where Postgres stores its database files.

You can now stop and remove this container, then start a new one with the same volume:

docker rm -f postgres-db

docker run -d \
  --name postgres-db-new \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Your database is back with all tables and rows intact.

That's the whole point of volumes - data persistence across container lifecycles.

Managing and maintaining volume data

You can run this command to check what volumes exist on your system:

docker volume ls

Then, you can run this command to inspect a specific volume to see where it's stored and which containers use it:

docker volume inspect mydata

This shows the mount point on your host and useful metadata. But you rarely need to access this directory directly - that's Docker's job.

If you’re done with the volume and with to remove it, just run this command:

docker volume rm mydata

Docker won't let you delete a volume that's attached to a running container. Stop the container first, then remove the volume.

Finally, if you want to clean up resources and claim back some disk space, you can run this command to remove all unused volumes at once:

docker volume prune

For production setups, Docker supports volume drivers that connect to external storage systems like NFS, AWS EFS, or cloud block storage. You specify the driver when creating the volume, and Docker handles the rest. This lets you store data outside your host machine entirely, which matters for high-availability setups where containers move between servers.

Up next, let’s discuss bind mounts.

Bind Mounts for Local Development

Bind mounts give you direct access to your host filesystem from inside a container, and that's exactly why developers love them.

They're perfect for local development but come with trade-offs that make them risky for production. You get real-time file sync and zero build steps, but you lose portability and can open up security holes.

How bind mounts work

A bind mount maps a specific directory on your host machine directly into a container.

You specify the exact path - like /home/user/myapp - and Docker makes it available at a path inside the container. There's no copying, no Docker-managed storage, no abstraction layer. The container sees your actual host files.

If you change a file on your host, the container sees the change immediately. Likewise, if you modify a file inside the container, it updates on your host. Both sides are working with the same files in real time.

Here's a bind mount in action:

docker run -d \
  --name dev-app \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  python:3.14

This mounts /Users/dradecic/Desktop/app from my host to /app inside the container. When I edit a Python file in /Users/dradecic/Desktop/app using your text editor, the containerized app instantly sees the change.

You can also use the shorter syntax:

Common development workflows

The most common use case is mounting your source code during development.

Say you're building a FastAPI application. You can mount your project directory into the container, enable hot reload, and you've got a full development environment:

docker run -d \
  --name fastapi-dev \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  -w /app \
  -p 8000:8000 \
  python:3.14 \
  sh -c "pip install fastapi uvicorn && uvicorn main:app --reload --host 0.0.0.0"

Just for reference, this is my main.py file:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(
    title="FastAPI Docker Demo",
    description="A minimal FastAPI app running inside Docker",
    version="1.0.0",
)

class Item(BaseModel):
    name: str
    price: float
    in_stock: bool = True

@app.get("/")
def read_root():
    return {
        "message": "FastAPI is running",
        "docs": "/docs",
        "redoc": "/redoc",
    }

@app.get("/health")
def health_check():
    return {"status": "ok"}

@app.post("/items")
def create_item(item: Item):
    return {
        "message": "Item received",
        "item": item,
    }

After running the Docker command, the app is available from my host machine on port 8000:

If you edit main.py in your editor, save the file, FastAPI will reload automatically. No rebuilding images, no restarting containers. You write code like you would locally, but your app runs in a consistent container environment.

Risks and limitations

Bind mounts expose your host filesystem to containers, and that can create security problems.

A container with a bind mount can read and write files on your host. Run a container as root - which is the default - and it has root access to those mounted files. Malicious code or a compromised container can modify or delete anything in the mounted directory.

Portability is another issue.

Bind mounts depend on specific paths existing on the host. The /Users/dradecic/Desktop/app doesn’t exist on your machine or on a production server. This breaks the "works everywhere" promise of containers.

Platform differences are also a thing. Windows and Mac use a VM to run Docker, so bind mounts go through an extra translation layer. This makes file operations slower and can cause subtle bugs with file watching and symlinks.

Production environments should never use bind mounts.

They're too dependent on host-specific paths, too risky from a security standpoint, and impossible to version control. Volumes solve all these problems, which is why they're the production standard.

Treat bind mounts as a development tool - fast, convenient, and powerful, but not something you want anywhere near production.

tmpfs Mounts for Temporary Data

tmpfs mounts store data in your host's RAM instead of on disk. This makes them perfect for data you don't want to persist.

In-memory storage behavior

A tmpfs mount exists entirely in memory.

Docker allocates RAM on your host machine and makes it available as a filesystem inside the container. A file written to a tmpfs mount never touches your disk. The data sits in memory until the container stops.

When you stop the container, everything in the tmpfs mount is deleted. There is no cleanup required, no leftover files, no trace of what was there. Every time you restart the container you get a fresh, empty tmpfs mount.

In a nutshell, tmpfs mounts are for data you explicitly don't want to keep - temporary calculations, session tokens, or sensitive information that shouldn't persist after use.

Typical use cases

The most common use case is storing secrets or sensitive data.

Say you're running a container that needs an API key or database password. Store it in a tmpfs mount, and the secret will never be stored on disk. When the container stops, the secret disappears from memory. There's no file to accidentally commit to version control or leave exposed on the filesystem.

Caches are another good fit. Build artifacts, compiled code, or downloaded dependencies that you'll regenerate anyway don't need to persist. Put them in tmpfs for faster access during the container's lifetime, then let them disappear when you're done.

Temporary files work well here too - think session data, lock files, or intermediate processing results that only matter while the container runs.

Basic configuration

Run this command to create a tmpfs mount using the --tmpfs flag:

docker run -d \
  --name temp-app \
  --tmpfs /tmp:rw,size=100m \
  python:3.14

This creates a 100MB tmpfs mount at /tmp inside the container. The size option limits how much RAM the mount can use.

You can also use the --mount syntax:

docker run -d \
  --name temp-app \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=104857600 \
  python:3.14

The tmpfs-size value is in bytes - 104857600 bytes equals 100MB.

If you don't specify a size limit, tmpfs uses up to half your system's RAM. That's dangerous - for obvious reasons. Always set explicit size limits.

The only big downside is that tmpfs mounts only work on Linux.

Mac and Windows Docker Desktop don't support them because they run Docker inside a Linux VM, and tmpfs requires direct kernel support.

Docker Mount Syntax and Configuration

Docker gives you two ways to define mounts, and picking the right syntax makes your commands easier to read and debug.

Both approaches work, but one scales better when you need advanced options or multiple mounts in a single container.

-mount vs --volume

The --mount flag uses explicit key-value pairs, while -v or --volume uses a colon-separated string.

Here's the same volume mount with both syntaxes:

# Using --mount
docker run -d \
  --mount type=volume,source=mydata,target=/app/data \
  python:3.14

# Using -v
docker run -d \
  -v mydata:/app/data \
  python:3.14

Both create a volume named mydata and mount it to /app/data in the container.

Use --mount for anything beyond basic setups. It's more verbose, but the explicit keys make it clear what each part does. When you add options like read-only access or custom volume drivers, it stays readable while -v can look like a cryptic string.

The -v syntax is fine for simple development workflows where you're typing commands by hand.

Common mount options

The readonly option prevents containers from modifying mounted data:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,readonly \
  python:3.14

This is useful for configuration files or reference data that containers should read but never change. A container trying to write to a readonly mount gets a permission error.

For volumes, the volume-nocopy option skips copying existing data from the container image into the volume:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,volume-nocopy \
  python:3.14

By default, Docker copies whatever exists at the mount point in the image to a new volume. When you set volume-nocopy, you get an empty volume regardless of what's in the image.

For tmpfs mounts, the tmpfs-size option sets a memory limit:

docker run -d \
  --mount type=tmpfs,target=/tmp,tmpfs-size=104857600 \
  python:3.14

This caps the tmpfs mount at 100MB. Without it, a tmpfs mount can consume all available RAM.

Mounting over existing data

When you mount to a directory that already exists in the container image, the mount completely hides whatever was there.

Say your image has a /app/data directory with config files built in. When you mount a volume to /app/data, those config files will disappear. The container sees only what's in the volume.

This happens with all mount types - volumes, bind mounts, and tmpfs. The mounted content takes precedence, and the original directory becomes inaccessible while the mount is active.

Using Mounts with Docker Compose

Docker Compose makes it easy to define and share mounts across multiple containers in your application stack.

Instead of typing long docker run commands with mount flags, you declare everything in a docker-compose.yml file. Let me show you how.

Defining volumes and bind mounts in Compose

Here's a Compose file with both volume and bind mount examples:

services:
  service-1:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - ./code:/app          # Bind mount for development
      - shared:/data         # Named volume shared with worker

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - shared:/data         # Same volume as service-1

volumes:
  shared:

The volumes key under each service defines what gets mounted. Relative paths like ./code create bind mounts, while names like shared reference named volumes.

The top-level volumes section declares named volumes that Compose creates and manages. Both service-1 and service-2 mount the same shared volume, so they see the same files. Write a file from one container, and the other container can read it immediately.

The sleep infinity command keeps containers running so you can exec into them - just for demonstration purposes.

Persisting and verifying data

Start your stack with docker compose up -d, then check if mounts work:

# Write data to the shared volume from app
docker compose exec service-1 sh -c "echo 'test' > /data/file.txt"

# Read it from worker
docker compose exec service-2 cat /data/file.txt

If both commands work, your volumes are configured correctly.

You can now run this command to stop and remove everything:

docker compose down

Your named volumes will still be present. If you start the stack again with docker compose up -d, the data you wrote earlier will still be there. This is how databases persist across deployments - the volume outlives the container.

To delete volumes when you stop the stack, add the -v flag:

docker compose down -v

This removes all volumes defined in your Compose file. Use it when you want a clean slate.

Populating volumes with initial data

The most common pattern is using a separate init container to seed the shared volume:

services:
  init:
    image: ubuntu:latest
    command: sh -c "mkdir -p /source && echo 'initial data' > /source/seed.txt && cp /source/* /dest/"
    volumes:
      - shared:/dest

  service-1:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

volumes:
  shared:

The init container creates seed data and copies it into the shared volume, then exits. Both service-1 and service-2 start after and find the seeded data ready to use.

Compose handles the complexity of coordinating multiple containers and their shared storage in a single, version-controlled file.

Docker Mount Performance and Security

Choosing the wrong mount type can slow down your containers or create security holes you didn't know existed. Read this section if you don’t want that to happen.

Performance trade-offs between mount types

Volumes offer the best performance on Linux because they're stored directly on the host filesystem with no translation layer.

On Mac and Windows, Docker runs inside a Linux VM. Volumes still perform well because they stay inside that VM. On the other hand, bind mounts have to sync files between your host OS and the Linux VM, which adds overhead. File operations on bind mounts can be significantly slower on Mac and Windows compared to native Linux.

tmpfs is the fastest option for read and write operations because everything happens in RAM. No disk I/O, no filesystem overhead. But you're limited by available memory, and data disappears when the container stops.

If you're on Linux and need maximum performance, use volumes. If you're on Mac or Windows and notice slow file operations during development, you're probably hitting bind mount overhead. Switch to volumes for production workloads.

Security implications of mounts

Every mount gives containers access to something outside their isolated filesystem, and that creates risk.

Bind mounts are the biggest concern. If you mount /home/user into a container, a compromised container can read your SSH keys, modify your shell config, or delete files across your entire home directory. Run that container as root - the default - and it has root-level access to those files.

Volumes reduce this risk because they're isolated in Docker's storage directory. A container can't mount arbitrary host paths through volumes. But volumes can still leak data between containers if you share them carelessly.

tmpfs mounts minimize persistence risk - secrets stored in memory disappear when containers stop. But they don't protect against runtime attacks where a compromised container reads secrets from memory.

The general rule is that mounts break container isolation, so use them carefully.

Best practices for safe mounts

Mount only what containers need and nothing more.

Instead of mounting your entire project directory, mount just the subdirectory the container uses. Instead of mounting /var/log with write access, mount it read-only if the container only needs to read logs.

Use the readonly option whenever possible:

docker run -d \
  --mount type=bind,source=/app/config,target=/config,readonly \
  ubuntu:latest

This prevents containers from modifying mounted data, limiting damage if they're compromised.

Run containers as non-root users to reduce the impact of bind mount vulnerabilities. Create a user in your Dockerfile and switch to it before the container starts:

RUN useradd -m appuser
USER appuser

Clean up unused volumes regularly with docker volume prune. Old volumes pile up over time, and they consume disk space and potentially hold sensitive data from deleted containers.

Never mount sensitive host directories like /, /etc, or /var unless you have a specific reason and understand the risks. Each mount should have a clear purpose and minimal scope.

Troubleshooting Docker Mount Issues

Mount problems usually show up as permission errors, missing files, or containers that won't start - and they're almost always caused by the same set of issues.

Here's how to diagnose and fix the most common problems you'll run into.

Permission and ownership errors

Permission errors happen when the user inside the container doesn't have access to mounted files.

Docker containers run as root by default. When root creates a file in a bind mount, that file is owned by root on your host. If you try to edit it with your regular user account, you’ll get a permission denied error.

The reverse happens too. Mount a directory you own into a container running as a non-root user, and the container might not be able to write to it.

You can check file ownership with ls -la on the mounted directory:

ls -la /path/to/mounted/directory

If files are owned by root but your container runs as a different user, you have a mismatch. Fix it by running the container as the same user that owns the files:

docker run -d \
  --user $(id -u):$(id -g) \
  -v ./data:/app/data \
  ubuntu:latest

This runs the container as your current user instead of root, matching the ownership of files in the bind mount.

For volumes, Docker handles permissions automatically when containers create files. But if you're seeing errors, check which user the containerized app runs as and whether it has write access to the mount point.

Path and configuration mistakes

The most common mistake is mounting a path that doesn't exist on the host.

Try to mount /home/user/project when that directory doesn't exist, and Docker will create an empty directory owned by root. Your container starts, but it's mounting the wrong thing - an empty directory instead of your actual project.

Always verify paths exist before mounting them:

ls /home/user/project

If the directory doesn't exist, create it first or fix the path in your mount command.

In Docker Compose, relative paths are resolved from the directory containing your docker-compose.yml file. If your file is in /home/user/app/ and you use ./data, Docker looks for /home/user/app/data.

Move the Compose file, and the mount breaks.

Another common error is mounting to the wrong target path inside the container. Mount to /app/data when your app expects /data, and the app won’t be able to find its files. Check your application's documentation or Dockerfile to confirm where it expects data to be.

Platform-specific quirks

On Linux, bind mounts work directly with the host filesystem.

On Mac and Windows, Docker runs inside a Linux VM. Bind mounts sync files between your host OS and that VM, which creates timing issues. File watchers - tools that reload your app when files change - sometimes miss updates because of sync delays.

Mac and Windows also handle file permissions differently. The VM translates permissions between the host OS and Linux, which can cause files to appear with incorrect ownership inside containers.

Symlinks don't work reliably in bind mounts on Mac and Windows. The VM can't always resolve symlinks that point outside the mounted directory, so files appear missing or broken inside containers.

tmpfs mounts don't work at all on Mac and Windows because the VM doesn't expose tmpfs to the host. If you try to use a tmpfs mount, Docker will silently ignore it or throw an error depending on the version.

If you're developing on Mac or Windows and hitting weird file sync issues, switch to named volumes for better performance and reliability. Save bind mounts for development workflows where real-time sync matters more than perfect consistency.

Conclusion

To wrap things up, use volumes for production data that needs to persist, like databases, uploaded files, application state - anything you can't afford to lose. They're Docker-managed, portable across platforms, and the safest choice for data that matters.

Bind mounts belong in development workflows where you need real-time file sync between your host and containers. When you edit code in your editor, you’ll see changes instantly in your containerized app. But keep them out of production as they're too dependent on host-specific paths and create security risks you don't need.

When you’re ready to dive deeper into containerization and virtualization, check our course: Containerization and Virtualization with Docker and Kubernetes.