Uso de Disco do Docker no Mac: O Que Realmente Consome Espaço

O Docker no Mac raramente parece enorme de uma vez. Ele cresce em camadas.

No começo é uma imagem, um projeto, um volume de banco de dados, um container parado, um build cache que tu pretendes limpar depois. Depois a máquina fica mais apertada, o Docker Desktop começa a parecer suspeito, e a conclusão usual é vaga mas emocionalmente satisfatória: “O Docker está comendo meu disco.”

Essa conclusão está na direção certa, mas é imprecisa demais para ser útil. O problema real geralmente não é “Docker em geral.” É acúmulo entre imagens, layers, build cache, containers parados, volumes e dados de runtime que ninguém revisou como um sistema.

Resposta rápida

Por que o Docker silenciosamente fica tão grande no Mac

O Docker foi projetado para manter estado útil até que tu explicitamente diga o contrário. A própria documentação do Docker descreve a limpeza como conservadora: imagens, containers, volumes e redes não utilizados geralmente não são removidos a menos que tu pedes ao Docker para faze-lo.

Isso é conveniente para fluxos de desenvolvedor é exatamente por isso que o uso de disco cresce devagar.

No Mac, o quadro parece ainda menos óbvio porque o Docker Desktop armazena containers e imagens Linux em um único arquivo grande de imagem de disco. Isso significa que o host pode mostrar uma pegada grande do Docker enquanto as causas reais estão enterradas dentro de múltiplas camadas de dados de runtime.

O padrão de crescimento geralmente e alguma combinação de:

• imagens baixadas e reconstruídas em vários projetos;
• layers compartilhadas reutilizadas entre tags e versões;
• containers parados que ainda mantêm layers graváveis;
• volumes que armazenam bancos de dados, arquivos enviados ou estado de serviços locais;
• build cache que mantém os builds rápidos até se tornarem caros;
• objetos dangling deixados para trás após reconstruções e retags.

O resultado é uma pegada que se expande silenciosamente porque cada adição individual parece normal.

Onde o Docker guarda os dados no Mac?

No Mac, o Docker não espalha arquivos pelo disco como faria um app nativo. O Docker Desktop roda Linux dentro de uma máquina virtual e guarda quase tudo (imagens, containers e volumes) dentro de um único arquivo grande de imagem de disco.

Por padrão, esse arquivo fica mais ou menos aqui:

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

O caminho exato pode mudar entre versões do Docker Desktop, mas a ideia é constante: um arquivo gerenciado carrega toda a pegada do lado Linux. É por isso que um único Docker.raw aparece no Finder como dezenas de gigabytes mesmo quando boa parte desse espaço é recuperável ou é apenas o tamanho máximo que a imagem de disco pode atingir.

Duas consequências vêm desse desenho:

• O tamanho no Finder engana. As ferramentas do host costumam informar o tamanho máximo da imagem de disco, não o espaço que o Docker realmente usa lá dentro.
• Não mexa no Docker.raw diretamente. A própria documentação do Docker para Mac avisa para não mover nem apagar a imagem de disco pelo Finder, porque o Docker Desktop pode perdê-la de vista. O espaço se recupera pelo Docker, não pelo sistema de arquivos.

O que realmente ocupa espaço do Docker no Mac

Se tu queres um plano de limpeza útil, separa a pegada do Docker em categorias em vez de tratá-la como uma caixa preta gigante.

É por isso que um fluxo genérico de “maior pasta” e fraco para o Docker. O mesmo tamanho total pode significar decisões de limpeza muito diferentes dependendo se o espaço e principalmente build cache ou dados reais de volumes.

Imagens Docker e layers compartilhadas

Imagens costumam ser a primeira coisa em que desenvolvedores pensam, mas a história mais profunda são as layers. Uma máquina com vários runtimes de linguagem, builds locais estilo CI e múltiplos microservicos pode acumular muitas layers compartilhadas e únicas rapidamente.

É por isso que o uso de disco nem sempre mapeia de forma limpa para a lista de imagens que tu te lembras de ter baixado.

Build cache do Docker

O build cache é uma das causas ocultas mais comuns em máquinas de desenvolvedor ativas. Ele existe para tornar builds futuros mais rápidos, o que significa que fica por aí até tu o limpares. Isso também significa que deletá-lo geralmente é uma troca de desempenho, não uma vitória gratuita.

Containers Docker parados

Desenvolvedores subestimam isso o tempo todo. Um container que não está rodando ainda é um objeto de armazenamento. Se ele ainda existe, ainda pode ocupar espaço em disco.

Volumes Docker

É aqui que o risco aumenta. Os volumes podem conter os dados que tu realmente te importas: bancos de dados, mirrors de pacotes, uploads, índices de busca, conteúdo de registro local ou estado de serviços.

Essa é a diferença entre limpeza do Docker e limpeza de cache comum. Alguns armazenamentos do Docker são reconstrutíveis. Alguns são teu ambiente.

Imagens e objetos Docker dangling

Objetos dangling geralmente são os candidatos mais seguros para limpeza. A documentação de prune do Docker define imagens dangling como imagens que não estão com tag e não são referenciadas por nenhum container. São exatamente o tipo de acúmulo que cresce através de iteração normal.

Como verificar o uso de disco do Docker no Mac

O melhor primeiro passo não é o Finder. É uma visão no nível do Docker do que o daemon acha que está consumindo espaço.

A recomendacao do próprio Docker no Mac começa com docker system df -v, que mostra uso de imagens, containers, volumes locais e espaço recuperável. Essa é a forma mais rápida de parar de adivinhar.

Usa esta ordem de revisão:

1. Começa com docker system df -v

Esse é o melhor primeiro resumo porque mostra:

• uso total e recuperável de imagens;
• uso de containers;
• uso de volumes locais;
• um detalhamento mais completo quando usas a flag verbose.

Se o espaço recuperável e pequeno, limpeza ampla provavelmente não vai ajudar muito.

2. Revisa containers parados antes de fazer prune

Verifica se há muitos containers encerrados que ninguém precisa mais. Esses costumam ser candidatos seguros de limpeza em comparação com volumes ou estado de runtime ativo.

3. Revisa imagens separadamente do build cache

Imagens e build cache resolvem problemas diferentes. Se o cache é o principal ofensor, limpeza focada em cache geralmente é melhor do que um reset amplo de tudo que o Docker possui.

4. Revisa volumes antes de qualquer coisa que use --volumes

Essa é a parte que as pessoas pulam e depois se arrependem. Um volume pode parecer desanexado de um container atualmente em execução, mas ainda representar dados locais reais de um projeto que tu planejas iniciar novamente amanhã.

5. Revisa a imagem de disco do Docker Desktop no Mac

O FAQ do Docker para Mac observa que o Docker Desktop armazena containers e imagens Linux em um único arquivo de imagem de disco é que algumas ferramentas mostram o tamanho máximo do arquivo em vez do tamanho real consumido. Isso importa porque um número assustador do lado do host nem sempre é a mesma coisa que desperdício imediatamente recuperável.

Antes de fazer prune em qualquer coisa

Comandos rápidos de revisão do Docker

Esses comandos de inspeção são úteis antes de tu remover qualquer coisa:

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

Usa-os para confirmar o que realmente é recuperável antes de escolher qualquer escopo de prune.

Como liberar espaço em disco do Docker no Mac

Depois que docker system df -v mostra o que é de fato recuperável, libere espaço com o escopo mais estreito que resolve o problema, em vez de uma varrida ampla:

# remover containers parados
docker container prune

# remover o cache de build (BuildKit)
docker builder prune

# remover imagens penduradas (sem tag)
docker image prune

# remover volumes sem uso - só depois de confirmar que não guardam dados de que você precisa
docker volume prune

Se você quiser que o Docker limpe vários tipos de objeto de uma vez, docker system prune cuida de containers parados, redes sem uso, imagens penduradas e cache de build sem uso em um passo. Acrescente -a para remover também as imagens que nenhum container usa, e --volumes só quando tiver certeza de que nenhum volume guarda dados reais.

Também dá para recuperar espaço pelo próprio Docker Desktop: abra Settings → Resources para ajustar ou reduzir o tamanho do disco virtual, ou use Troubleshoot → Clean / Purge data para um reset mais pesado. Os dois caminhos ficam dentro do fluxo do Docker, o que é mais seguro do que mexer no Docker.raw na mão.

A troca é sempre a mesma: podar cache e imagens custa builds mais lentos e novos downloads, não o seu código-fonte, enquanto podar volumes pode remover dados locais reais, então trate esse escopo com o máximo de cautela.

Por que deletar pastas do Docker diretamente é arriscado

Deleção direta parece atrativa porque parece decisiva. Também é como tu transformas limpeza do Docker em roleta de limpeza de runtime.

Há duas razões.

Primeiro, o Docker rastreia estado de runtime e metadados. Quando tu removes arquivos gerenciados pelo Docker fora do próprio fluxo do Docker, tu arriscas quebrar a relação entre o que o runtime acredita existir e o que realmente está no disco.

Segundo, no Mac a pegada do Docker está vinculada a imagem de disco gerenciada pelo Docker Desktop e ao armazenamento de runtime. A própria documentação do Docker para Mac avisa explicitamente para não mover a imagem de disco diretamente no Finder porque o Docker Desktop pode perde-la. A mesma lição geral se aplica a deleção bruta dentro do armazenamento gerenciado pelo Docker: ações Docker-aware são mais seguras do que adivinhação no filesystem.

É por isso também que deletar arquivos dentro de um container em execução não é a mesma coisa que recuperar espaço em disco do host. Os docs do Docker para Mac observam que o espaço do host é recuperado quando imagens são deletadas, não automaticamente quando arquivos desaparecem dentro de containers em execução.

Quando o prune ajuda

prune é útil quando tu já entendes a pegada e queres que o Docker remova objetos que considera não utilizados.

Os principais casos onde ajuda são diretos:

• docker system prune quando containers parados, redes não utilizadas, imagens dangling e build cache não utilizado se acumularam;
• docker builder prune quando o build cache é o problema real;
• docker volume prune quando tu verificaste que volumes não utilizados são realmente descartáveis;
• limpeza filtrada por tempo ou label quando tu queres estreitar o escopo em vez de varrer tudo.

É aqui que limpeza Docker-aware é claramente melhor do que deleção bruta de arquivos. O runtime entende tipos de objetos. O Finder não.

Quando docker system prune é perigoso

O perigo não é que prune seja ruim. O perigo é que “não utilizado” no Docker ainda pode significar “importante para o meu fluxo de trabalho.”

Tem cautela quando:

• um container parado faz parte de um ambiente local que tu esperas retomar;
• o próximo build precisa do cache que tu estás prestes a apagar;
• volumes locais contem dados de banco de dados ou serviços que tu ainda te importas;
• docker system prune -a removeria imagens que não estão rodando agora mas ainda fazem parte de trabalho ativo;
• tu estás prestes a adicionar limpeza de volumes sem antes confirmar o que esses volumes representam.

Os docs do Docker são explícitos que volumes não são removidos automaticamente porque isso poderia destruir dados. Esse é o modelo mental certo para limpeza de volumes em geral: volumes merecem mais suspeita do que imagens ou cache dangling.

Como entender as consequências antes da limpeza

Antes de tu limpar qualquer coisa, responde a questão das consequências em linguagem simples:

O que eu terei que reconstruir, rebaixar, restaurar ou recriar depois disso?

Essa questão é mais útil do que “Quanto posso deletar?”

Para o Docker, a revisão prática geralmente se parece com isso:

1. A pegada principal e imagens, build cache, containers parados ou volumes?
2. Algum container em execução faz parte do plano, ou a limpeza requer parar primeiro?
3. Se eu fizer prune do cache, estou confortável com builds ou pulls mais lentos depois?
4. Se eu fizer prune dos volumes, qual estado de serviço ou dados desaparece com eles?
5. Estou usando limpeza do Docker para resolver um problema real de espaço recuperável, ou reagindo a uma imagem de disco grande e opaca?

Essa é a diferença entre uma limpeza de desenvolvedor controlada e pânico de armazenamento aleatório.

Por que limpeza de desenvolvedor é diferente de limpeza comum de arquivos

Limpeza comum de arquivos pergunta: “Qual pasta é grande?”

Limpeza do Docker precisa de perguntas diferentes:

• isso é cache reconstruível ou dados persistentes de serviço;
• o runtime está relatando como recuperável;
• a limpeza deve acontecer através de comandos Docker em vez de deleção no filesystem;
• containers em execução, containers parados ou volumes fazem parte do modelo de consequências;
• eu preciso de uma revisão guiada antes de aplicar um caminho de limpeza arriscado?

É por isso que o Docker pertence a um fluxo container-aware, não ao mesmo balde mental de deletar downloads ou esvaziar uma pasta de cache genérica.

Onde o StorageRadar se encaixa

Isso importa porque o Docker não é apenas “uma pasta grande.” É um ecossistema de tipos de objetos com diferentes consequências de limpeza.

Se o build cache é o problema, tua ação é diferente de uma máquina pesada em volumes. Se containers em execução devem ser parados primeiro, isso deve estar visível antes da limpeza. Se o perfil é arriscado, o fluxo deve te desacelerar de propósito.

O que não fazer

Evita estes erros comuns:

• não trates toda pegada grande do Docker como um problema com um comando;
• não executes rm -rf direto dentro de diretórios gerenciados pelo Docker porque os caminhos parecem grandes;
• não assumas que uma imagem de disco grande do Docker Desktop significa que todo aquele espaço e seguramente recuperável agora;
• não adiciones limpeza de volumes casualmente se não verificaste o que esses volumes contem;
• não uses um prune amplo logo antes de uma demo, release ou rebuild de ambiente local que não podes pagar.

Se o Docker é apenas parte de um problema maior na máquina de desenvolvedor, o guia complementar sobre Xcode DerivedData Ocupando Espaço Demais no Mac é uma próxima leitura útil.

Conclusão

O uso de disco do Docker no Mac geralmente não é misterioso depois que tu o divides nos buckets certos. Os maiores contribuintes tipicamente são imagens, layers, build cache, containers parados, volumes, objetos dangling e armazenamento de runtime do Docker Desktop.

A jogada segura e inspecionar a pegada primeiro, separar artefatos reconstrutíveis de dados persistentes e usar limpeza Docker-aware somente depois de entender as consequências.