🚀 Intro
In most of my deployments I do, I always (at least when it makes sense) implement Docker volumes as a part of docker run command.
The reason for that is the simple fact that — docker doesn’t keep your data by default. Yes, Docker containers are ephemeral — meaning they are short-lived or temporary.
What does it mean for you and your application?
Well… Once a container stops, crashes, or gets recreated during an update… everything inside the container’s filesystem disappears. Yes, including your application data…
And that’s perfectly fine for stateless services — but the moment you work with anything that stores data (databases, uploads, logs, configuration files), you must make that data persistent.
That moment when you suddenly realize you could have lost all your MySQL data… just because you forgot to set up persistent storage…
is not something you want to experience. Trust me. I’ve been there. Almost, lost 3 years MySQL data base packed with troubleshooting procedures, critical files and critical files for our infrastructure.
Also, in the article, at the bottom, you will find a cheat sheet with the Docker volumes-related commands :)
So today, we’re going through everything you need to know about Docker volumes,
This article is part of longer series on docker engineering, but I regularly write about all DevOps-related technologies.
You can read about Ansible, Jenkins or Kubernetes project below:
1️⃣ Let’s start with the basics
Ok first things first — most of all the commands and examples are in the official docker documentation — i will leave the link in the description/.
Now, what we need to know is the fact that docker volume is a way that allows you to store container data outside the container.
In case your container will be:
deleted
recreated
updated
or you VM machine is rebooted
or simply you want to make an upgrade to the newer version with updated Docker image
…your data still remains safe
So, where a normal container loses everything inside its filesystem once it’s gone, a volume you attached to your containers lives on — independently from the container lifecycle.
And that’s why every production stateful deployment MUST use volumes as long as you want to keep you data
Volumes are Docker-managed storage locations designed to keep your container data safe and persistent. You can create one manually with docker volume create, or Docker will automatically generate a volume whenever a container or service needs one.
Behind the scenes, each volume lives inside a specific directory on the Docker host. When you attach that volume to a container, Docker simply mounts that directory inside the container’s files.
2️⃣ When to use docker volumes?
Press enter or click to view image in full size
Scenario 1: Your application stores persistent data
Use a Docker volume whenever your application creates data that must survive container restarts, rebuilds, or scaling operations.
Examples:
Databases (PostgreSQL, MySQL, MongoDB, etc.)
Database data must be persistent. If the container is removed without a volume, all tables and records are lost.User uploads (images, documents, media files)
Any user-generated content needs to be stored outside the container’s ephemeral filesystem.Configuration files generated at runtime
Apps sometimes write config files, API keys, or runtime state. Without a volume, these will be lost on redeploy.Application logs that need to be preserved
Logs stored inside the container disappear when the container is replaced. Volumes allow you to archive or analyze logs later.
Scenario 2: Multiple containers need to share the same data
Volumes make it safe and simple for multiple containers to read/write the same files.
Examples:
A web app and a worker process sharing uploaded files
Two containers sharing a configuration directory
A database cluster with shared storage requirements
Bind mounts can work, but volumes offer controlled permissions, less host-dependency, and better performance.
Scenario 3: You need a storage method that behaves consistently across environments
Docker volumes work the same, regardless of the platform — whether it is:
Linux
Windows
macOS (via Docker Desktop)
This makes them ideal when:
Deploying the same container stack on different OS environments
Running CI/CD pipelines across mixed systems
Using docker-compose or Kubernetes where portability is key
Imagine — Deploying the same Postgres container on both Windows and Linux servers without worrying about host filesystem differences.
Scenario 4: You want better performance, isolation, and security than bind mounts
Volumes are handled directly by Docker’s storage drivers and offer:
Better I/O performance (especially on macOS/Windows)
Isolation from the host filesystem
Ability to manage them with Docker commands (docker volume ls, prune, etc.)
Support for remote volume drivers (NFS, EFS, SSHFS, etc.)
Scenario 5: You use orchestrators like Docker Compose, Swarm, or Kubernetes
Volumes are the standard persistent storage mechanism in orchestrators.
They allow:
Seamless scaling
Reliable data persistence over container recreation
Declarative config in YAML
3️⃣ Most common mistakes
Let’s talk about the traps many DevOps beginners fall into — and I’ve fallen into some of these myself.
Press enter or click to view image in full size
❌ Mistake #1: Relying on Container Filesystem for Databases
Running MySQL, PostgreSQL, MongoDB, Redis, or anything stateful without a volume. Your data will disappear the second you recreate the container. Don’t do it. Rely on volumes.
❌ Mistake #2: Deleting Volumes When Removing Containers
Running:docker rm -f $(docker ps -aq) && docker volume prune
…just because it “fixes things” is NEVER a good idea. This is the fastest way to wipe production databases. Always, think twice before you remove any volume, double check with you containers whether the volume is not currently utilized by any container.
❌ Mistake #3 : Confusing Volume Names
Trust me:
You do NOT want to troubleshoot a production outage because “wait… which volume was Postgres using again?”
Always use descriptive names
❌ Mistake #4: Not backing up volumes
Now, this is the biggest sin in my opinion. Volumes are great for persisting data, but if you don’t have a backup strategy, one wrong command or system crash can wipe everything. I recommend to set up some smart DevOps system that is regularly backing up your volumes.
4️⃣ Docker Volume Cheat-sheet
As promised, I made a quick cheat sheet you can use for your daily work with Docker containers and volumes.
We hope you liked it,
BecomeDevops
