Installing Docker (without selling your soul to Desktop)

Posted on March 26, 2026  •  10 minutes  • 1989 words

There’s a moment in every tech career when someone tells you: “install Docker Desktop, next step.” You comply, reboot, accept three EULAs without reading them, and after a while your laptop sounds like a jet engine and Docker Desktop decides to eat more RAM than your IDE, your open Chrome tabs, and all your unresolved trauma combined.

Then you go back to the fine print and discover that, past a certain company size, Docker Desktop isn’t even free: you need an enterprise license . Perfectly fair, but not always feasible — and that’s when the quest begins: “I want Docker, but I don’t want another giant thing running in the background all day.”

The good news: in 2026, you don’t have to marry Docker Desktop to do serious development.

On Windows you can use Docker CE inside WSL2, and on macOS you can get a decent Docker environment using Colima (which relies on Lima and QEMU, no official app required). And if you miss having a GUI to poke at containers, you can spin up a Portainer instance and manage everything from your browser like you’re the SRE of a data center… without paying for yet another license.

Sounds pretty good, right?

Context: Docker Desktop is fine… but it’s not free or lightweight

Docker doesn’t run natively on Windows or Mac. It needs Linux under the hood: Docker Desktop bundles a Linux VM, the Docker daemon, a nice interface, system integration, and a bunch of extras. All convenient, all in a single app.

But convenience has a price:

• Licensing: medium and large companies need a paid subscription to use it legally.
• Resources: that VM is always lurking around, eating RAM, CPU, and occasionally deciding to crash at the worst possible moment.

That’s why there’s so much best-practices literature around Docker Desktop + WSL2 where Docker itself begs you to limit resources, use WSL, keep your projects out of the slow folders… And that’s also why leaner alternatives have flourished: running Docker CE directly on Linux (in our case, WSL2) or on a lightweight VM like Colima on Mac.

The basic idea is simple:

• On Windows, you let WSL2 be your Linux and install Docker there, just like you would on any server.
• On Mac, you let Colima/Lima manage a minimal Linux VM and install Docker CE there too.

Docker Desktop becomes an option, not a requirement.

Docker CE on WSL2: running “real” Docker in your Linux inside Windows

If you already have WSL2 set up (for example with Ubuntu, as we covered in the previous tutorial), the idea is to treat it like a regular Ubuntu server : that’s where Docker CE goes.

Installing Docker CE inside the WSL2 distro

Open your Ubuntu on WSL2 and roughly follow Docker’s official recipe for Ubuntu (adapted to the current docs):

1. Update packages:

sudo apt update && sudo apt upgrade

2. Install dependencies for HTTPS repositories:

sudo apt install ca-certificates curl gnupg lsb-release

3. Add Docker’s GPG key and repo (typical example):

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

4. Install Docker CE and friends:

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io

5. Add your user to the docker group so you don’t have to sudo everything:

sudo usermod -aG docker $USER

Close and reopen your WSL session, or run wsl --shutdown from Windows and reopen Ubuntu so the group change takes effect.

Verify:

docker version
docker run hello-world

If that works, you’ve got Docker running inside your Linux on WSL2, with no Docker Desktop in the middle. In practice, it’s the same setup you’d have on a cloud server or on-prem.

Auto-starting Docker and coexisting with Windows

By default, the Docker service inside WSL tends not to start on its own.

To avoid having to run sudo service docker start manually every time, you can use the /etc/wsl.conf file we covered in the previous tutorial:

sudo nano /etc/wsl.conf

And add:

[boot]
command = service docker start

Shut down WSL:

wsl --shutdown

and the next time you open Ubuntu, the Docker service will start automatically.

As for ports, think of it this way:

• If you spin up a container on WSL2 with docker run -p 8080:80 ..., from inside WSL you access it at http://localhost:8080.
• From Windows, since WSL2 is integrated into the host network, you can usually also access http://localhost:8080 directly, thanks to WSL2’s automatic port forwarding.

In more unusual setups (aggressive firewalls, exotic ports), you might need to fiddle with firewall rules or check WSL’s internal IP (ip addr) and connect to http://<wsl-ip>:8080, but for the vast majority of “local development” use cases, the shared localhost works just fine.

Docker on macOS with Colima: lightweight Linux without Desktop

On macOS the problem is similar to Windows: Docker Desktop gives you everything in one package, but with licenses and excessive resource consumption.

The alternative is Colima, which spins up a lightweight Linux VM using Lima (and QEMU under the hood), and on that VM you install/run Docker or containerd.

The typical setup these days goes something like this:

1. Install Homebrew if you don’t have it (I’m not going to repeat the magic command, but you know the one: /bin/bash -c "...brew...").
2. Install Colima and the Docker CLI:

brew install colima docker

3. Start Colima:

colima start

Colima creates and boots a minimal Linux VM with container support. In most configurations, it leaves you with a Docker environment that feels “native”: the docker CLI you installed via Homebrew talks to the daemon in Colima’s VM.

Verify:

docker version
docker run hello-world

If it works, you’ve got Docker up and running… without Docker Desktop. If you want more control, Colima accepts profiles (CPU, RAM, etc.) in its config, but that’s fine-tuning territory.

What about ports? Colima, like Docker Desktop, does port forwarding from the VM to the host. A docker run -p 8080:80 ... gives you a service accessible on your Mac at http://localhost:8080 with no extra setup. For the typical web development and API workflow, that’s more than enough.

“I miss the pretty buttons”: enter Portainer (or another web panel)

One thing a lot of people appreciate about Docker Desktop is the visual dashboard: seeing containers, images, networks, logs — all with clicks. Without the official app, you’re “stuck” with the CLI… unless you set up a web panel yourself.

That’s where Portainer comes in. It’s been the de facto “Docker control panel” for years: a lightweight web app that deploys as a container and lets you manage Docker (and even clusters) from your browser.

The usual approach, on both WSL2 and Colima, is to spin up a container to get yourself a control panel:

docker volume create portainer_data

docker run -d \
  -p 9443:9443 \
  --name portainer \
  --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:latest

Then go to https://localhost:9443 (on Windows: the host browser; on Mac: same) and follow the setup wizard.

Portainer hooks into the host’s Docker socket (the one from WSL or Colima) and gives you a list of containers, logs, stats, image management, networks, volumes, and basic RBAC and authentication if you need it.

It’s not as “native” as Docker Desktop’s panel, but it comes with one key upside: you decide where it runs and it doesn’t add another heavy layer to your system. If you don’t want a GUI one day, just stop the container and you’re done.

Important note about ports and the Windows-WSL2 boundary

I mentioned this earlier, but it deserves its own subsection: there are multiple networks involved in WSL2. Typically:

• WSL2 creates a sort of VM with an internal IP (something like 172.x.y.z).
• Windows acts as the host and usually maps ports automatically so that localhost on Windows reaches services listening on 0.0.0.0 inside WSL2.

In practice, for local development, this is usually enough:

• In WSL2: docker run -p 8000:8000 myimage with your service on 0.0.0.0:8000.
• On Windows: http://localhost:8000 in the browser.

If something doesn’t work, check the following:

• Make sure the container is listening on 0.0.0.0, not just 127.0.0.1.
• Check your WSL IP with ip addr and try http://that-ip:8000.
• Verify that no firewall is blocking traffic between the host and the WSL interface.

For more advanced scenarios (exposing WSL services to external networks, setting up reverse proxies on Windows pointing to WSL, etc.) you’d be getting into Nginx/Traefik/iptables territory, but for the “browser <-> local API” cycle, WSL2 behaves reasonably well out of the box.

What if I still want Docker Desktop?

None of this is an “anti-Docker Desktop” manifesto. The company itself still recommends its app for people who need tight system integration, built-in Kubernetes, easy updates, and so on. It’s a solid solution that, when properly configured, is genuinely useful.

What I want you to take away from this tutorial is, above all, that you have choices. That if Docker Desktop’s licensing model doesn’t fit your company, you’re not stuck. That if the app eats your resources or crashes more than you’d like, you can let WSL2 or Colima do the heavy lifting without that extra layer. And that if you miss a nice panel where you can click on things, Portainer is just a docker run away and runs on your own Docker, no additional subscription required.

At the end of the day, you can have a complete, modern, and pretty lightweight Docker environment on both Windows and macOS without selling your soul to a single desktop application.

And if one day you feel like going back to Docker Desktop, you’re always just one install away; the important thing is that it’s your call, not something you went with just because everyone else did.

Quick glossary

In case your boss asks what you just installed and you need to sound convincing.

• Docker CE (Community Edition): the free, open-source version of the Docker engine. It’s the daemon that actually runs containers, without the GUI or the integrations that come with Docker Desktop.
• WSL2 (Windows Subsystem for Linux 2): a Microsoft compatibility layer that runs a real Linux kernel inside Windows, with near-native performance.
• Colima: an open-source tool for macOS that spins up a lightweight Linux VM (based on Lima) where you can run Docker without needing Docker Desktop.
• Lima / QEMU: Lima manages Linux VMs on macOS; QEMU is the emulator/virtualizer it uses under the hood to create those VMs.
• containerd: the low-level container runtime that Docker uses internally to manage the container lifecycle (create, run, stop, remove).
• EULA (End User License Agreement): the end-user license agreement you accept (without reading) when you install software.
• Portainer: a web application deployed as a container that provides a graphical panel for managing Docker, its images, networks, and volumes from the browser.
• Port forwarding: the mechanism that allows a service listening on a port inside a VM or container to be accessible from the host system.
• RBAC (Role-Based Access Control): a permissions model where capabilities are assigned to roles and users inherit those permissions based on their role.
• Docker socket (/var/run/docker.sock): a special Unix file that acts as a communication channel with the Docker daemon. Tools like Portainer hook into it to send commands to the container engine without needing to open network ports.

Sources and references

Official docs, Docker blog posts, and a couple of WSL resources. No sketchy YouTube videos, I promise.

• Docker Desktop WSL 2 Best Practices - Docker Docs. Official best practices for Docker Desktop with WSL2, including licensing info.
• Docker Desktop WSL 2 Best Practices (Blog) - Docker Blog. Article on optimizing Docker Desktop with WSL2.
• Unleashing Linux on Windows: A Developer’s Guide to WSL2 - Van Falchi. Developer guide on WSL2 workflows.
• Official Microsoft docs: install WSL - Microsoft Learn. Official WSL installation guide.
• Setting Up WSL on Windows 11 - OreateAI Blog. Detailed WSL setup guide for Windows 11.
• Manual WSL installation - Microsoft Learn. Manual steps and advanced WSL configuration.