6.1.1.3 Creation Filesystem Layer
A focused guide to Creation Filesystem Layer, connecting core concepts with practical Docker and container operations.
The creation filesystem layer is the new, empty, writable layer Docker allocates for a container at the moment it is created, sitting on top of the selected image's read-only layers and capturing any filesystem changes that occur during the container's subsequent running life.
How This Layer Relates to the Underlying Image
The image's own layers remain entirely unchanged and read-only; the container's writable layer is the only place any new or modified file content during the container's life actually gets stored.
docker run -d --name myapp myapp:1.0
docker exec myapp touch /tmp/new-file.txt
docker diff myapp
The docker diff command reveals exactly what has changed in this container's writable layer relative to the underlying image, confirming the layer's role in capturing runtime changes.
Why Multiple Containers From the Same Image Don't Interfere
Because each container gets its own independent writable layer, multiple containers created from the identical image can each make their own filesystem changes without those changes affecting each other or the shared, underlying image layers.
docker run -d --name container-a myapp:1.0
docker run -d --name container-b myapp:1.0
docker exec container-a touch /tmp/a-only.txt
docker exec container-b ls /tmp/a-only.txt
The second command fails, since container-b's own writable layer has no knowledge of changes made within container-a's separate writable layer.
What Happens to This Layer When a Container Is Removed
A container's writable layer is deleted entirely when the container itself is removed, meaning any data stored only there (and not in a separately managed volume) is permanently lost at that point.
docker rm myapp
Why Understanding the Creation Filesystem Layer Matters
Recognizing that a container's writable layer is created fresh, empty, and tied specifically to that container's own lifecycle clarifies both why containers from the same image can run independently without interfering with each other, and why any data needing to survive a container's removal must be stored in a volume rather than relying on this layer alone.