When would you use a tmpfs mount instead of a regular volume, and why does it matter for handling sensitive data like decrypted secrets?

Use a tmpfs mount when data genuinely shouldn't persist beyond the container's lifetime and shouldn't ever touch the host's actual disk — tmpfs is backed by memory, not disk storage, so its contents disappear when the container stops and are never written to a physical disk where they could be recovered later. For a decrypted secret written briefly during startup, that's exactly the property you want: no disk-persistence, no leftover file for someone with host or volume access to later find.

Volumes and bind mounts are both fundamentally about persisting data on disk — named volumes in Docker-managed storage, bind mounts on a specific host path — and by design, that data survives independently of the container's lifecycle, which is exactly the point for a database's data directory or application logs. A tmpfs mount inverts that: it's explicitly for data that should exist only transiently, in memory, for exactly the container's runtime.

Regular volumes and bind mounts persist to disk, which is a liability for transient secrets: even a file that's deleted immediately after use can leave recoverable traces on physical disk (depending on the filesystem and storage layer), and if the volume or host path is ever backed up, snapshotted, or inspected, a decrypted secret that briefly touched disk-backed storage could be exposed through that channel — a risk that doesn't apply to something that was only ever in memory.

tmpfs mounts avoid disk entirely, bounding the exposure to the container's actual runtime: since a tmpfs mount is backed by memory, its contents vanish when the container stops (or the mount is unmounted), with no on-disk artifact left over to accidentally back up, snapshot, or forget to clean up.

tmpfs is also naturally size-bounded, which is worth being deliberate about — you can (and generally should) cap a tmpfs mount's size explicitly, since unlike a disk-backed volume, its usage consumes the host's actual memory, and an unbounded or very large tmpfs mount can become a memory-pressure problem on the host.

This doesn't replace proper secrets management: a tmpfs mount is about where a decrypted secret briefly lives during processing, not a substitute for fetching that secret from a real secrets manager in the first place, or for controlling which processes/users can read the mount while the container is running (a tmpfs mount is still readable by anything with access inside the container's namespace).

• Use tmpfs for data that should exist only transiently, in memory, for the container's runtime — regular volumes and bind mounts are for data meant to persist to disk.
• tmpfs avoids leaving a disk-backed artifact of a transient secret, which matters for backup/snapshot exposure risk that doesn't apply to memory-only storage.
• Explicitly bound a tmpfs mount's size, since it consumes host memory rather than disk space.
• tmpfs solves "where does this transient data briefly live," not the broader secrets-management problem of how the secret is fetched and controlled in the first place.

• Docker Docs: tmpfs mounts