tmpfs Mounts
LEVEL 0
The Problem
You have data that:
- Doesn’t need to persist (temporary caches, session data)
- Needs to be very fast (high-performance temporary storage)
- Should never be written to disk (sensitive data that shouldn’t leave RAM)
Writing to disk is slow compared to RAM. And for security-sensitive data, you don’t want it persisted anywhere.
Docker volumes and bind mounts both write to disk. Is there a way to store data purely in memory?
LEVEL 1
The Concept — The Whiteboard
The Concept
Imagine you’re in a meeting room with:
A filing cabinet (Docker volume): Permanent storage. Survives the meeting. Organized and secure.
A desk with drawers (Bind mount): Semi-permanent. Files stay as long as you’re using the desk.
A whiteboard (tmpfs mount): Temporary. You write notes during the meeting. When the meeting ends, someone erases the whiteboard. Fast to write, instant to erase, but nothing persists.
tmpfs mounts are whiteboards. Data exists only in RAM. When the container stops, the data vanishes.
LEVEL 2
The Mechanics — How tmpfs Works
The Mechanics
tmpfs (temporary filesystem) stores data in the host’s memory, not on disk.
Creating a tmpfs mount:
docker run -d \
--name webapp \
--tmpfs /app/cache:rw,size=100m,mode=1777 \
myapp
Explanation:
--tmpfs /app/cache: Create tmpfs mount at/app/cacherw: Read-write (default)size=100m: Limit to 100 MB (prevents runaway memory usage)mode=1777: File permissions (sticky bit, all users can write)
Or using —mount (recommended):
docker run -d \
--name webapp \
--mount type=tmpfs,target=/app/cache,tmpfs-size=104857600,tmpfs-mode=1777 \
myapp
LEVEL 3
Use Cases for tmpfs Mounts
1. Temporary caches
docker run -d \
--tmpfs /app/cache \
my-web-app
Application stores rendered page fragments in /app/cache. Cache is fast (in RAM) but doesn’t need to persist.
2. Sensitive data processing
docker run -d \
--tmpfs /tmp/secrets:noexec,nosuid \
security-tool
Processing decrypted keys or tokens. Data never touches disk, reducing attack surface.
3. Build artifacts
docker run \
--tmpfs /build \
--mount type=bind,source=$(pwd),target=/src,readonly \
--mount type=bind,source=$(pwd)/dist,target=/out \
build-image
Compilation happens in /build (tmpfs, fast). Final artifacts written to /out (bind mount, persisted).
4. High-performance temp storage
docker run -d \
--tmpfs /app/tmp:size=2g \
data-processing-app
ETL jobs that create large temporary files. tmpfs is much faster than disk I/O.
LEVEL 4
tmpfs Limitations
RAM consumption:
tmpfs uses host RAM. If a container writes 1GB to tmpfs, that’s 1GB of RAM consumed.
Solution: Always set size limits:
--tmpfs /app/cache:size=500m
Data loss on container stop:
When the container stops, tmpfs data is gone. This is by design, but be aware.
Not available on Windows containers:
tmpfs is a Linux feature. Windows containers can’t use it.
No sharing between containers:
Each container gets its own tmpfs. Containers can’t share tmpfs mounts.
LEVEL 5
tmpfs vs. Volume vs. Bind Mount
Storage location:
- Volume:
/var/lib/docker/volumes/(disk) - Bind mount: Anywhere on host filesystem (disk)
- tmpfs: Host RAM (memory)
Persistence:
- Volume: Permanent (survives container removal)
- Bind mount: Permanent (host file persists)
- tmpfs: Temporary (lost when container stops)
Performance:
- Volume: Disk I/O speed
- Bind mount: Disk I/O speed (slower on Mac/Windows)
- tmpfs: RAM speed (very fast)
Size:
- Volume: Limited by disk space
- Bind mount: Limited by disk space
- tmpfs: Limited by RAM (and size parameter)
Use in production:
- Volume: Yes (databases, persistent data)
- Bind mount: Rarely (config files, maybe)
- tmpfs: Yes (caches, temporary data)