Uso de disco de Docker en Mac: lo que realmente consume espacio

Docker en Mac rara vez se ve enorme de golpe. Crece en capas.

Al principio es una imagen, un proyecto, un volumen de base de datos, un contenedor detenido, una caché de build que planeas limpiar después. Luego la máquina se aprieta, Docker Desktop empieza a parecer sospechoso, y la conclusión habitual es vaga pero emocionalmente satisfactoria: “Docker se está comiendo mi disco.”

Esa conclusión es correcta en dirección, pero demasiado imprecisa para ser útil. El verdadero problema normalmente no es “Docker en general.” Es la acumulación entre imágenes, capas, caché de build, contenedores detenidos, volúmenes y datos de runtime que nadie revisó como un sistema.

Respuesta rápida

Por qué Docker crece silenciosamente tanto en Mac

Docker está diseñado para mantener estado útil hasta que tu explícitamente le digas lo contrario. La propia documentación de Docker describe la limpieza como conservadora: las imágenes, contenedores, volúmenes y redes no utilizados generalmente no se eliminan a menos que le pidas a Docker que lo haga.

Eso es conveniente para flujos de desarrollador y exactamente por lo que el uso de disco se acumula.

En Mac, la imagen se siente aun menos obvia porque Docker Desktop almacena contenedores e imágenes Linux en un solo archivo grande de imagen de disco. Eso significa que el host puede mostrar una huella grande de Docker mientras las causas reales están enterradas dentro de múltiples capas de datos de runtime.

El patrón de crecimiento suele ser alguna combinación de:

• imágenes descargadas y reconstruidas a través de varios proyectos;
• capas compartidas reutilizadas entre tags y versiones;
• contenedores detenidos que aun mantienen capas de escritura;
• volúmenes que contienen bases de datos, archivos subidos o estado local de servicios;
• caché de build que mantiene los builds rápidos hasta que se vuelve costosa;
• objetos colgantes dejados atrás después de reconstrucciones y retags.

El resultado es una huella que se expande silenciosamente porque cada adición individual parece normal.

¿Dónde guarda Docker sus datos en Mac?

En Mac, Docker no dispersa sus archivos por el disco como haría una app nativa. Docker Desktop ejecuta Linux dentro de una máquina virtual y guarda casi todo (imágenes, contenedores y volúmenes) dentro de un único archivo grande de imagen de disco.

Por defecto, ese archivo vive más o menos aquí:

~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

La ruta exacta puede cambiar entre versiones de Docker Desktop, pero la idea es constante: un archivo gestionado contiene toda la huella del lado Linux. Por eso un solo Docker.raw aparece en Finder como decenas de gigabytes aunque buena parte de ese espacio sea recuperable o sea solo el tamaño máximo que la imagen de disco puede alcanzar.

De ese diseño se derivan dos consecuencias:

• El tamaño en Finder engaña. Las herramientas del host suelen informar del tamaño máximo de la imagen de disco, no del espacio que Docker está usando dentro.
• No toques Docker.raw directamente. La propia documentación de Docker para Mac advierte de no mover ni borrar la imagen de disco en Finder, porque Docker Desktop puede perderle la pista. El espacio se recupera a través de Docker, no del sistema de archivos.

Qué realmente consume espacio de Docker en Mac

Si quieres un plan de limpieza útil, separa la huella de Docker en categorías en vez de tratarla como una caja negra gigante.

Por eso un flujo genérico de “carpeta más grande” es débil para Docker. El mismo tamaño total puede significar decisiones de limpieza muy diferentes dependiendo de si el espacio es mayormente caché de build o mayormente datos reales de volúmenes.

Imágenes de Docker y capas compartidas

Las imágenes suelen ser lo primero en lo que piensan los desarrolladores, pero la historia más profunda son las capas. Una máquina con varios runtimes de lenguaje, builds locales tipo CI y múltiples microservicios puede acumular muchas capas compartidas y únicas rápidamente.

Por eso el uso de disco no siempre se mapea limpiamente a la lista de imágenes que recuerdas haber descargado.

Caché de build de Docker

La caché de build es una de las causas ocultas más comunes en máquinas de desarrollo activas. Existe para hacer futuros builds más rápidos, lo que significa que se queda hasta que la limpias. Eso también significa que eliminarla suele ser un tradeoff de rendimiento, no una ganancia gratis.

Contenedores Docker detenidos

Los desarrolladores subestiman esto constantemente. Un contenedor que no está corriendo sigue siendo un objeto de almacenamiento. Si aun existe, puede seguir ocupando espacio en disco.

Volúmenes de Docker

Los volúmenes es donde el riesgo sube. Pueden contener los datos que realmente te importan: bases de datos, mirrors de paquetes, subidas, índices de búsqueda, contenido de registro local o estado de servicios.

Esa es la diferencia entre la limpieza de Docker y la limpieza ordinaria de caché. Parte del almacenamiento de Docker es reconstruible. Parte es tu entorno.

Imágenes y objetos colgantes de Docker

Los objetos colgantes suelen ser los candidatos de limpieza más seguros. La documentación de prune de Docker define las imágenes colgantes como imágenes que no tienen tag y no son referenciadas por ningún contenedor. Son exactamente el tipo de acumulación que crece a través de la iteración normal.

Cómo revisar el uso de disco de Docker en Mac

El mejor primer movimiento no es Finder. Es una vista a nivel de Docker de lo que el daemon cree que está consumiendo espacio.

La recomendación propia de Docker en Mac empieza con docker system df -v, que muestra el uso de imágenes, contenedores, volúmenes locales y espacio recuperable. Esa es la forma más rápida de dejar de adivinar.

Usa este orden de revisión:

1. Empieza con docker system df -v

Este es el mejor primer resumen porque muestra:

• uso total y recuperable de imágenes;
• uso de contenedores;
• uso de volúmenes locales;
• un desglose más detallado cuando usas el flag verbose.

Si el espacio recuperable es pequeño, la limpieza amplia probablemente no ayudara mucho.

2. Revisa los contenedores detenidos antes de hacer prune

Comprueba si hay muchos contenedores salidos que ya nadie necesita. Estos suelen ser candidatos de limpieza más seguros comparados con volúmenes o estado de runtime activo.

3. Revisa las imágenes separadas de la caché de build

Las imágenes y la caché de build resuelven problemas diferentes. Si la caché es la principal culpable, la limpieza enfocada en caché suele ser mejor que un reset amplio de todo lo que Docker posee.

4. Revisa los volúmenes antes de cualquier cosa que use --volumes

Esta es la parte que la gente se salta y luego lamenta. Un volumen puede parecer desconectado de un contenedor corriendo actualmente pero aun representar datos locales reales de un proyecto que planeas iniciar mañana.

5. Revisa la imagen de disco de Docker Desktop en Mac

El FAQ de Docker para Mac nota que Docker Desktop almacena contenedores e imágenes Linux en un solo archivo de imagen de disco y que algunas herramientas muestran el tamaño máximo del archivo en vez del tamaño consumido real. Eso importa porque un número aterrador del lado del host no siempre es lo mismo que desperdicio inmediatamente recuperable.

Antes de hacer prune

Comandos rápidos de revisión de Docker

Estos comandos de inspección son útiles antes de eliminar nada:

docker system df -v
docker ps -a --size
docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.Size}}'
docker volume ls

Úsalos para confirmar que es realmente recuperable antes de elegir cualquier alcance de prune.

Cómo liberar espacio de Docker en Mac

Cuando docker system df -v ya muestra qué es realmente recuperable, libera espacio con el alcance más estrecho que resuelva el problema, en vez de con una pasada amplia:

# eliminar contenedores detenidos
docker container prune

# eliminar la caché de build (BuildKit)
docker builder prune

# eliminar imágenes colgantes (sin etiqueta)
docker image prune

# eliminar volúmenes sin usar - solo tras confirmar que no guardan datos que necesites
docker volume prune

Si quieres que Docker limpie varios tipos de objeto a la vez, docker system prune se encarga de contenedores detenidos, redes sin usar, imágenes colgantes y caché de build sin usar en un solo paso. Añade -a para eliminar también las imágenes que ningún contenedor usa, y --volumes solo cuando tengas la certeza de que ningún volumen guarda datos reales.

También puedes recuperar espacio desde Docker Desktop: abre Settings → Resources para ajustar o reducir el tamaño del disco virtual, o usa Troubleshoot → Clean / Purge data para un reinicio más fuerte. Ambos caminos se quedan dentro del flujo del propio Docker, que es más seguro que tocar Docker.raw a mano.

El intercambio es siempre el mismo: podar caché e imágenes te cuesta builds más lentos y volver a descargar, no tu código fuente, mientras que podar volúmenes puede eliminar datos locales reales, así que trata ese alcance con la máxima cautela.

Por qué eliminar carpetas de Docker directamente es riesgoso

La eliminación directa se siente atractiva porque parece decisiva. También es como conviertes la limpieza de Docker en ruleta de limpieza de runtime.

Hay dos razones.

Primera, Docker rastrea estado de runtime y metadatos. Cuando eliminas archivos gestionados por Docker fuera del propio flujo de Docker, arriesgas romper la relación entre lo que el runtime cree que existe y lo que realmente está en disco.

Segunda, en Mac la huella de Docker está vinculada a la imagen de disco gestionada por Docker Desktop y el almacenamiento de runtime. La documentación de Docker para Mac advierte explícitamente que no muevas la imagen de disco directamente en Finder porque Docker Desktop puede perderle la pista. La misma lección general aplica a la eliminación por fuerza bruta dentro del almacenamiento gestionado por Docker: las acciones conscientes de Docker son más seguras que adivinar en el filesystem.

Por eso eliminar archivos dentro de un contenedor corriendo no es lo mismo que recuperar espacio de disco del host. La documentación de Docker para Mac nota que el espacio del host se recupera cuando se eliminan imágenes, no automáticamente cuando los archivos desaparecen dentro de contenedores corriendo.

Cuándo prune ayuda

prune es útil cuando ya entiendes la huella y quieres que Docker elimine objetos que considera no utilizados.

Los casos principales donde ayuda son sencillos:

• docker system prune cuando contenedores detenidos, redes no utilizadas, imágenes colgantes y caché de build no utilizada se han acumulado;
• docker builder prune cuando la caché de build es el verdadero problema;
• docker volume prune cuando has verificado que los volúmenes no utilizados son verdaderamente desechables;
• limpieza filtrada por tiempo o etiqueta cuando quieres estrechar el alcance en vez de barrer todo.

Aquí es donde la limpieza consciente de Docker es claramente mejor que la eliminación cruda de archivos. El runtime entiende los tipos de objetos. Finder no.

Cuándo docker system prune es peligroso

El peligro no es que prune sea malo. El peligro es que “no utilizado” en Docker puede seguir significando “importante para mi flujo de trabajo.”

Ten cuidado cuando:

• un contenedor detenido es parte de un entorno local que planeas reanudar;
• el próximo build necesita la caché que estás a punto de limpiar;
• volúmenes locales contienen datos de bases de datos o servicios que aun te importan;
• docker system prune -a eliminaría imágenes que no están corriendo ahora pero que aun son parte de trabajo activo;
• estás a punto de añadir limpieza de volúmenes sin primero confirmar que representan esos volúmenes.

La documentación de Docker es explícita en que los volúmenes no se eliminan automáticamente porque eso podría destruir datos. Ese es el modelo mental correcto para la limpieza de volúmenes en general: los volúmenes merecen más sospecha que las imágenes o la caché colgante.

Cómo entender las consecuencias antes de la limpieza

Antes de limpiar nada, responde la pregunta de consecuencia en lenguaje llano:

¿Qué tendré que reconstruir, re-descargar, restaurar o re-crear después de esto?

Esa pregunta es más útil que “¿Cuánto puedo eliminar?”

Para Docker, la revisión práctica suele verse así:

1. ¿La huella principal es imágenes, caché de build, contenedores detenidos o volúmenes?
2. ¿Hay contenedores corriendo que son parte del plan, o la limpieza requiere detenerlos primero?
3. Si hago prune de la caché, ¿estoy cómodo con builds más lentos o re-descargas después?
4. Si hago prune de volúmenes, ¿qué estado de servicio o datos desaparecen con ellos?
5. ¿Estoy usando la limpieza de Docker para resolver un problema real de espacio recuperable, o reaccionando a una imagen de disco grande y opaca?

Esa es la diferencia entre una limpieza de desarrollador controlada y pánico aleatorio de almacenamiento.

Por qué la limpieza de desarrollo es diferente de la limpieza ordinaria de archivos

La limpieza ordinaria de archivos pregunta: “¿Qué carpeta es grande?”

La limpieza de Docker necesita preguntas diferentes:

• esto es caché reconstruible o datos persistentes de servicio;
• el runtime lo reporta como recuperable;
• la limpieza debería pasar por comandos de Docker en vez de eliminación del filesystem;
• contenedores corriendo, detenidos o volúmenes son parte del modelo de consecuencias;
• ¿necesito una revisión guiada antes de aplicar una ruta de limpieza riesgosa?

Por eso Docker pertenece en un flujo consciente de contenedores, no en el mismo cubo mental que eliminar descargas o vaciar una carpeta genérica de caché.

Dónde encaja StorageRadar

Eso importa porque Docker no es solo “una carpeta grande.” Es un ecosistema de tipos de objetos con diferentes consecuencias de limpieza.

Si la caché de build es el problema, tu acción es diferente a la de una máquina pesada en volúmenes. Si los contenedores corriendo deben detenerse primero, eso debería ser visible antes de la limpieza. Si el perfil es riesgoso, el flujo debería ralentizarte a propósito.

Lo que no deberías hacer

Evita estos errores comunes:

• no trates cada huella grande de Docker como un problema con un solo comando;
• no ejecutes rm -rf directo dentro de directorios gestionados por Docker porque las rutas se ven grandes;
• no asumas que una imagen de disco grande de Docker Desktop significa que todo ese espacio es recuperable de forma segura ahora mismo;
• no añadas limpieza de volúmenes a la ligera si no has comprobado que contienen esos volúmenes;
• no uses un prune amplio justo antes de una demo, release o reconstrucción de entorno local que no puedes permitirte.

Si Docker es solo una parte de un problema más amplio de máquina de desarrollo, la guía complementaria sobre DerivedData de Xcode ocupando demasiado espacio en Mac es una buena próxima lectura.

Conclusión

El uso de disco de Docker en Mac normalmente no es misterioso una vez que lo divides en los cubos correctos. Los mayores contribuyentes suelen ser imágenes, capas, caché de build, contenedores detenidos, volúmenes, objetos colgantes y almacenamiento de runtime de Docker Desktop.

El movimiento seguro es inspeccionar la huella primero, separar artefactos reconstruibles de datos persistentes y usar limpieza consciente de Docker solo después de entender las consecuencias.