2.3.3.4 Writable Container Layer
A focused guide to Writable Container Layer, connecting core concepts with practical Docker and container operations.
The writable container layer is the thin, container-specific filesystem layer created automatically when a container starts, sitting on top of all of its image's read-only layers, where every file the container creates or modifies is actually stored.
Created Fresh for Each Container
Every container gets its own writable layer the moment it is created, even if multiple containers are started from the exact same image — each one's writable layer is entirely independent of the others.
docker run -d --name app1 myapp:1.0
docker run -d --name app2 myapp:1.0
docker exec app1 sh -c "echo unique-to-app1 > /tmp/marker.txt"
docker exec app2 ls /tmp/marker.txt
The second command reports the file as not found, because the file written in app1 exists only in that specific container's own writable layer, with no effect on app2's separate writable layer or on the shared image layers underneath both.
The Writable Layer Disappears With the Container
Because the writable layer is tied to the container's own lifecycle, removing the container removes its writable layer and everything written to it — any data that needs to survive the container's removal must be stored in a volume or bind mount instead.
docker run --rm -d --name temp-app myapp:1.0
docker exec temp-app sh -c "echo data > /tmp/file.txt"
docker rm -f temp-app
The file written here is gone permanently once the container is removed, since it existed only in that container's now-deleted writable layer.
Inspecting What a Container Has Changed
The contents of a container's writable layer — every file it has added, modified, or deleted relative to its image — can be inspected directly, which is a precise way to understand exactly what state is unique to a running container.
docker diff myapp
Why the Writable Layer Matters
Understanding that a container's own changes live entirely in this separate, disposable layer is essential to correctly reasoning about data persistence: anything written only here is lost the moment the container is removed, which is precisely why stateful data is deliberately placed in volumes rather than relied upon to persist in this layer.