✦ For everyone, free.

Practical knowledge for real and everyday life

Home

8.4.1.3 Tmpfs Non Persistence

A focused guide to Tmpfs Non Persistence, connecting core concepts with practical Docker and container operations.

Tmpfs non-persistence is the defining characteristic distinguishing tmpfs from both volumes and bind mounts: it provides absolutely no data durability whatsoever, by design, making it fundamentally unsuitable for any data that needs to survive beyond the current container's specific running instance.

Comparing Persistence Across the Three Storage Options

Each of Docker's three main storage mechanisms offers a fundamentally different persistence guarantee, appropriate for different kinds of data.

docker run -d -v app-data:/data myapp:1.0
docker run -d -v /home/user/config:/config myapp:1.0
docker run -d --tmpfs /scratch myapp:1.0

A named volume persists independently of any specific container; a bind mount reflects whatever the host path currently contains, persisting as long as that host path does; a tmpfs mount persists only for the current container's running instance, with no durability at all.

Why Non-Persistence Is a Deliberate Design Choice, Not a Limitation

Tmpfs's complete lack of persistence isn't an oversight to be worked around — it's precisely the property that makes it appropriate for temporary, sensitive, or performance-critical data that should never persist in the first place.

docker run -d --tmpfs /app/secrets:size=10m myapp:1.0

For temporary decrypted secrets, this complete lack of persistence is exactly the desired behavior, not a shortcoming.

Recognizing When Non-Persistence Is the Wrong Choice

Using tmpfs for data that actually needs to survive — application state, uploaded files, database content — would be a clear misapplication of this storage option, since its core characteristic is fundamentally incompatible with that requirement.

docker run -d --tmpfs /var/lib/postgresql/data postgres:16

This would be a serious mistake, since a database's actual data clearly needs to persist, which tmpfs by design cannot provide.

Why Understanding Tmpfs Non-Persistence Matters

A clear understanding of tmpfs's complete and deliberate lack of persistence is essential for correctly choosing among Docker's storage options, ensuring data that genuinely needs to survive is never mistakenly routed through a mechanism specifically designed not to provide that durability.