When Docker Desktop Is the Wrong Tool

Docker Desktop is a very good developer tool, and this whole course was written with it. But it is a developer tool. It is a desktop app that runs a Linux virtual machine for you, adds conveniences that a server does not have, and comes with licence terms that depend on the size of your company. Using it where it doesn't belong does not fail loudly. It fails as "works on my machine", as a server that stops when someone logs out, or as an invoice. This lesson is about knowing where that line is.

Everything shown was run on Docker Desktop 4.85.0 with Engine 29.6.2 on Windows 11 with the WSL 2 backend.

What you are actually running

Ask the engine what it is:

docker version --format "client {{.Client.Version}}, server {{.Server.Version}}, platform: {{.Server.Platform.Name}}"
docker info --format "{{.OperatingSystem}} | kernel {{.KernelVersion}} | {{.Architecture}}"
docker run --rm alpine:3.24 uname -r

client 29.6.2, server 29.6.2, platform: Docker Desktop 4.85.0 (235549)
Docker Desktop | kernel 6.6.87.2-microsoft-standard-WSL2 | x86_64
6.6.87.2-microsoft-standard-WSL2

The engine is a Linux engine inside a small VM that Docker Desktop manages, on a kernel built by Microsoft for WSL 2. Your containers share that kernel, not the one your production server runs. Most of the time the difference does not matter. When it does, it is a kernel feature, a file system detail or a network behaviour, and you find out in production.

Things that work on Desktop and not on a server

Docker Desktop adds a few conveniences. The best known is the name host.docker.internal, which points from a container back to your Windows machine:

docker run --rm alpine:3.24 sh -c "getent hosts host.docker.internal > /dev/null && echo host.docker.internal resolves"
docker run --rm --add-host probe.internal:host-gateway alpine:3.24 sh -c "getent hosts probe.internal > /dev/null && echo host-gateway works"

host.docker.internal resolves
host-gateway works

On Docker Desktop, the first line works without any setup. On Docker Engine on Linux, that name does not exist unless you add it with --add-host host.docker.internal:host-gateway, which is what the second line shows with a different name. If your Compose file relies on host.docker.internal without that line, it works on every laptop and breaks on the server.

Other differences that I see people trip on:

• Published ports. Desktop forwards them from Windows into the VM. On a Linux server, Docker writes firewall rules directly, and a published port can bypass a host firewall like ufw that you thought was protecting it. Bind to 127.0.0.1 unless the port must be public.
• Bind mounts. Files from C: go through a file sharing layer, with Windows-style permissions that look loose from inside. On Linux, the owner numbers are real, and the permission errors from the Intermediate course show up.
• Resource limits. On Desktop all containers share what WSL 2 gives the VM. On a server they share the whole machine, and the limits from the "Running Under Load" lesson are the only thing between one container and the rest.

Where Desktop is the wrong tool

Servers. Docker Desktop is an app that runs in a user's session. It is not meant to be a Windows service that runs your production containers with nobody logged in. On a server, install Docker Engine on Linux. It starts with the system, has no GUI and no extra VM, and it is the setup that the official docs and every hosting guide assume. From your laptop, you can still control it with a Docker context over SSH, for example docker context create prod --docker "host=ssh://deploy@server.example.com". I did not create a remote context for this lesson.

CI runners. Hosted CI runners already have Docker Engine. On a self-hosted Linux runner, install Engine. Desktop in CI adds a VM and a GUI app that nobody looks at.

Larger companies without a subscription. According to Docker's documentation, checked in October 2026, Docker Desktop is free for personal use, education, non-commercial open-source projects and small businesses with fewer than 250 employees and less than 10 million US dollars in annual revenue. Professional use above either limit, and use by government entities, needs a paid Pro, Team or Business subscription. Docker Engine itself is open source and has no such terms. This is a summary, not legal advice, and the terms change, so check Docker's current licence page before you decide.

Measuring performance. Timings on Desktop include the VM and, for bind mounts, the Windows file sharing layer. If you are tuning a service for production, measure on a Linux machine that looks like production.

Where Desktop is the right tool

On a Windows or Mac developer machine, for learning, and for teams that fit the licence terms, it is hard to beat: one installer, the VM managed for you, Compose and BuildKit included, updates in one place. I would not tell a beginner on Windows to set up Docker Engine inside a WSL distro by hand. I would tell a team that runs production on a Desktop install to stop.

There are other options for developer machines too. Docker Engine installed inside your own WSL 2 distribution, Rancher Desktop and Podman Desktop all exist. I did not test any of them for this course, so I only mention them. If you switch, run the examples from this course again on the new setup. Small differences show up exactly in the areas listed above.

Common mistakes

• Using host.docker.internal in a production Compose file.
• Testing a firewall setup on Desktop and assuming the server behaves the same.
• Assuming Docker Desktop's terms are the same as Docker Engine's. They are different products with different licences.

If your laptop died tonight, would anything in production stop working with it?