One of the first surprises new Docker users encounter is that data disappears when a container is removed.
Imagine deploying a web application or a database inside a Docker container. Everything works perfectly until the container crashes or you redeploy your application. Suddenly, all your uploaded files, logs, or database records are gone.
Why?
Because containers are ephemeral by design. They are designed to be created, destroyed, and recreated quickly. Unless data is stored outside the container, it disappears together with the container.
In this article, you’ll learn the three common ways Docker handles storage and when each one should be used.
Understanding Docker Storage
There are three common ways to work with data in Docker:
Storage Type Persists After Container Removal? Managed By Container Writable Layer ❌ No Docker Bind Mount ✅ Yes Host Machine Docker Volume ✅ Yes DockerLet’s explore each one with practical examples.
1. Container Writable Layer (Ephemeral Storage)
By default, every Docker container has a writable layer where files can be created or modified while the container is running.
Think of it like a teacher writing notes on a whiteboard during a class. Once the class ends and the board is cleaned, everything written on it is gone.
Similarly, when a container is removed, everything stored inside its writable layer is lost.
Step 1: Start a container
docker run -it --name notes alpine sh
Enter fullscreen mode Exit fullscreen mode
Inside the container:
echo "My first note" > notes.txt
cat notes.txt
Enter fullscreen mode Exit fullscreen mode
Exit the container:
exit
Enter fullscreen mode Exit fullscreen mode
Remove it:
docker rm notes
Enter fullscreen mode Exit fullscreen mode
Create a new container:
docker run -it --name notes alpine sh
Enter fullscreen mode Exit fullscreen mode
Try reading the file again:
cat notes.txt
Enter fullscreen mode Exit fullscreen mode
Observation
The file no longer exists because it was stored only inside the container.
When is this useful?
- Temporary files
- Cache
- Generated reports
- Session data
2. Bind Mount
A bind mount connects a folder on your host machine directly into a container.
Think of it as giving someone access to a folder on your computer. They can read from it and write to it, and you can immediately see the changes from your host machine.
Unlike the container’s writable layer, the data remains on your computer even after the container is deleted.
Create a folder
mkdir docker-notes
Enter fullscreen mode Exit fullscreen mode
Run the container:
docker run -it \
--name bind-demo \
-v $(pwd)/docker-notes:/app/data \
alpine sh
Enter fullscreen mode Exit fullscreen mode
Inside the container:
echo "Bind Mount Note" > /app/data/notes.txt
Enter fullscreen mode Exit fullscreen mode
Exit:
exit
Enter fullscreen mode Exit fullscreen mode
Verify the file on your host machine:
cat docker-notes/notes.txt
Enter fullscreen mode Exit fullscreen mode
Remove the container:
docker rm bind-demo
Enter fullscreen mode Exit fullscreen mode
Check the file again:
cat docker-notes/notes.txt
Enter fullscreen mode Exit fullscreen mode
Observation
The file is still available because it is stored on the host machine, not inside the container.
Common Use Cases
- Local development
- Editing source code
- Sharing files between host and container
3. Docker Volumes
Docker volumes are the recommended way to persist data in production.
Unlike bind mounts, Docker manages the storage location for you.
Think of a Docker volume as a portable external drive that Docker can attach to any container whenever it starts.
This is the preferred method for storing application and database data.
Create a volume
docker volume create notes-volume
Enter fullscreen mode Exit fullscreen mode
Run a container using the volume:
docker run -it \
--name volume-demo \
-v notes-volume:/app/data \
alpine sh
Enter fullscreen mode Exit fullscreen mode
The option
-v notes-volume:/app/data
Enter fullscreen mode Exit fullscreen mode
attaches the Docker volume to the container.
Inside the container:
echo "Volume Note" > /app/data/notes.txt
Enter fullscreen mode Exit fullscreen mode
Exit:
exit
Enter fullscreen mode Exit fullscreen mode
Remove the container:
docker rm volume-demo
Enter fullscreen mode Exit fullscreen mode
Start another container using the same volume:
docker run -it \
--name volume-demo2 \
-v notes-volume:/app/data \
alpine sh
Enter fullscreen mode Exit fullscreen mode
Check the file:
cat /app/data/notes.txt
Enter fullscreen mode Exit fullscreen mode
Observation
The file still exists because it was stored inside the Docker volume instead of the container.
Common Use Cases
- Databases
- Production applications
- User uploads
- Application logs
Comparison
Feature Writable Layer Bind Mount Docker Volume Persists after container removal ❌ ✅ ✅ Stored on host ❌ ✅ ✅ Managed by Docker ✅ ❌ ✅ Best for Production ❌ ⚠️ Sometimes ✅ Best for Development ❌ ✅ ✅Which One Should You Use?
Choose the storage option that matches your use case:
- Container Writable Layer → Temporary data that doesn’t need to survive.
- Bind Mount → Local development where you want to edit files directly on your machine.
- Docker Volume → Databases and production workloads where persistent storage is essential.
Final Thoughts
Understanding Docker storage is one of the most important skills for anyone learning containers.
If you don’t store your data correctly, removing a container can also remove everything your application has generated.
As a general rule:
- Use the container writable layer for temporary data.
- Use bind mounts during development.
- Use Docker volumes in production.
Following these best practices will help you build containerized applications that are reliable, portable, and easier to maintain.
Resources
You can find the complete examples used in this article in my GitHub repository:
👉 https://github.com/highbee2810/Docker_storage_tutorials
If this article helped you, consider leaving a ❤️ and following me for more practical Docker, DevOps, and Cloud tutorials.
답글 남기기