Docker ocupa espacio en mi Mac
Docker Desktop guarda todo en un archivo. Crece con cada compilación, y borrar imágenes no lo hace más pequeño. Aquí está por qué, y qué recupera el espacio de verdad.
Prueba gratuita de 14 días, sin tarjeta. Después 15 $ una vez para 3 ordenadores, macOS y Linux.

Dónde está el espacio
En macOS, Docker Desktop ejecuta una máquina virtual Linux, y todo el sistema de archivos de esa máquina es un único archivo disperso en tu Mac:
~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
Comprueba su tamaño real en disco, no el lógico, que siempre es el máximo que le permitiste a Docker:
du -h -d0 ~/Library/Containers/com.docker.docker/Data/vms/0/data/
Por qué borrar imágenes no lo reduce
Quitar una imagen libera bloques dentro del sistema de archivos de la máquina virtual, pero el archivo de tu Mac conserva su tamaño: ya se lo ha quedado a macOS. Las versiones recientes de Docker Desktop emiten TRIM desde dentro de la máquina, lo que permite a macOS recuperar los bloques liberados, pero ocurre según el calendario de Docker y no en el momento en que haces el prune. Hasta entonces, docker system df informa de gigabytes liberados mientras el Finder no muestra cambio alguno.
Recuperar el espacio
En orden: primero lo menos destructivo.
1. Ver qué cree Docker que está usando
Empieza siempre aquí. Separa imágenes, contenedores, volúmenes y caché de compilación, y te dice cuánto de cada uno es recuperable.
docker system df -v
2. Vaciar la caché de compilación
En una máquina que construye imágenes con regularidad, suele ser el mayor elemento y el más seguro de quitar: solo hace más lenta la siguiente compilación.
docker builder prune -a
3. Limpiar lo que de verdad no se usa
Contenedores parados, imágenes huérfanas y redes sin usar:
docker system prune
Añade -a para quitar además cada imagen que no use un contenedor en marcha, lo que significa volver a bajarlas más tarde. Añade lo siguiente --volumes solo si estás seguro: en los volúmenes es donde las bases de datos guardan sus datos, y ese es el único comando de esta página que destruye algo que no puedes volver a descargar.
4. Lista los volúmenes antes de tocarlos
Mira qué desaparecería de verdad:
docker volume ls
docker volume ls -f dangling=true
Docker rara vez es lo único
Puedes ejecutar todos los comandos de esta página, y en el mismo Mac DerivedData de Xcode y unos cuantos pesos de modelos olvidados suelen ser igual de grandes. Bytesweep mide el tamaño real de Docker en disco junto a todos ellos en una pasada de diez segundos, para que arregles el disco una vez en lugar de perseguirlo herramienta a herramienta.
5. Hacer que macOS recupere el archivo
Después del prune, Docker Desktop tiene una forma prevista de devolver los bloques liberados: Ajustes → Recursos → Avanzado → Uso de disco, o salir y volver a abrir Docker Desktop, lo que dispara TRIM al arrancar. Dale un minuto y vuelve a comprobar el tamaño del archivo antes de decidir que no ha funcionado.
6. Bajar el límite de disco
En Ajustes → Recursos, el límite de disco virtual es cuánto se le permite crecer a Docker.raw. Bajarlo no libera nada por sí solo, pero pone techo al problema. Haberlo subido «por si acaso» es la razón por la que el archivo llegó a 64 GB.
7. El último recurso
Ajustes → Solución de problemas → Clean / Purge data reinicia por completo el disco de la máquina virtual y devuelve el archivo casi a cero. Borra todas las imágenes, contenedores y volúmenes que tengas. Úsalo cuando nada más haya funcionado y sepas qué hay en tus volúmenes.
No borres Docker.raw en el Finder. No es un archivo de caché: son los datos de toda la instalación de Docker, y quitarlo mientras Docker está en marcha puede dejar la máquina virtual en un estado que igualmente exija un reinicio.
También conviene mirar
Docker rara vez está solo
En el Mac donde Docker llegó a 50 GB, DerivedData de Xcode y los modelos de IA locales suelen ir justo detrás. Si vas a recuperar espacio, vale la pena medir todo el disco una vez en lugar de arreglar una cosa cada vez. La lista completa →
En Linux no hay archivo de imagen
En Linux, Docker escribe directamente en /var/lib/docker, así que un prune libera el espacio al momento y nada del problema de TRIM anterior se aplica. Limpieza de disco en Linux →
Ver Docker junto a todo lo demás
Bytesweep mide el tamaño real de Docker en disco, lo muestra junto a Xcode, los simuladores, node_modules y los pesos de modelos, y marca lo que se puede quitar sin riesgo, sin tocar tus volúmenes.
Preguntas
¿Es seguro borrar Docker.raw?
No desde el Finder, y no mientras Docker está en marcha. Ese único archivo es cada imagen, contenedor y volumen que tienes. Si de verdad quieres empezar de cero, usa Solución de problemas → Clean / Purge data en Docker Desktop, que hace lo mismo de una forma que Docker conoce.
¿Por qué docker system prune dice que liberó 20 GB si no ha cambiado nada?
Porque liberó 20 GB dentro del sistema de archivos de la máquina virtual, no en tu Mac. El archivo conserva su tamaño hasta que se ejecuta TRIM y macOS recupera los bloques. Salir y volver a abrir Docker Desktop suele dispararlo.
¿docker system prune borra mis bases de datos?
Solo si añades --volumes. Sin esa opción deja los volúmenes en paz. Con ella, desaparece cualquier volumen no conectado a un contenedor, y el volumen de una base de datos parada cuenta como no conectado.
¿Cómo de grande debería ser Docker.raw?
No hay una respuesta correcta, pero en una máquina con unos pocos proyectos activos, de 15 a 25 GB es normal, y 60 GB significa que la caché de compilación no se ha vaciado nunca. Comprueba con docker system df -v antes de dar por hecho que son las imágenes.