If you work on macOS or Windows, you have spent the whole course running containers inside a Linux virtual machine without ever seeing it. Docker Desktop is that VM, plus a graphical interface and a handful of extras. This lesson opens the box: what is inside, why that explains why bind mounts are slow, what it genuinely adds, what it costs — including the small print of the license — and what alternatives you have on each system.

1. What Docker Desktop actually is
2. The architecture from the inside
3. Why bind mounts are slow
4. The VM and its resources
5. The virtual disk that grows and never shrinks
6. Windows: WSL 2 versus Hyper-V
7. macOS: Apple Silicon, Rosetta and VirtioFS
8. What the interface brings
9. Docker Scout, one-click Kubernetes and extensions
10. docker init, docker debug and dev containers
11. Licensing and cost
12. Alternatives to the desktop app
13. Recommendation by profile

Docker Desktop is not Docker. It is a bundle that contains, among other things:

The key point is in the first row: containers are a Linux kernel feature — namespaces and cgroups, exactly as you saw in 05-07. macOS and Windows do not have that kernel, so one has to be supplied. On Linux, Docker Desktop is optional precisely because the kernel is already there: docker talks directly to dockerd with no VM in between.

Anything that crosses the boundary between the host and the VM has a cost. And two things cross it constantly: the files of your bind mounts and the network packets of your published ports.

When you mount ./src:/app/src on Linux, nothing special happens: the container sees the very same host file system through the mount namespace. On macOS or Windows, every open(), every stat() and every read() travels from the container to the VM, from the VM to the host, and back.

There you have the reason behind a recommendation you will see everywhere and that you now understand: never put node_modules in a bind mount. Installing the aurora-api dependencies with the folder mounted from macOS can take minutes; with a named volume, seconds.

Measure it yourself, which is more convincing than any table:

The VM has a fixed size that you assigned to it, and everything your containers run competes inside it. When a docker compose up of Aurora Libros is slow for no obvious reason, this is the first place to look.

A frequent and confusing symptom: PostgreSQL dies with exit code 137 while importing the nine titles of the catalog. It is not a database failure, it is the OOM killer of the VM's kernel. If the VM has 2 GB and the containers ask for 3, somebody dies; raise it and the problem disappears.

The VM's disk is a sparse file on your host — Docker.raw on macOS, a .vhdx on Windows — that grows when you write and does not shrink when you delete. You can have 8 GB of images according to Docker and 90 GB taken up on your laptop.

Reclaiming space takes two steps, and the order matters:

The warning on the third command is serious: --volumes will take aurora-data with it if no container happens to be using it at that moment. The nine titles of the catalog vanish without a question being asked. Run docker volume ls first and, in general, prefer selective prune commands.

Distro integration is what makes daily work comfortable: in Settings → Resources → WSL Integration you enable your Ubuntu, and from its terminal the docker command works without installing anything inside it.

And the rule that will buy you the most performance on Windows: keep your code on the Linux file system, not on the Windows one.

The difference is not a nuance: an npm install for aurora-api can go from three minutes to twenty seconds just by moving the folder. If you need to edit from Windows, VS Code with the WSL extension opens the project remotely without taking the files out of Linux.

On a Mac with Apple Silicon, the VM is arm64. Your images are built and run natively on arm64, and everything is fast... until an image turns up that only exists for amd64.

Rosetta is enabled in Settings → General → Use Rosetta for x86/amd64 emulation and it improves the experience a lot, but it is not magic: some binaries fail, some CPU extensions are missing and some workloads remain slow.

That is why the multi-architecture work from module 5 was not academic. Your ghcr.io/auroralibros/aurora-api:2.0.0 is published for linux/amd64 and linux/arm64, so the Mac pulls the arm64 variant and the production server pulls the amd64 one, with no emulation on either side. That is the correct solution to the problem.

As for files, macOS uses VirtioFS with Apple's virtualization framework: it is noticeably faster than the old gRPC-FUSE, although it still does not reach native speed. Check that it is enabled in Settings → General → Choose file sharing implementation.

The GUI does nothing the CLI cannot do, but there are tasks where seeing is faster than typing.

The Builds panel is the most underrated: it tells you which step of the aurora-api Dockerfile is costing you the seconds and whether the cache hit or missed, which is exactly what you optimized blind in 05-04.

Docker Scout comes built in and analyzes local images:

It is convenient for a quick review on the desktop, but it does not replace scanning in the pipeline: what decides whether an image gets published is the Trivy step in your GitHub Actions (06-02), which runs without human intervention and fails the build. Scout is the early check; the pipeline is the gate.

One-click Kubernetes enables a single-node cluster inside the same VM.

Compared with kind, minikube or k3d (06-04), its advantage is that it is already there; its disadvantage is that it consumes memory from the same VM, and you cannot have several clusters or pick a version comfortably. To experiment with several versions or simulate several nodes, kind is still better.

Extensions add third-party tools to the dashboard (log viewers, database clients, disk managers). They are useful with one precaution: they are third-party code with access to your daemon. Install only the ones you need, and only from known sources.

docker init generates reasonable scaffolding: multi-stage, an unprivileged user and a .dockerignore. It is an excellent starting point and a poor finishing point: it does not pin the base image by digest, and it adds neither the three probes from 06-01 nor graceful shutdown. Use it to get going and apply what you know on top.

docker debug solves the classic problem of minimal images: when aurora-api:2.0.0 has neither sh nor curl, docker exec is of no use to you.

It installs nothing in the container and does not change the image: it mounts a set of utilities in a separate layer. It is the convenient alternative to the netshoot container you will see in 07-04, and it is a paid-subscription feature.

Finally, VS Code dev containers: a .devcontainer/devcontainer.json describes the complete environment — image, extensions, ports, commands — and the editor runs inside the container.

With this, somebody new to Aurora Libros clones the repository, opens VS Code and has Node 22, PostgreSQL 16 and Redis 7 running. It is the definitive answer to the fifteen manual onboarding steps the course started with in 01-07.

Docker Desktop is proprietary software with a commercial license, even though the Docker Engine it carries inside is open source. Under the terms in force in 2026:

The threshold has changed more than once since 2021, and the specific wording — what counts as an employee, whether it includes contractors, what happens within a group of companies — determines whether your organization has to pay.

Practical warning: do not install Docker Desktop on a corporate machine assuming it is free. Check the terms in force on the official website at the moment you install it and validate it with your company's legal or procurement department. There have been license audits with retroactive invoices, and the responsibility does not fall on whoever installed it, but on the company. If your company decides not to pay, the good news is that there are fully functional alternatives and none of them affects your images, which are standard OCI.

Notice the detail: all these alternatives integrate through Docker contexts, the mechanism from the previous lesson. And on all of them your images and your compose.yaml work without changes, because nothing you have built during the course depends on Docker Desktop.

The last row admits no nuance: on a server or a continuous integration runner you install Docker Engine, never Docker Desktop.

• Working from /mnt/c/... in WSL 2. It is the number one cause of slowness on Windows. Move the project to ~/ inside the distribution.
• Bind-mounting node_modules. Thousands of small files crossing the boundary. Use a named volume for that path.
• Being surprised by exit code 137. It is the VM's OOM killer. Raise the memory in Resources or set per-service limits.
• Believing that deleting images frees space on your laptop. The virtual disk does not shrink by itself: it has to be compacted or purged separately.
• Running docker system prune -a --volumes without looking. It takes aurora-data with it, and the nine titles along with it. Check docker volume ls first.
• Installing it at the company without checking the license. The terms change and audits happen. Verify, and consult legal or procurement.
• Using Docker Desktop's Kubernetes as if it were production. It is a single node: it tests neither availability, nor rescheduling, nor the real CNI.
• Tip: enable Rosetta on Apple Silicon, but solve the problem at the root by publishing multi-architecture images as you did in 05-05.
• Tip: check the Builds panel when a docker compose build gets slow. It will point at the guilty step in seconds.
• Tip: keep a .devcontainer/devcontainer.json in the repository. It turns onboarding into "clone and open".

Exercise 1 — Measure the boundary. Design and run a measurement that compares the time it takes to create 3,000 small files in three locations: a bind mount from a folder on your host, a named volume and the container's internal file system. Note the three times, work out the ratio and explain the result using the architecture from §2. If you are on Linux, explain why the three numbers look alike.

Exercise 2 — Space audit and recovery. Find out how much Docker takes up according to its own accounting and how much the virtual disk really takes up on your host. Explain the difference. Then free up space safely, leaving the aurora-data volume untouched, and check the result in both measurements. State which command would have destroyed the data and why.

Exercise 3 — Choosing a desktop tool. Aurora Libros grows to 14 developers: 6 on macOS with Apple Silicon, 5 on Windows and 3 on Linux. The company is above the free license threshold. Procurement asks whether 14 subscriptions have to be paid for. Prepare a recommendation with: what is actually needed on each system, which alternative you propose for each group, what is lost with each alternative, and which concrete questions have to be asked of legal before deciding.

Solution 1.

Typical results on a Mac with Apple Silicon and VirtioFS: the bind mount around 8-12 s, the named volume 0.6-1.2 s, the container layer 0.5-1 s. The bind mount ratio is around 10×. The explanation is the one from §2: every open(), write() and close() of the 3,000 files goes through the sharing layer between the VM and the host, and that is 9,000 round trips; the named volume lives inside the VM's disk and crosses nothing, just like the overlay2 writable layer (05-07).

On Linux the three numbers come out almost identical — tenths of a second — because there is no boundary to cross: the bind mount is the same file system seen from a different mount namespace. That is exactly why a colleague on Linux cannot reproduce your slowness problem, and why the solution is not "get a better laptop" but move the files to the right side of the boundary.

Solution 2.

The difference is that the virtual disk is a sparse file that grows as you write and never shrinks when you delete: when you remove an image, the blocks become free inside the VM but the file keeps reserving that size on your laptop.

The destructive command is docker system prune -a --volumes: the --volumes option includes volumes with no container attached at all, and if aurora-db happens to be stopped at that moment, aurora-data gets caught in the sweep and the nine titles of the catalog disappear without any per-volume confirmation. As a safety net, run docker run --rm -v aurora-data:/v -v "$PWD":/b alpine tar czf /b/aurora-data.tgz -C /v . before any aggressive cleanup — exactly the backup pattern from 05-02.

Solution 3. Recommendation by group:

Analysis: of the 14 licenses, 3 are unnecessary straight away because on Linux Docker Desktop adds nothing. On macOS, Colima covers the whole case with the usual CLI and the same contexts; what you lose are desktop features the team probably uses very little, and it is worth asking before deciding for them. Windows is where WSL 2 integration has the most real value, so there it may be worth paying for a few licenses instead of forcing an alternative. A reasonable middle way: 5 licenses for Windows and free alternatives on macOS and Linux, to be reviewed in six months.

Questions for legal and procurement before deciding anything: what exactly do the terms in force say about the threshold, and do we count total employees or only developers?; do external contractors and subsidiaries count within the group?; is there already a framework agreement with Docker, or a subscription contract for another product that covers this? Add a fourth, internal question, which is often the one that settles the debate: which specific Docker Desktop features does the team genuinely use every week? If the answer is "starting Compose and looking at logs", the decision makes itself.

You now know what that VM you had been using without seeing it is. Docker Desktop is not Docker: it is a Linux virtual machine with dockerd inside, plus a GUI, plugins and extras, and it exists because containers are a Linux kernel feature that macOS and Windows do not have. On Linux it is optional for exactly that reason.

Everything else follows from that architecture. You understand why bind mounts are between 2 and 30 times slower depending on the system and the protocol, why node_modules must live in a named volume, and why on WSL 2 moving the project from /mnt/c/... to ~/ can turn three minutes into twenty seconds. You know how to size the VM, how to diagnose exit code 137 for what it is — the OOM killer, not a PostgreSQL bug — and how to reclaim space at both levels, with the warning that --volumes takes aurora-data without asking.

You know the terrain of each system: WSL 2 versus Hyper-V and distro integration on Windows; Apple Silicon, Rosetta and VirtioFS on macOS, with the realization that the multi-architecture work from 05-05 is the root solution to the emulation problem. And you know what the tool genuinely brings: the Builds panel with duration per step, Scout as an early check that does not replace pipeline scanning, one-click Kubernetes with its honest limits, docker init as a good starting point and a poor finishing point, docker debug for images with no shell, and dev containers as the definitive answer to the fifteen onboarding steps from 01-07.

And you take away what is not technical: it is proprietary software with license thresholds that have changed several times, so you check them on the official website and validate them with legal or procurement before installing it at the company. If the answer is that nobody is paying, you have the table of alternatives — native Engine, Rancher, Podman Desktop, Colima, OrbStack, lima — all integrated through contexts and all running your images without changing a line, because nothing you have built depends on Docker Desktop.

In the next lesson we leave the desktop to equip the workflow: the third-party tools and plugins that surround Docker in a real project. How CLI extensibility works — you will build your own docker aurora — what is worth having in interfaces, inspection, security, private registries, development and alternative builders, and what criteria you use to decide whether to adopt a tool or leave it out.