For a local Docker project on macOS, use a bind mount when you need to edit or inspect the same files in macOS and a container; use a named volume when the container should own persistent data such as a database or cache. The practical test is whether you need direct access to the files in Finder or a Mac app. If yes, bind the specific project folder. If not, keep the data in a named volume managed by Docker.

What changes between the two mount types?

A bind mount connects a path on your Mac to a path inside a container. Changes are visible from either side, which makes it useful for source code, configuration, and generated files you want to keep in your project folder. A named volume is stored and managed by Docker, and attached to a container at a chosen path. Docker recommends volumes for persistent container data and when the host does not need direct file access. Docker’s bind mount documentation and volume documentation describe these differences.

Your data Usually choose Reason
Source files you edit in a Mac IDE Bind mount Mac and container access the project files.
A database’s data directory Named volume Docker manages persistent container data without sharing every database file through macOS.
Output you want to open or use with Mac tools Bind mount The output appears at the chosen Mac path.
Temporary state that can be discarded Neither by default Consider whether the data needs persistence at all; a named volume remains after container removal unless you remove it separately.

Why macOS makes the choice matter

Docker Desktop runs Linux containers inside a Linux virtual machine, so it mediates access between the Mac filesystem and containers. Docker’s settings documentation says sharing host files adds overhead; sharing too many files can increase CPU load and slow filesystem operations. It specifically recommends keeping non-code items such as caches and databases in a data volume when performance matters. Docker Desktop settings

That guidance does not mean every bind mount will be slow. It means the type of data and your observed workflow matter. A project’s source tree is a natural bind mount because editing on the Mac is the goal. A database’s many changing files usually do not need to be browsed in Finder, so a named volume is a better starting point. For unusually large repositories, Docker Desktop also documents Synchronized file shares as a subscription-limited option that can improve bind-mount performance; it changes file-sharing behavior, not the basic distinction between host-visible source and Docker-managed volume. Synchronized file shares

Set up a project folder and a database volume

From Terminal, move into your project directory and use a bind mount for code. This example mounts the current folder at /workspace in a disposable Alpine container; replace the image or command to suit your development container.

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

In the default macOS shells, $PWD expands to the current directory. Quoting the full mount argument keeps the expanded host path together if a folder name contains spaces. Docker’s --mount syntax is explicit. The host path must exist: Docker documents that a missing source path causes --mount to fail by default. A bind mount is writable unless marked read-only, so a container process can change files in the mounted Mac directory. Use readonly when the container only needs to read the project. Bind mount options and behavior

For data the container owns, create and attach a named volume instead. This command starts PostgreSQL with a volume at its standard data directory:

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

Here project-db is the persistent volume name, and POSTGRES_PASSWORD is an illustrative local setting, not a production secret-management pattern. Removing the container does not automatically remove a named volume. That persistence helps with container replacement, but also means old data can remain and a new run may reuse it. Keep a note of the volume name and the container configuration needed to reconnect to it.

Check visibility, portability, and cleanup

Before choosing, ask: will I open or edit these exact files with Mac software? If so, bind-mount the narrowest folder that serves the task, rather than sharing an unnecessarily broad part of your home directory. Docker notes that macOS and Linux handle filename case differently, which can expose case-sensitive filename issues in a container. Check names carefully if the project behaves differently inside Linux. Docker Desktop file-sharing notes

If the files should stay behind the container boundary, choose a named volume and manage it with Docker’s volume commands. The volume is not a Finder folder in the ordinary project location; Docker Desktop stores its Linux data in its VM environment. Treat volume removal as a data deletion step, and back up important volume contents separately. Docker’s backup guidance notes that container images do not include filesystem changes stored in attached volumes. Docker Desktop backup and restore

A bind mount depends on the host path being present, so it can be less portable across Macs with different directory layouts. A named volume avoids that project-path dependency, but its data still needs an explicit backup or migration plan. The simple default for many Mac development projects is therefore a bind mount for source code and a named volume for database state, with each data location documented in the project’s Compose configuration or run instructions.

Sources