# Limpar o Docker no Mac: imagens, cache de build, volumes > Inspecione imagens, contêineres, cache de build e volumes com estado antes de podar, e meça o uso do disco esparso à parte do que o Docker informa. Published: 2026-06-26 | Updated: 2026-10-18 O Docker Desktop pode usar dezenas de gigabytes porque imagens, camadas graváveis de contêiner, cache de build e volumes vivem dentro de um disco virtual Linux. Essas categorias não são igualmente descartáveis. O cache de build em geral é reproduzível; um volume de banco de dados pode ser a única cópia de dados importantes. A limpeza segura começa pelo inventário do Docker, não pelo comando de poda mais amplo. Se você quer remover o Docker Desktop em vez de liberar espaço dentro dele, veja [Desinstalar o Docker Desktop no Mac](https://mole.fit/tested-apps/docker). ## Por que o espaço do Docker não volta O Docker Desktop no macOS roda uma VM Linux e normalmente guarda os dados num disco virtual esparso chamado `Docker.raw`. O [guia de armazenamento no Mac](https://docs.docker.com/desktop/troubleshoot-and-support/faqs/macfaqs/#where-does-docker-desktop-store-linux-containers-and-images) do Docker aponta para **Docker Desktop › Settings › Resources › Advanced** para o local, o limite de disco e o espaço real consumido. Mova com esse controle, não pelo Finder. Um arquivo esparso tem um tamanho lógico máximo e uma alocação física menor, então `ls -lh` sozinho pode fazê-lo parecer bem maior do que a capacidade que ocupa agora. Veja o que o próprio Docker acha que está usando: ``` docker system df -v ``` A visualização detalhada separa imagens, contêineres, volumes locais e cache de build. "Reclaimable" significa que o Docker não vê uma referência atual que exija o objeto; não prova que você não vai precisar amanhã de um contêiner parado, de uma imagem antiga ou de um volume. Inspecione também `docker ps -a` e `docker volume ls` antes de podar. ## Comece com uma limpeza estreita Sempre recupere de dentro do Docker, não apagando o arquivo do disco virtual. Comece pela categoria que você entende: ``` docker builder prune --filter until=168h docker image prune docker container prune ``` O primeiro comando remove cache de build com mais de sete dias; ajuste a idade ao seu trabalho. Os dois seguintes pedem confirmação antes de remover imagens pendentes e contêineres parados. Rode `docker system df -v` de novo depois de cada passo para ver qual ação importou. O [guia de poda](https://docs.docker.com/engine/manage-resources/pruning/) do Docker documenta `docker system prune` como um comando de conveniência mais amplo. Acrescentar `-a` remove todas as imagens sem uso, não só camadas pendentes. Acrescentar `--volumes` amplia a operação a volumes anônimos sem uso, que podem conter arquivos de banco de dados ou outro estado. Não faça de `docker system prune -a --volumes` um comando padrão de limpeza. Antes de qualquer poda de volume, inspecione nomes e posse: ``` docker volume ls docker volume inspect ``` Volumes criados pelo Compose normalmente carregam rótulos de projeto e de serviço. Identifique o projeto dono e exporte ou faça backup de dados que não podem ser reconstruídos antes de remover o volume. ## Recuperar a própria imagem de disco Dá para apagar `Docker.raw` para recuperar o espaço? Não como uma exclusão no Finder. O arquivo é o disco inteiro da VM Linux, então removê-lo no Finder ou com `rm` destrói cada imagem, contêiner e volume dentro dele, não só a folga, e o Docker reconstrói um disco vazio na próxima abertura. Recupere de dentro do Docker: pode, depois deixe o disco esparso devolver blocos, e use Settings para o local e o limite da imagem de disco. O número enorme que você vê costuma ser o máximo lógico de um arquivo esparso, não o espaço físico em uso, então meça a alocação real antes de supor que tudo é recuperável. Depois de uma poda, blocos livres existem dentro do sistema de arquivos Linux antes de o macOS necessariamente recebê-los do disco esparso. A documentação atual do Docker diz que uma imagem `Docker.raw` normalmente devolve o espaço elegível do host em segundos; imagens antigas `Docker.qcow2` usam um processo em segundo plano que pode levar minutos. Meça de novo o uso real do disco em vez de julgar o máximo lógico do arquivo. Uma redefinição de fábrica não é compactação: ela destrói contêineres, imagens, volumes e ajustes locais. Use só quando essa perda completa for intencional e os dados importantes de volume tiverem sido exportados. ## Por dentro: por que o arquivo cresce e não encolhe O Docker Desktop roda uma VM Linux, e `Docker.raw` é o disco virtual dessa VM: um arquivo esparso que cresce conforme o convidado escreve, mas nem sempre devolve espaço ao macOS na hora em que o convidado apaga. Remover uma imagem marca blocos como livres dentro do sistema de arquivos da VM. O Docker Desktop pode então usar TRIM/discard e compactação para devolver blocos elegíveis ao host. O momento depende da versão e da implementação da imagem de disco. Por isso uma limpeza lógica e uma mudança de capacidade no nível do host precisam ser medidas separadamente, e por isso apagar o arquivo do host destrói os contêineres, as imagens e os volumes guardados dentro dele.
Um arquivo esparso Docker.raw cresce conforme a VM convidada escreve e pode devolver blocos elegíveis ao macOS por discard e compactação.
Apagar um objeto do Docker libera espaço primeiro dentro da VM. Devolver a alocação física ao macOS é um passo separado do disco esparso.
## Onde um mapa de disco ajuda Um mapa de disco como a visualização Analisar do [Mole](https://mole.fit/) pode revelar o disco virtual e a pegada física dele. A própria CLI do Docker é que deve decidir quais objetos internos estão referenciados. As duas visualizações respondem perguntas diferentes: o macOS mostra onde a capacidade está alocada, enquanto o Docker explica o que essa alocação contém. ## Uma ordem segura de operações Rode `docker system df -v`, identifique projetos antigos e volumes com estado, exporte dados únicos e pode uma categoria de cada vez. Confira de novo tanto os totais internos do Docker quanto a capacidade física do macOS. Use flags amplas de poda só depois de revisar o alcance expandido, e nunca use uma redefinição de fábrica como atalho rotineiro de recuperação de espaço. O ganho seguro mais rápido costuma ser cache de build antigo, não volumes desconhecidos. --- Canonical HTML page: https://mole.fit/pt-br/blog/how-to-clean-up-docker-mac Blog index for agents: https://mole.fit/pt-br/blog/llms.txt Site index for agents: https://mole.fit/llms.txt