Back up your Docker data before you uninstall Docker Desktop—not after you move the app to Trash. Docker's own uninstaller destroys local containers, images, and volumes, including a database stored in a volume, according to Docker's uninstall documentation.

The safe order is inventory, backup, restore check, then uninstall. A saved image is not a saved database. This guide separates the pieces so you can decide what matters before removing anything.

Choose the right branch before you start

  • Keeping Docker, just freeing space? This is not an uninstall task. First inventory local-only images, container writable-layer files, and volumes. Do not run prune or factory reset until those preservation decisions are complete. Cleanup is outside this uninstall guide.
  • Removing Docker Desktop while it still runs? Inventory the current local environment, back up important volumes separately, and save local-only images and container configuration.
  • Docker Desktop will not start? Use Docker's stopped-VM backup procedure before reinstalling or uninstalling. Do not reset the VM to make it start first: that can erase the data you are trying to recover.
  • Using a remote Docker engine too? Identify the selected context first. An inventory of a remote server tells you nothing about the Desktop data on this Mac.

These branches follow the distinction between a working installation and a failed installation in Docker's backup and restore guide.

1. Inventory the data, not just the app

With Docker Desktop running, use these diagnostic commands. They list objects; they do not remove them:

docker context show
docker context ls
docker container ls -a
docker image ls
docker volume ls

Check that the selected context is the Desktop environment you intend to remove. If it is not, select the appropriate local context in Docker Desktop before proceeding. Keep a private record of the container names, image tags, and volume names that matter.

For each important container, inspect it by its actual name:

docker container inspect YOUR_CONTAINER_NAME

Replace the placeholder; do not paste it unchanged. Read the Mounts section and distinguish volume from bind. Docker's volume documentation explains that Docker manages volumes, while bind mounts depend on host directories. A project folder bind-mounted from your Mac needs its own ordinary file backup; it is not preserved by saving a container image.

Save your Compose file, relevant configuration, and the settings needed to recreate the services. Keep secret files in protected storage, not in a public repository. Docker specifically recommends remembering container creation options or keeping a Compose file in its backup guide.

2. Back up volumes with application consistency in mind

A volume can outlive an individual container. That does not mean it survives uninstalling Docker Desktop. The volume lifecycle described in Docker's storage documentation is different from the destructive Desktop uninstall described in Docker's uninstall warning.

Make a small checklist for each volume: what application owns it, whether you need its contents, where its backup will live, and how you will restore it. Include unfamiliar anonymous volumes until you have identified them; a generated name is not evidence that the data is disposable.

For a database, first use that database's supported backup workflow. Do not assume that archiving files while a database is writing produces a valid backup. For example, PostgreSQL's file-system backup documentation requires shutting down the server for a simple file copy; a consistent snapshot or database-supported online backup is a different procedure with additional requirements.

A practical sequence is:

  1. Identify the database and version, and follow its matching backup instructions.
  2. Save the database backup outside Docker's managed storage and outside the application folders being removed.
  3. If you also need a raw volume archive, stop all writers cleanly before following Docker's volume backup procedure. Its example creates a helper container and writes an archive; it is not merely a read-only inspection.
  4. Record the exact volume-to-application mapping and the restore method.
  5. Restore into a separate test environment or temporary volume, never over the only original, and check that the application can read the expected data.

The restore check is a safety recommendation, not a claim that this article tested your backup. If you cannot complete it, stop before uninstalling anything important.

3. Preserve container-local changes, then save images

Classify the state before choosing a backup:

  • Images: the original built or pulled filesystem layers. Saving an existing image does not capture later changes made inside a container created from it.
  • Volumes: Docker-managed data mounted into a container; back these up separately.
  • Bind mounts: host files mounted into a container; back up the actual Mac folders separately.
  • Container writable layer: files created or edited inside the container outside mounted paths, such as a manually edited configuration or local-only output. These disappear when the container is destroyed, as Docker's volume lifecycle documentation explains.
  • Recreation configuration: Compose files, environment inputs, ports, and mount mappings. This records how to recreate a service, not a copy of its filesystem data.

Use docker container diff YOUR_CONTAINER_NAME to review added, changed, and deleted paths, then compare them with the inspected mounts. Docker documents this diagnostic; a changed-file list is not a backup. Decide which container-local-only files are intentional and needed, rather than assuming everything is reproducible from the image.

For selected ordinary files, Docker's documented docker container cp can copy from a running or stopped container to the Mac. Use a new destination outside Docker's removal paths, review its overwrite and ownership behavior, and stop writers cleanly when consistency matters. Follow the copy reference, not a guessed archive of a live database.

If you need to preserve broader writable-layer changes, Docker's backup guide documents committing the actual container to a new image with docker container commit, then saving that resulting image. The commit reference says mounted-volume data is excluded. A commit captures filesystem changes and some configuration, not a complete running-state snapshot; keep the recreation configuration and separate volume/bind-mount backups too. Pausing during commit is not a substitute for a database-supported consistency procedure.

Do not skip the commit/copy decision and merely save the original image: docker image save saves an image, not an existing container's unsaved writable layer.

For an image that exists only on this Mac, Docker documents saving it to a local archive with docker image save -o images.tar image1. Substitute your actual image reference and choose a backup destination outside Docker's data folders. This writes a backup file and needs enough free space; it is not an uninstall command.

If an image can be rebuilt, keep the Dockerfile, build context, dependency versions, and any private resources needed for the build. If it can be pulled again, record its exact reference and confirm you still have registry access. A tag name alone is not a backup of local modifications.

Docker also warns that committed images can contain sensitive environment variables. Do not upload an image to a public registry simply because a backup tutorial suggests pushing it. A protected local archive may be the more appropriate choice.

4. If Docker will not start, copy the stopped VM first

Docker's whole-VM backup instructions require Docker Desktop to be fully stopped before copying its disk. The documented default Mac location is:

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

If you changed the disk image location, use that configured location instead. Copy the file to safe storage using Finder after confirming Docker Desktop has stopped. Do not move or delete the original yet. Allow enough destination space and confirm the copy completes.

Docker documents restoring the disk to the same location after reinstalling. Treat this as a recovery path, not a guarantee that every version or damaged database will recover. A stopped VM copy also does not replace a separate backup of bind-mounted host folders or project secrets.

5. Use Docker's Mac uninstaller only after the backup gate

Before confirming removal, check that the required backups are outside the removal paths, their copies are accessible, and your restore plan is written down.

Then follow Docker's Mac GUI instructions: open Docker Desktop, choose the Dashboard's Troubleshoot icon, select Uninstall, and confirm Uninstall again. Afterward, move the Docker application to Trash.

The confirmation is destructive to local Docker data. The app bundle sitting in Trash is not a recovery mechanism for volumes erased by Docker's uninstaller.

Docker lists possible residual folders, including ~/Library/Group Containers/group.com.docker and ~/.docker. Do not blindly remove them. Review configuration you may still need for another engine or remote context, and leave uncertain files alone. If a protected metadata file produces an error, check Docker's documented caveat rather than forcing deletion or changing macOS protections.

FAQ

Does uninstalling Docker Desktop delete named volumes?

Yes. Docker warns that Desktop uninstall destroys local volumes along with containers and images. A named volume's ability to survive container removal does not protect it from Desktop uninstall. Back up important contents first.

Is saving an image enough to preserve my database?

No. Saving the original image misses unsaved container writable-layer changes, and committing a container still excludes mounted-volume data. Preserve intentional container-local files with the documented copy or commit-then-save workflow, and preserve database data with its supported backup workflow and any separately prepared volume backup.

Can I back up Docker.raw while Docker Desktop is running?

Not using Docker's documented whole-VM copy procedure. Docker requires Desktop to be fully stopped before copying the disk. If it runs normally, application-native backups and separate image and volume backups give you more targeted recovery options.

Will reinstalling Docker Desktop bring my old containers back?

Not automatically after a destructive uninstall. Docker documents loading saved images, recreating containers from their configuration, and separately restoring volumes, or restoring a previously copied VM disk. You need the backups first.

Should I delete every remaining Docker folder?

No. Residual configuration may matter to another Docker setup, and uncertain data should stay until reviewed. Completing the uninstall does not require a speculative sweep of your Library or home directory.

A planned toolchain review, not a backup substitute

SwoopByte Uninstaller is not publicly released. Its planned toolchain support includes Docker, with detection and sizes free and removal in Pro. Join the Uninstaller waitlist if that workflow would help. It cannot substitute for a verified database or volume backup, and this guide's Docker vendor-uninstall steps are not a SwoopByte workflow.

For ordinary app bundles rather than container data, see how to completely uninstall an app on Mac.