Para um projeto Docker local no macOS, use um bind mount quando precisar editar ou inspecionar os mesmos arquivos no macOS e em um contêiner; use um named volume quando o contêiner deve ser o proprietário de dados persistentes, como um banco de dados ou cache. O teste prático é se você precisa de acesso direto aos arquivos no Finder ou em um aplicativo do Mac. Se sim, vincule a pasta específica do projeto. Se não, mantenha os dados em um named volume gerenciado pelo Docker.

O que muda entre os dois tipos de montagem?

Um bind mount conecta um caminho no seu Mac a um caminho dentro de um contêiner. As alterações ficam visíveis em ambos os lados, o que o torna útil para código-fonte, configurações e arquivos gerados que você deseja manter na pasta do projeto. Um named volume é armazenado e gerenciado pelo Docker, sendo anexado a um contêiner em um caminho escolhido. O Docker recomenda volumes para dados persistentes do contêiner e para quando o host não precisa de acesso direto aos arquivos. A documentação de bind mounts do Docker e a documentação de volumes descrevem essas diferenças.

Seus dados Geralmente escolha Motivo
Arquivos-fonte que você edita em uma IDE no Mac Bind mount O Mac e o contêiner acessam os arquivos do projeto.
O diretório de dados de um banco de dados Named volume O Docker gerencia dados persistentes do contêiner sem compartilhar cada arquivo do banco de dados pelo macOS.
Arquivos de saída que você quer abrir ou usar com ferramentas do Mac Bind mount A saída aparece no caminho escolhido no Mac.
Estado temporário que pode ser descartado Nenhum por padrão Avalie se os dados realmente precisam de persistência; um named volume permanece após a remoção do contêiner, a menos que você o remova separadamente.

Por que o macOS torna essa escolha importante

O Docker Desktop executa contêineres Linux dentro de uma máquina virtual Linux, mediando o acesso entre o sistema de arquivos do Mac e os contêineres. A documentação de configurações do Docker informa que o compartilhamento de arquivos do host adiciona sobrecarga (overhead); compartilhar arquivos em excesso pode aumentar o uso da CPU e tornar as operações do sistema de arquivos mais lentas. Ela recomenda especificamente manter itens que não sejam código, como caches e bancos de dados, em um volume de dados quando o desempenho for essencial. Configurações do Docker Desktop

Essa orientação não significa que todo bind mount será lento. Significa que o tipo de dados e o fluxo de trabalho observado fazem a diferença. A árvore de código-fonte de um projeto é um caso natural para bind mount, pois o objetivo é editar no Mac. Por outro lado, a grande quantidade de arquivos em constante modificação de um banco de dados geralmente não precisa ser navegada no Finder, tornando um named volume um ponto de partida melhor. Para repositórios excepcionalmente grandes, o Docker Desktop também documenta o Synchronized file shares como uma opção restrita a assinaturas que pode melhorar o desempenho do bind mount; isso altera o comportamento de compartilhamento de arquivos, não a distinção básica entre código visível no host e volume gerenciado pelo Docker. Synchronized file shares

Configure uma pasta de projeto e um volume de banco de dados

No Terminal, acesse o diretório do seu projeto e use um bind mount para o código. Este exemplo monta a pasta atual em /workspace em um contêiner Alpine descartável; substitua a imagem ou o comando conforme o contêiner de desenvolvimento desejado.

docker run --rm -it \
  --mount "type=bind,source=$PWD,target=/workspace" \
  alpine:latest sh

Nos shells padrão do macOS, $PWD expande para o diretório atual. Colocar todo o argumento da montagem entre aspas garante que o caminho expandido do host permaneça íntegro caso o nome de uma pasta contenha espaços. A sintaxe --mount do Docker é explícita. O caminho do host deve existir: o Docker documenta que, por padrão, um caminho de origem inexistente faz o --mount falhar. Um bind mount permite escrita a menos que seja marcado como somente leitura, portanto um processo no contêiner pode alterar arquivos no diretório montado do Mac. Use readonly quando o contêiner só precisar ler o projeto. Opções e comportamento de bind mounts

Para dados que pertencem ao contêiner, crie e anexe um named volume em vez disso. Este comando inicia o PostgreSQL com um volume em seu diretório de dados padrão:

docker volume create project-db

docker run --name project-postgres \
  --mount type=volume,source=project-db,target=/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD='local-dev-only' \
  -d postgres:17

Aqui, project-db é o nome do volume persistente, e POSTGRES_PASSWORD é uma configuração local ilustrativa, não um padrão seguro de gerenciamento de segredos para produção. Remover o contêiner não remove automaticamente um named volume. Essa persistência ajuda na substituição de contêineres, mas também significa que dados antigos podem permanecer e uma nova execução pode reutilizá-los. Guarde o nome do volume e a configuração do contêiner necessária para reconectar-se a ele.

Avalie visibilidade, portabilidade e limpeza

Antes de escolher, pergunte-se: vou abrir ou editar exatamente estes arquivos com softwares do Mac? Se sim, faça o bind mount da pasta mais restrita que atenda à tarefa, em vez de compartilhar uma parte desnecessariamente ampla do seu diretório pessoal (home). O Docker destaca que o macOS e o Linux tratam maiúsculas e minúsculas em nomes de arquivos de formas diferentes, o que pode evidenciar problemas de diferenciação de maiúsculas/minúsculas (case-sensitive) dentro de um contêiner. Verifique os nomes com atenção se o projeto se comportar de forma diferente no Linux. Notas sobre compartilhamento de arquivos do Docker Desktop

Se os arquivos devem permanecer restritos aos limites do contêiner, escolha um named volume e gerencie-o com os comandos de volume do Docker. O volume não é uma pasta acessível pelo Finder na localização comum do projeto; o Docker Desktop armazena seus dados Linux no ambiente da VM. Trate a remoção de volumes como uma etapa de exclusão de dados e faça backup do conteúdo importante separadamente. O guia de backup do Docker destaca que as imagens de contêiner não incluem alterações no sistema de arquivos armazenadas em volumes anexados. Backup e restauração do Docker Desktop

Um bind mount depende da existência do caminho no host, podendo ser menos portátil entre Macs com estruturas de diretórios distintas. Um named volume elimina essa dependência do caminho do projeto, mas seus dados ainda exigem um plano explícito de migração ou backup. Portanto, o padrão mais comum e direto para muitos projetos de desenvolvimento no Mac é usar um bind mount para o código-fonte e um named volume para o estado do banco de dados, documentando a localização de cada dado na configuração do Compose ou nas instruções de execução do projeto.

Fontes