Volúmenes: nombrados, bind mounts y tmpfs

Por qué hace falta esto

El filesystem de un contenedor vive en su capa de escritura (ver Arquitectura) — se pierde para siempre si el contenedor se borra. Para datos que necesitan sobrevivir (una base de datos, uploads de usuarios), Docker ofrece tres mecanismos de almacenamiento por fuera de esa capa.

Las tres opciones

Volumen nombrado          Bind mount                tmpfs
┌────────────┐            ┌────────────┐            ┌────────────┐
│ Contenedor │            │ Contenedor │            │ Contenedor │
└─────┬──────┘            └─────┬──────┘            └─────┬──────┘
      │                         │                          │
┌─────▼──────┐            ┌─────▼──────┐            ┌─────▼──────┐
│ Área que    │            │ Carpeta    │            │ Memoria RAM │
│ Docker      │            │ EXACTA del │            │ (no persiste│
│ administra  │            │ host que   │            │ ni en disco)│
└────────────┘            │ eliges tú │            └────────────┘
                            └────────────┘

	Volumen nombrado	Bind mount	tmpfs
Dónde vive	Área gestionada por Docker (/var/lib/docker/volumes/...)	Carpeta específica del host, la que elijas	RAM
Persiste tras docker rm	Sí	Sí (es una carpeta real del host)	No
Uso típico	Datos de la aplicación (base de datos)	Código fuente en desarrollo (recarga en caliente)	Datos temporales sensibles o caché
Sintaxis	-v mis-datos:/data	-v /ruta/host:/data	--tmpfs /data

Volumen nombrado: el default para datos de app

docker run -v mis-datos:/var/lib/postgresql/data postgres:16

Docker crea (si no existe) un volumen llamado mis-datos y lo monta en /var/lib/postgresql/data dentro del contenedor. Es la opción recomendada para datos que la app gestiona (bases de datos, uploads) — Docker se encarga de dónde vive físicamente, y sobrevive a docker rm del contenedor.

docker volume ls              # listar volúmenes
docker volume inspect mis-datos
docker volume rm mis-datos    # borrar (falla si algún contenedor lo usa)

Bind mount: para desarrollo con hot reload

docker run -v $(pwd):/app mi-app-dev

Monta la carpeta exacta del proyecto (en el host) dentro del contenedor — cualquier cambio de archivo en el editor se refleja instantáneamente adentro, sin reconstruir la imagen. El caso de uso típico es desarrollo local: código fuente montado, para que un nodemon/vite/similar corriendo dentro del contenedor detecte los cambios igual que si corriera nativo.

# Windows/Mac: %cd% o $(pwd) según la shell
docker run -v ${PWD}:/app -p 3000:3000 mi-app-dev

tmpfs: memoria, no disco

docker run --tmpfs /app/cache mi-app

Los datos viven solo en RAM, nunca tocan disco, y se pierden al detener el contenedor — para cache temporal o datos sensibles que no deberían persistir en ningún lado.

Consideraciones

• Con un volumen nombrado, si el contenedor se borra pero el volumen no, un contenedor nuevo montado sobre ese mismo volumen ve los mismos datos — ver Persistencia de datos para el detalle completo de este flujo.
• Los bind mounts son cómodos en desarrollo, pero suelen evitarse en producción porque dependen de una carpeta específica del host que puede no existir de la misma forma en otro servidor.