The Ephemeral Problem — Why Containers Forget

~10 min · data, concepts

Level 0Container Curious

0 XP0/36 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

Containers don't keep what you write

The writable layer Docker adds on top of an image is throwaway. docker rm deletes it. docker run a fresh container from the same image, and that fresh container starts from the image's filesystem — your earlier writes are gone.

This is a feature

Ephemerality is what makes containers easy to scale, replace, and patch. The cost: anything that must persist needs to live outside the container's writable layer. That's what volumes are for.

Code

Reproduce the loss in 30 seconds·bash

docker run -d --name pg1 -e POSTGRES_PASSWORD=secret postgres:16

# Create a database
docker exec -it pg1 psql -U postgres -c "CREATE DATABASE app;"
docker exec -it pg1 psql -U postgres -d app -c "CREATE TABLE t(x int); INSERT INTO t VALUES(42);"

# Throw it away
docker rm -f pg1

# Fresh container, same image, same name
docker run -d --name pg1 -e POSTGRES_PASSWORD=secret postgres:16
docker exec -it pg1 psql -U postgres -d app -c "SELECT * FROM t;"
# ERROR: database "app" does not exist
# Data was in the writable layer. Layer was deleted. Data is gone.

External links

Docker — Manage data in containers

Exercise

Reproduce the data loss above with any container of your choice (Postgres, Redis, MySQL). Then re-run with a named volume mounted on the data directory and verify the data survives docker rm -f + recreate. Capture both runs.

Progress

Progress is local-only — sign in to sync across devices.

← 🛠️ Building Images — DockerfileProduction-Ready Dockerfile — non-root, healthcheck, labels Next →Three Storage Types — Volumes, Bind Mounts, tmpfs

Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)

No comments yet — be the first.