Docker Volume
A Docker volume keeps data alive independently from the container lifecycle. By default, writes go into the container's writable layer, which disappears when the container is removed. Volumes move important data outside that disposable layer.
βΆArchitecture Diagram
π StructureDashed line animations indicate the flow direction of data or requests
Containers are meant to be replaceable, so important data cannot safely live only in the container's writable layer. That writable layer is just the temporary write space added on top of the image, and it disappears with the container. If databases, uploads, or shared working files stay there, the system loses durability and other containers cannot reliably reuse the same state.
As containers became more popular, teams also wanted to run stateful workloads in them. That created tension with the principle that containers should be easy to destroy and recreate. Docker introduced stronger storage abstractions so that application processes could remain disposable while their data remained durable.
Ordinary writes inside a container first land in the writable layer. When a volume or mount is attached, chosen paths are redirected onto storage outside that disposable layer, so the data survives even when the container is recreated. The key mechanism is not storing files inside the container for longer, but moving important paths onto storage that outlives container replacement. Named volumes are usually the operational default because Docker manages their location and they can be reattached later without depending on a host path. Bind mounts expose an exact host directory, which is ideal for live source editing in development but tightly couples the setup to the host filesystem. tmpfs keeps data only in memory, which suits sensitive temporary data but makes the contents vanish as soon as the container stops.
Named volumes and bind mounts both keep data outside the container, but they differ in who manages the path. Named volumes are more portable because Docker manages the storage location. Bind mounts are convenient for development because they expose an exact host path, but they tie you to host filesystem layout.
Named volumes are the safer default for persistent production data, especially with databases. Bind mounts are especially useful in development for live source-code editing. In operations, teams also need to think beyond mounting itself and plan backups and retention for the data that now lives outside the container image.