If Docker Desktop shows up near the top of Activity Monitor's memory list even when you think nothing is running, you're not misreading it. This is architectural, not a bug in the traditional sense, though the degree to which it happens has been the subject of long-running complaints.
Why Docker Desktop needs a VM on Mac at all
Docker containers share the host machine's kernel, which is how they stay lightweight compared to a full virtual machine on Linux. macOS doesn't have a Linux kernel, so Docker Desktop for Mac runs a small Linux VM in the background (historically via HyperKit, more recently other virtualisation frameworks) purely so your containers have a Linux kernel to share. That VM needs its own allocated memory, separate from whatever your containers themselves use, and it stays running the whole time Docker Desktop is open, whether or not a container is active.
How much memory is normal, and when it's not
A completely idle Docker Desktop VM typically holds somewhere in the range of 1-4GB depending on your configured resource limits. GitHub issue trackers for Docker's Mac client describe cases well beyond that: the background helper process (historically com.docker.hyperkit) accumulating memory and CPU over time even with no active containers, in issues that have been open and discussed for years across multiple Docker Desktop versions. Separately, Docker Desktop's default memory allocation has been reported as too conservative for real development work, leading some users to manually raise it and then wonder why usage climbs to match the new ceiling, which is expected: Docker will use up to whatever limit you've set if your containers ask for it.
What genuinely helps
Check your configured memory limit. Open Docker Desktop's Settings, go to Resources, and look at the Memory slider. If it's set higher than you need for your actual projects, lower it; Docker won't exceed this ceiling regardless of what your containers request.
Quit Docker Desktop when you're not using it. Unlike many menu-bar utilities, Docker Desktop isn't designed to sit unobtrusively in the background when idle; if you're not actively developing against containers, quitting it fully (not just closing the window) reclaims the VM's memory entirely.
Prune unused images and volumes. Running docker system prune in Terminal removes stopped containers, unused networks, and dangling images, which can reduce disk pressure and, indirectly, some of the bookkeeping overhead Docker Desktop maintains.
Consider a lighter alternative for simple use cases. If you only need Docker occasionally and don't require Docker Desktop's full GUI and Kubernetes integration, lighter-weight Mac-native alternatives like Colima or OrbStack use a smaller, more efficient VM layer and have a reputation for a noticeably lower baseline memory footprint. This is a genuine trade-off (less built-in tooling) rather than a strict downgrade, worth investigating if Docker Desktop's overhead is a recurring frustration.
Restarting Docker Desktop vs restarting your Mac
If Docker Desktop's memory use has crept up over a long working session, quitting and reopening the app resets its VM to a clean baseline without needing a full system restart, and is the first thing worth trying before anything more drastic.
Where a memory-relief tool fits in
Docker Desktop's own VM memory isn't something a general memory-relief tool can reclaim while Docker itself is still running, since that memory is legitimately allocated to the VM you're using. Where Shiny genuinely helps is everything else competing for RAM alongside Docker: browser tabs, Slack, Electron apps, and orphaned helper processes from apps you've since closed. Freeing that up in one click gives Docker's VM more headroom to work with on a Mac that's juggling several demanding apps at once, which is a realistic situation for most developers running Docker day to day.
For a broader look at what's actually consuming your Mac's memory during a typical development session, see how to free up RAM on Mac and the Xcode memory guide if you're also running Apple's own development tools alongside Docker.
Checking exactly what Docker is holding
Docker Desktop's own dashboard gives you more visibility than Activity Monitor alone. Open the Docker Desktop app and look at the Containers tab to see what's actually running versus stopped, since a stopped container still occupies disk space (and sometimes cached layers in memory) even though it's not actively consuming CPU. The Images tab shows every downloaded image, including old versions you've since rebuilt and forgotten about; each one sits on disk and contributes to what Docker has to track. Cleaning these up with docker image prune -a (which removes all unused images, not just dangling ones) is more thorough than the basic prune command and worth running periodically if you've been developing against Docker for months without a cleanup pass.
When high memory use is actually fine
Not every instance of Docker Desktop showing several gigabytes is a problem worth chasing. If you're actively running a database container, a local Kubernetes cluster, or several interconnected services for development, that memory is doing real work and reducing it would mean reducing what you can actually run locally. The distinction worth making is between memory Docker is using for something you're currently doing, which is expected and fine, versus memory left over from containers, images, or the VM itself that nobody is actively using anymore, which is the part worth reclaiming.