8.4.1.2 Tmpfs Ephemeral Writes
A focused guide to Tmpfs Ephemeral Writes, connecting core concepts with practical Docker and container operations.
Tmpfs ephemeral writes describes how every write operation against a tmpfs mount exists only as long as the container itself is running, with no possibility of that data surviving a container stop, restart, or removal, since it was never written to persistent storage at any point.
Confirming the Ephemeral Nature Directly
Writing data to a tmpfs mount and then stopping the container demonstrates this ephemerality concretely.
docker run -d --name myapp --tmpfs /app/scratch myapp:1.0
docker exec myapp sh -c "echo 'temporary data' > /app/scratch/file.txt"
docker restart myapp
docker exec myapp cat /app/scratch/file.txt
This file no longer exists after the restart, since the tmpfs mount (and everything written to it) was discarded the moment the container stopped, even though the same container was subsequently restarted.
Why Even a Restart, Not Just Removal, Loses This Data
Unlike a container's writable layer, which persists through a stop and restart (only being deleted upon actual removal), a tmpfs mount's content does not survive even a simple restart, since the underlying memory backing it is released as soon as the container stops.
docker stop myapp
docker start myapp
docker exec myapp ls /app/scratch
This reflects an empty directory, confirming the tmpfs mount was recreated fresh upon restart, with no memory of its previous content.
Why This Behavior Is Appropriate for Its Intended Use Case
This ephemeral behavior is exactly what makes tmpfs well suited to genuinely temporary, scratch-space data — anything written there is understood from the outset to have no expectation of surviving beyond the current running instance.
docker run -d --tmpfs /tmp myapp:1.0
Why Understanding Tmpfs Ephemeral Writes Matters
Recognizing that tmpfs content doesn't survive even a simple restart — not just removal — is important for correctly using this storage option only for data that genuinely has no persistence requirements whatsoever, avoiding the mistake of relying on it for anything that needs to survive routine container lifecycle events.