How to Completely Uninstall Docker Desktop on Mac Without Losing Volumes

Before uninstalling: inventory Docker's reproducible and persistent data

Docker Desktop runs Linux containers inside a virtual machine. Its disk image can contain images, stopped and running containers, build cache, and volumes. Project source normally lives in your own bind-mounted folders and remains outside that disk, but a named volume may hold the only copy of a local PostgreSQL, MySQL, Redis, or application database.

Start Docker while it is still healthy and record the inventory. Run docker system df -v for size by category, docker ps -a for containers, docker volume ls for named volumes, docker image ls for images, and docker context ls for contexts. Compose files, Dockerfiles, .dockerignore files, and source repositories belong with your projects and must be kept.

1. Run docker system df -v and save the category totals.
2. Run docker volume ls and map every important volume to the project or database that owns it.
3. Export data from databases using their native backup tools, or follow Docker's volume-backup guidance before removal.
4. Save any locally built image that cannot be rebuilt or pulled again; record required registries and tags.
5. Record docker context ls and preserve ~/.docker only if you need contexts, credentials, or configuration later.

A volume being 'unused' only means no current container references it. It does not prove the data is disposable.

Choose cleanup or uninstall — they are different jobs

If you will keep using Docker, do not uninstall it merely because Docker.raw is large. Use Docker's own inventory and pruning commands, starting with unused build cache and clearly obsolete images. The virtual disk may not immediately shrink even after internal space becomes reusable, so app deletion is not a reliable substitute for storage management.

Uninstall is appropriate when you are retiring Docker Desktop, switching runtimes, fixing a broken installation that cannot be repaired in place, or intentionally resetting all Docker state. That decision includes the virtual machine and therefore has a wider blast radius than deleting an app cache.

Use Docker Desktop's official uninstall action

Docker documents uninstalling from Docker Desktop's Troubleshoot menu on macOS. Use that supported route while the application can still open. It understands the application and its privileged components better than manually deleting random Library paths. Docker also documents a command-line uninstaller inside the app bundle for cases where the interface is unavailable; follow the current official page rather than copying a stale command from a forum.

Quit development tools that are actively calling Docker, stop important Compose projects cleanly, and complete backups before starting. After the official uninstaller finishes, restart the Mac if Docker's background components or networking still appear active. Do not empty the Trash or delete backups until verification is complete.

Review residual files without deleting credentials or volume data blindly

After the official uninstall, application caches, preferences, logs, and support files may remain. Their names usually identify Docker Desktop, but ownership still matters. The ~/.docker directory can contain CLI configuration, credential-store references, contexts, plugin state, and registry settings; keep or back it up unless you intentionally want to reset the Docker CLI as well.

The group container and Docker.raw paths are not ordinary cache folders. Docker.raw is the virtual disk that held images and volumes; group-container data can belong to Docker Desktop's managed state. If the official uninstaller leaves a protected container path, inspect the documented reason and your backups before manual removal. A permission error is not a reason to escalate to an unconditional sudo delete.

AskClean applies the same boundary: launcher cache can be recommended, ~/.docker is protected as credential/configuration data, and Docker.raw plus group-container data are shown as provider-managed, never as automatic cleanup.

Remove optional CLI and helper installations by their original installer

The docker command may have come from Docker Desktop, Homebrew, another container runtime, or a separate package. Run command -v docker and inspect the resolved path before removing it. If Homebrew owns the formula, use Homebrew to uninstall it. If another runtime provides a compatible CLI, removing that command can break the replacement you intended to keep.

The same rule applies to Compose plugins, credential helpers, kubectl, and contexts. Do not infer ownership from the filename alone. Remove only the components that belong to the installation method you are retiring, and keep project YAML, Dockerfiles, registry documentation, and backup archives outside cleanup.

Verify that Docker is gone and your protected data is usable

Check Activity Monitor for Docker processes, run command -v docker, and confirm Docker Desktop no longer appears in Applications or Login Items. Inspect the known application-support paths and classify each remainder as cache, configuration, credential, backup, or virtual-disk data before removal.

Restore or inspect one important backup before deleting the source volume or virtual disk. Confirm Compose files and bind-mounted project folders remain. If macOS Storage does not update immediately, compare the measured Docker paths from before and after and allow System Data time to recalculate.

For a complex installation, AskClean can scan Docker-related application residues and show why protected paths are not selected. It should complement the official uninstall and backup workflow, not replace Docker's understanding of its own volumes.

Docker uninstall safety map

Docker Desktop locations and uninstall behavior change across releases. Prefer Docker's current settings and documentation over an old path list.

FAQ