Docker and Compose
Docker volumes vs bind mounts in production
Choose named volumes, bind mounts or files built into the image based on ownership, portability and backup needs.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Build application code and fixed assets into the image, use Docker-managed volumes for data that must survive container replacement, and reserve links to host folders for deliberate needs such as configuration or imports. Every writable location needs a backup and ownership plan.
What this means in plain English
Both volumes and bind mounts let a container use files that are not part of its read-only image. A named volume is managed by Docker and works well for application-owned data. A bind mount points at an exact folder on the host, which gives control but connects the app tightly to that machine.
Production application code normally belongs inside the image so every release is known and repeatable. Use persistent storage only for data that must survive replacement, such as uploads or a database. Decide how each persistent path will be backed up and restored.
Where should each kind of data live?
| Image layer | Fixed application code and packaged assets |
|---|---|
| Named volume | Docker-managed application data that must survive |
| Host-folder link | An explicit host path that ties the container to that host |
A simple example
A photo app has its code inside the image, stores uploaded pictures in a named volume and reads one host-provided configuration file through a deliberate bind mount. Replacing the container changes the code version but leaves the pictures in place.
What to do, step by step
1. List every directory the application writes to.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on image layer: fixed application code and packaged assets. Write the result down so you can compare it later.
2. Classify it as disposable, reproducible or required data.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Mount only required data or intentional host folders.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Test backup and restore with matching permissions.
Finish by checking the result against host-folder link: an explicit host path that ties the container to that host. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Check file ownership during a restore test. A backup can contain every file and still fail if the new container user cannot read or write it.
Common mistakes and how to avoid them
Linking source-code folders into production.
This gives a misleading or unsafe result because it leaves out image layer. A better approach is to list every directory the application writes to, then check the result before making the change permanent.
Saving caches that should be disposable.
This gives a misleading or unsafe result because it leaves out named volume. A better approach is to classify it as disposable, reproducible or required data, then check the result before making the change permanent.
Backing up a volume while its data is changing.
This gives a misleading or unsafe result because it leaves out host-folder link. A better approach is to mount only required data or intentional host folders, then check the result before making the change permanent.
Words explained
- container
- A packaged, isolated way to run an application with the files and software it needs.
- image
- The read-only package used to create a container. A good production image can be rebuilt and traced back to a specific release.
- volume
- Storage that survives when a container is replaced. Databases and uploaded files often need a volume.
- bind mount
- A direct link from a folder on the host computer into a container. It is useful for some tasks but tightly connects the container to that host.
Quick checklist
- List every directory the application writes to.
- Classify it as disposable, reproducible or required data.
- Mount only required data or intentional host folders.
- Test backup and restore with matching permissions.
Common questions
What is the simple answer?
Build application code and fixed assets into the image, use Docker-managed volumes for data that must survive container replacement, and reserve links to host folders for deliberate needs such as configuration or imports. Every writable location needs a backup and ownership plan.
What should I check first?
Start with image layer: fixed application code and packaged assets. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
List every directory the application writes to. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Linking source-code folders into production. Avoiding that one mistake makes the rest of the comparison much more trustworthy.