When would you attach a `tmpfs` mount to a Docker container instead of a volume or a bind mount, and what limitations does a tmpfs mount have?
answer
- RAM-backed, per-container, dies on stop
- secrets + scratch + writable holes under --read-only
- counts against the memory cgroup → set tmpfs-size
- Linux containers only, never shareable
- swap can still page it to disk
basics
~20 sUse tmpfs when data must never touch disk or persist: scratch files, caches, short-lived credentials, and the writable paths a --read-only container still needs. Limits: Linux containers only, not shareable, gone on stop, and it consumes the container's memory — always set a size.
solid answer
~60 sA tmpfs mount is a RAM-backed filesystem mounted into one container. Nothing lands in the image, the writable layer, or a host directory, and the content disappears when the container stops. Good fits: - **Secrets at runtime** — a token or key material written to `/run/secrets` stays out of any on-disk artifact and out of layer or volume backups. (Swarm mounts its secrets on tmpfs for exactly this reason.) - **Scratch and hot caches** — temp files, sockets, render or compile scratch, where copy-on-write into the writable layer would be slow and pointless. - **Making a hardened container work** — with `--read-only`, `/tmp` and `/run` still need to be writable; tmpfs punches those holes without introducing persistence. Limitations to name: Linux containers only; per-container, so you cannot share one between containers; no persistence at all, including across restart; and its pages count against the container's memory limit, so an unbounded tmpfs can OOM-kill the container. Set `tmpfs-size`, and remember that if the host has swap enabled, tmpfs pages can still be swapped to disk — it is not a guarantee of "never on disk".
code
bash · 12 lines# scratch space, capped at 64 MB
docker run --tmpfs /tmp:rw,size=64m,mode=1777 alpine sh
# explicit form
docker run --mount type=tmpfs,destination=/run,tmpfs-size=16m,tmpfs-mode=0755 myapp
# read-only root filesystem with just the writable paths the app needs
docker run --read-only \
--tmpfs /tmp:size=64m,mode=1777 \
--tmpfs /run:size=16m \
-v appdata:/var/lib/app \
myorg/api:1.4go deeper
Know that tmpfs lives in memory, is wiped when the container stops, and is for temporary files rather than data you want to keep.
Give the concrete use cases and the constraints — Linux-only, per-container, memory-charged — and show you would set a size.
Pair it with --read-only as a hardening pattern, reason about the memory limit interaction and OOM symptom, and raise the swap caveat when secrets are involved.
Treat it as part of a data-classification policy: decide which paths may persist at all, make ephemerality a platform guarantee rather than an application responsibility, and account for tmpfs in capacity planning since it competes with heap for the same limit.
## What a tmpfs mount is `tmpfs` is a Linux filesystem that lives in the page cache and is backed by memory rather than a block device. Docker can mount one into a container's mount namespace at any path. Because it is per-container and memory-backed, it has properties neither bind mounts nor volumes have: no host path exists, no volume object is created, `docker volume ls` shows nothing, and when the container stops the filesystem and everything in it are destroyed. Two ways to request it: - `--tmpfs /tmp` — short form, accepts a comma-separated option string after a colon (`--tmpfs /tmp:rw,size=64m,mode=1777`). - `--mount type=tmpfs,destination=/tmp,tmpfs-size=67108864,tmpfs-mode=1777` — explicit form, and the one Compose's long syntax mirrors with a `tmpfs:` block. ## When it is the right choice **Keeping sensitive material off disk.** Anything written into the container's writable layer sits on the host filesystem under Docker's data root and can survive in backups, snapshots or a committed image. A decrypted key, a short-lived cloud credential or a rendered config containing a password is much safer on tmpfs: it exists only while the process runs, and it is not something an operator can accidentally `docker cp` back out after the container is gone. This is why Swarm mounts secrets under `/run/secrets` on tmpfs. **Write-heavy scratch.** Writing into the container's own filesystem goes through the storage driver's copy-on-write machinery, which is comparatively slow and produces garbage that inflates the writable layer until the container is removed. Temp files, unix sockets, PID files, and per-request scratch belong on tmpfs, where writes are memory-speed. **Read-only containers.** A hardened container run with `--read-only` cannot write anywhere in its own filesystem. Almost every real image still needs a writable `/tmp` and `/run`. tmpfs mounts on exactly those paths give the process what it needs without creating persistent state and without giving up the read-only root. **Deliberate non-persistence.** Occasionally the requirement is that data must *not* survive — a per-session cache, an unpacked archive, decrypted content. tmpfs makes that a property of the platform rather than something the application must remember to clean up. ## Limitations you must be able to name - **Linux containers only.** tmpfs mounts are unavailable for Windows containers. On Docker Desktop for macOS/Windows they work, but the memory used is the Linux VM's memory, which is itself a bounded slice of the host. - **Not shareable.** A tmpfs mount belongs to one container. Two containers cannot see the same tmpfs, and it cannot be reattached to a replacement container — if you need sharing or handoff, you need a volume. - **Zero persistence.** Stop, restart, crash, or `docker rm` — all the same: content is gone. A restart is not a resume. - **It costs memory.** tmpfs pages are charged to the writing process's cgroup, so with `--memory` set, a container that fills its tmpfs is a container that hits its limit and gets OOM-killed by the kernel — often with a confusing symptom, because the application itself looks small in RSS. The default size when you specify none is half the host's memory, which is far too generous; always pass `tmpfs-size`. - **Not encrypted, and not swap-proof.** If the host has swap enabled, tmpfs pages can be paged out to swap, so "never touches disk" holds only on hosts with swap disabled or encrypted. Say this out loud when the use case is secrets — it is the detail that separates a memorised answer from a real one. - **`mode` matters.** `/tmp` is expected to be `1777` (world-writable with the sticky bit). A tmpfs mounted with default permissions can break applications that assume the usual `/tmp` semantics, and a too-open mode on a secrets directory is its own problem. ## Comparison in one breath Bind mount = host owns the data. Volume = Docker owns the data, it outlives the container. tmpfs = nobody owns the data after the process exits, and you pay for it in RAM. ## What a strong answer sounds like Name the three use cases (secrets, scratch, writable holes in a read-only container), then immediately volunteer the constraints — memory accounting and OOM risk, no sharing, no persistence, Linux-only, swap caveat. Mentioning `--read-only` plus tmpfs together shows you have actually hardened a container rather than read about it.
- A container with `--memory=256m` and a tmpfs on `/tmp` keeps getting OOM-killed even though the process's own heap is small. What is going on?tmpfs pages are charged to the container's memory cgroup, so files written to `/tmp` count towards the 256 MB limit just like heap does. Whatever fills `/tmp` — logs, uploads, temp extracts — is consuming the budget. Cap the mount with `tmpfs-size` so writes fail with ENOSPC instead of pushing the cgroup over its limit, and size the memory limit to cover heap plus the tmpfs cap.
- Does putting a secret on tmpfs guarantee it never reaches disk?Not by itself. tmpfs pages can be swapped out if the host has swap enabled, so the guarantee holds only on hosts with swap disabled or with encrypted swap. It also does nothing about the process itself writing the value somewhere else, or logging it. tmpfs removes the easy exposure — the writable layer, volumes, backups, `docker cp` — but it is a layer of defence, not a proof.
saying these in an interview costs you the question
- Believing tmpfs content survives a container restart, or is stored under `/var/lib/docker`.
- Not knowing tmpfs memory counts against the container's memory limit, so unbounded use gets it OOM-killed.
- Thinking two containers can share one tmpfs mount.
- Claiming tmpfs is encrypted or is a guarantee that data never touches disk, ignoring swap.
- Using tmpfs for data the app expects to find again after a restart.