A tmpfs mount backs a path with memory instead of disk. The data is fast, disappears when the container stops, and never touches the writable layer, which makes it a good fit for scratch files and secrets that must not persist.
Before you start
You should be comfortable with volumes and mounts. This article covers tmpfs mounts and their limits.
Step-by-step walkthrough
Step 1: Mount tmpfs for ephemeral data
docker run --tmpfs /app/tmp:size=64m mounts a memory-backed filesystem at that path with a size cap. Because it is not on disk, the data is gone when the container exits and is not included in image layers or a commit.
Step 2: Use it for secrets at runtime
Mounting a secret file into tmpfs keeps it out of the writable layer and off disk, reducing the chance it is captured in an image snapshot. Combine with read-only settings so the container cannot write elsewhere.
Step 3: Always set a size limit
An unbounded tmpfs can consume all available memory, so set size and monitor. Since it draws from host memory, a runaway write to tmpfs can affect other processes and trigger the OOM killer, so the bound is not optional.
Worked scenario
The mount is memory-backed and size-capped.
docker run --rm \
--tmpfs /run/secrets:size=1m,mode=0700 \
--tmpfs /app/tmp:size=64m \
my-appWalk through the example
/run/secrets is a small, mode-restricted memory mount for secret files, and /app/tmp is a larger scratch space. Neither persists beyond the container, and both are capped so they cannot exhaust host memory. The secrets never land on disk.
Common mistake
Expecting tmpfs data to persist across restarts, or running without a size limit and letting a large temporary file consume memory. Another is using tmpfs for data the app must keep, which is lost on exit.
Verify the behavior
Write to the tmpfs mount, stop and restart the container, and confirm the data is gone. Fill it past the size limit and observe the write failure. Confirm the data does not appear in the writable layer or a saved image.
Interview exercise
Why is tmpfs a good place for a runtime secret?
Answer and reasoning
Because it lives in memory and disappears with the container, so the secret is never written to the writable layer or committed into an image, and it is not recoverable from disk afterward. That reduces the exposure surface compared with a file on the container’s filesystem. The trade is that it must fit in memory and is lost on exit.
Continue learning
Compare mounts in Volumes lifecycle and read-only filesystems in Read-only filesystems. Read the Docker tmpfs mounts documentation and try the Docker interview questions.