Volumes vs Bind Mounts vs tmpfs

Docker gives you three ways to put data somewhere other than the disposable writable layer, and choosing the wrong one is the source of most storage pain. A named volume is Docker-managed storage under /var/lib/docker/volumes — the default for data you care about. A bind mount maps an exact host path into the container — ideal for development, leaky for production. A tmpfs mount lives only in RAM and never touches disk — for secrets and scratch.

This page is the spine of the chapter. The next four take each of these apart in depth, so the goal here is the decision: what defines each mount type, how the flag you type actually selects one, and which job each is the right answer to. Get the distinction clear once and the rest of the chapter is detail.

Named Volumes — Docker-Managed Storage

A named volume is storage Docker creates and owns, living under /var/lib/docker/volumes/<name>/_data and decoupled from any specific host path. You refer to it by name — driftwood-db-data — not by where it sits on disk, and Docker handles the rest. It survives container removal, so the container is disposable while the data is not. For persistent application data like Driftwood's Postgres directory, a named volume is the portable, recommended default, and the one you reach for unless you have a specific reason not to.

Bind Mounts — A Host Path Mapped In

A bind mount takes an exact absolute host path and mounts it straight into the container, so both sides see the same files live. Edit a file on the host and the container sees the change immediately, with no rebuild and no copy — which makes bind mounts the backbone of containerized development. The cost is portability: a bind mount ties the container to that one machine's directory layout, and it inherits the host's file ownership and permissions, so the same command behaves differently on a different host. Good for editing source, sharing a config; wrong as a general persistence mechanism.

tmpfs — Memory Only, Never on Disk

A tmpfs mount lives in the host's memory rather than on the container's filesystem, so its contents are never written to a volume or host path and vanish the moment the container stops. That is not a limitation to work around — it is the entire point. The use case is sensitive scratch: a decrypted secret, a session cache, a token you specifically do not want sitting on disk where it could survive in a backup or a forensic image. (One caveat: under memory pressure the kernel can still page tmpfs data to swap, so it isn't an absolute guarantee that nothing ever touches the disk.) If the data must outlive the process, tmpfs is the wrong tool; if you want to keep data off the durable filesystem, it is the right one.

The Mount Syntax, Read in Words

The short -v flag packs the mount type into punctuation, and reading it correctly matters. -v name:/path names a volume. -v /abs/host/path:/path is a bind mount — the leading slash on the source is the tell, because it makes the source a host path instead of a volume name. --tmpfs /path is a memory mount. The modern --mount type=volume|bind|tmpfs,... form spells the type out as a key, which is harder to get wrong and worth the extra characters once a container has more than one or two mounts.

docker run -d --name driftwood-db \
  -v driftwood-db-data:/var/lib/postgresql/data \
  -v /home/dev/driftwood/postgres.conf:/etc/postgresql/postgresql.conf:ro \
  --tmpfs /tmp \
  postgres:16

# the explicit --mount form says the same thing, unambiguously:
docker run -d --name driftwood-db \
  --mount type=volume,src=driftwood-db-data,dst=/var/lib/postgresql/data \
  --mount type=bind,src=/home/dev/driftwood/postgres.conf,dst=/etc/postgresql/postgresql.conf,ro \
  --mount type=tmpfs,dst=/tmp \
  postgres:16

Both invocations mount the same three things. The first leans on the leading-slash convention to distinguish the named volume from the bind mount; the second names each type outright. The :ro suffix and the ro key both make the bind mount read-only — the container can read the config but not overwrite the host's copy.

Picking the Right One

The decision collapses to a short rule. Durable application data goes on a named volume. Live source code in development goes on a bind mount. Secrets and ephemeral scratch go on a tmpfs. The writable layer (topic 33) is the right home for none of these — only for truly throwaway state you would never miss. When in doubt, default to a named volume and step outside it only for the specific reasons bind mounts and tmpfs exist.