11.2.3.2 Writable Temp Mounts

Writable temp mounts provide a specific, memory-backed writable location for a container otherwise running with a read-only root filesystem, accommodating an application's genuine need for temporary scratch space without compromising the broader filesystem's immutability.

Providing a Writable /tmp Alongside a Read-Only Root

A tmpfs mount specifically for /tmp accommodates the common need many applications have for temporary file storage.

docker run --read-only --tmpfs /tmp myapp:1.0

This provides a genuinely writable location at /tmp, while the rest of the container's filesystem remains read-only.

Why Tmpfs Is a Natural Fit for This Specific Need

Since temporary files are, by their nature, not expected to persist beyond the current run, a memory-backed tmpfs mount — itself inherently non-persistent — aligns naturally with what a temporary directory's contents are actually expected to be.

docker run --read-only --tmpfs /tmp --tmpfs /var/run myapp:1.0

Multiple tmpfs mounts can be provided for different specific paths an application might need writable access to.

Setting an Appropriate Size Limit for the Temp Mount

Limiting the tmpfs mount's size prevents an application's temporary file usage from growing unexpectedly large.

docker run --read-only --tmpfs /tmp:size=100m myapp:1.0

Verifying the Application Only Needs This Specific Writable Exception

Testing that the application functions correctly with only this specific writable path (and no other writable access) confirms the read-only configuration is correctly scoped to the application's actual needs.

docker run --rm --read-only --tmpfs /tmp myapp:1.0 npm test

Why Writable Temp Mounts Matter

Providing a deliberately scoped, memory-backed writable exception for temporary files allows a container to maintain an otherwise immutable, read-only filesystem while still accommodating the genuine, common need many applications have for some kind of temporary scratch space.