In our last post, we fixed the plumbing. We made sure our containers could talk to each other. But there is a bigger problem: containers are ephemeral. This is a fancy way of saying they are temporary. If you delete a container, everything inside it â like your database records or uploaded images â disappears forever.
To solve this, we need to move the data out of the container and onto the host machine. We have three main ways to do this.
The Three Storage Options
- Bind Mounts: You map a specific path on your host machine (like
/home/asif/project) to a path inside the container. - Volumes: These are managed entirely by Docker. You do not need to worry about where they live on the host; Docker handles the directory structure for you.
- tmpfs Mounts: These live only in the host's memory. They are never written to the disk, making them perfect for sensitive data that should disappear when the container stops.
Bind Mounts vs. Volumes: Which One Should You Use?
This is where most people get confused. Here is a simple breakdown:
| Feature | Bind Mount | Docker Volume |
|---|---|---|
| Location | You choose the host path. | Docker-managed (/var/lib/docker/volumes). |
| Syntax | -v /host/path:/container/path |
-v volume-name:/container/path |
| Best Use Case | Development (Hot reloading). | Production (Data persistence). |
| Portability | Host-dependent. | Portable across systems. |
Practical Examples
For Development (Bind Mount)
If you are working on a Node.js or Laravel project, you want the container to see your code changes immediately.docker run -d -v $(pwd):/app my-app
For Your Database (Named Volume)
For something like PostgreSQL, you want Docker to manage the storage safely.docker run -d -v db-data:/var/lib/postgresql/data postgres
Pro-Tip for Home Lab Users
Since I use Portainer, I prefer using Named Volumes for my stacks. It makes it much easier to back up the data and move it between different Proxmox virtual machines without worrying about hardcoded file paths on the host.
Wrapping Up
Managing storage correctly is the difference between a stable app and a total data loss disaster. Always remember: Keep your application in the container, but keep your data in a volume.
In the next post, we are going to look at The Diet. I will show you how to use Multi-Stage builds to make your images smaller, faster, and more secure.
Happy Dockerizing!