Updated on June 30, 2026 in #docker, #linux

Install Docker on Arch Linux with and Without Docker Desktop

You don't have to miss out on Docker Desktop features on Linux, it's pretty painless to install either the CLI or Docker Desktop.

Prefer video? Here it is on YouTube.

On native Linux you technically don’t need Docker Desktop to run Linux containers but depending on what your preferences are and what Docker features you’re interested in, IMO it’s very much worth looking into!

# Should You Use Docker Desktop on Linux?

Docker Desktop is more than just an optional GUI to interact with Docker’s resources such as images, containers, volumes and more. Docker Desktop has evolved a lot since it was released in 2016 (for Windows and Mac).

Nowadays, Docker Desktop has a bunch of features and it’s improving all the time.

At the time of this post (mid-2026), the full version of Docker Gordon (AI) is an exclusive feature of Docker Desktop, so if you like getting assistance around Docker concepts and commands from the comfort of Docker Desktop or the CLI that’s something to consider. In this case, the CLI depends on Docker Desktop being available.

Technically Gordon is available to use on Docker’s website which you may see going through the docs or the Docker Hub but this doesn’t expose all of the same features that the Docker Desktop version has.

In practice I find that Docker often introduces features for Docker Desktop first. Over the years a number of features started off as being for Docker Desktop but then were split out and made independent to work without it.

With that said, on Arch Linux, if you want to use most of Docker’s offerings (stable, beta or experimental features), I’d highly suggest Docker Desktop because while you can technically run most other things without it, it’s more painful to get set up. You’ll find yourself either tracking down dependencies and running scripts or hunting around the AUR to help pull everything together.

One benefit of using Docker Desktop is you install it once and it facilitates installing and managing these Docker features and plugins. It’s nice to be able to set it and forget it, and not have to think about missing out on features that Docker is releasing.

What Do I Do?

I personally use both.

I have a laptop and desktop both using Arch Linux with the same dotfiles minus a few configuration details that are machine specific.

On my laptop I have Docker Desktop and on my desktop I use the CLI version. This lets me use Docker’s latest and greatest features without worry. I have the same Docker projects synced between both devices and it’s no problem to run them without adjustments.

Btw, if you’re using DotFriedRice (my dotfiles), it’s easy to get going with either solution. Out of the box it comes with the CLI version but switching to Docker Desktop is painless, I’ll add a callout for that later.

Is the Extra VM Resource Hungry or Slow?

Not really!

The KVM backed VM uses about 1 GB of memory and ~5 GB of disk space. These are unofficial measurements I discovered when looking at btop and certain directories.

It uses dynamic CPU, memory and disk allocation as well. In other words, if you’re not running anything then it’s not pre-allocating a bunch of resources. For example, you might give Docker Desktop 4 CPU cores and up to 8 GB of memory but it won’t use those resources until you’re running containers that use it.

The ~5 GB disk space of appears to be for the VM’s OS. I verified this number by running qemu-img info ~/.docker/desktop/vms/0/data/Docker.raw after doing a full docker system prune --all --volumes. I’m not sure if there’s a better way to check, but the disk itself can grow in size based on what you have configured in Docker Desktop’s resource settings.

Those resource settings act as an upper limit for when Docker needs to allocate system resources to your containers.

Real-world benchmarks

Even on my desktop machine from 2014 I don’t notice any real run-time performance differences when using it on real projects. I haven’t run micro benchmarks to confirm that because it was never slow enough for me to investigate.

My blog uses Hugo (static site generator) and I have esbuild along with Hugo running in Docker while using Docker Compose. It has over 1,000 posts with drafts and thousands of assets (images, etc.). Building the site is quite CPU intensive and involves volume mounting thousands of files. It’s a worst case scenario.

For reference, my laptop’s specs are:

╭─󰍛 : AMD Ryzen 7 6800H (16) @ 4.79 GHz
├─ : 5.57 GiB / 30.58 GiB (18%)
├─ : Radeon 680M (512.00 MiB)
├─󰍹 : 1920x1080 in 15", 60 Hz [Built-in]
├─ : 36.98 GiB / 914.82 GiB (4%) - ext4
╰─󰾵 : 0 B / 4.00 GiB (0%)

╭─ : nick@nimo
├─ : Arch Linux
├─ : Linux 7.0.13-arch1-1
╰─󰏖 : 1075 (pacman)

╭─󱠶 : DotFriedRice
├─ : niri 26.04 (Wayland)
├─ : tmux 3.6b
╰─ : zsh 5.9.1

╭─󰔛  Uptime: 2 hours, 17 mins
╰─  OS Age: 37 days (2026-05-19)

On my laptop with Docker Desktop:

• Static CSS / JS assets get fully built in ~600ms (esbuild)
• The entire site gets fully built in ~3.8 seconds (hugo)
• Modifying a post incrementally rebuilds the site in ~350ms

On my laptop without Docker Desktop:

• Static CSS / JS assets get fully built in ~550ms (esbuild)
• The entire site gets fully built in ~2 seconds (hugo)
• Modifying a post incrementally rebuilds the site in ~115ms

These times are printed by each process when you run them, it’s straight from the source.

After looking at the above you might think Docker Desktop is way worse. On paper it is twice as slow in some spots but in practice it makes close to zero difference in my day to day. I do a full site rebuild a few times a week.

Keep in mind, this slowness we’re seeing isn’t because Docker Desktop is poorly coded. This is the VM tax. KVM is a type-1 hypervisor and has direct access to your hardware but it and Docker Desktop still need to facilitate sharing files from your host into the VM. A full site rebuild is twice as slow mainly because of disk I/O.

If you have a massive project where you’re constantly running heavy disk operations perhaps that’s something to consider but I have a hunch for most workloads this is one of those situations where it’s “fast enough”.

My desktop has much worse hardware which is why I used the laptop for benchmarks:

╭─󰍛  : Intel(R) Core(TM) i5-4460 (4) @ 3.40 GHz
├─ : 5.30 GiB / 15.55 GiB (34%)
├─ : Radeon RX 470/480/570/570X/580/580X/590 (8.00 GiB)
├─󰍹 : 3840x2160 in 32", 60 Hz [External]
├─󰍹 : 2560x1440 in 25", 60 Hz [External]
├─ : 103.03 GiB / 232.69 GiB (44%) - ext4
├─ : 907.05 GiB / 931.48 GiB (97%) - fuseblk
├─ : 907.92 GiB / 931.51 GiB (97%) - fuseblk
╰─󰾵 : 430.44 MiB / 4.00 GiB (11%)

╭─ : nick@kaizen
├─ : Arch Linux
├─ : Linux 7.0.12-arch1-1
╰─󰏖 : 1138 (pacman)

╭─󱠶 : DotFriedRice
├─ : niri 26.04 (Wayland)
├─ : tmux 3.6b
╰─ : zsh 5.9.1

╭─󰔛  Uptime: 8 days, 5 hours, 30 mins
╰─  OS Age: 186 days (2025-12-21)

For reference, on my desktop without Docker Desktop:

• Static CSS / JS assets get fully built in ~650ms (esbuild)
• The entire site gets fully built in ~3.6 seconds (hugo)
• Modifying a post incrementally rebuilds the site in ~120ms

Given how long it takes to do a full rebuild when Docker Desktop (KVM) isn’t involved, that indicates once VM disk I/O bottlenecks are reduced I’m quite CPU bound which I am. The desktop’s CPU has 4 physical cores and no hyper-threading. The laptop has 8 physical cores and 16 logic cores.

It’s also worth pointing out the laptop has an NVME SSD where as the desktop has a first gen SATA SSD from 2014. Disk I/O is still quite good on both machines but this is certainly a task that’s disk heavy in general.

People ask me all the time why I don’t buy a new desktop computer. It’s because it doesn’t feel slow, truly, I’m not lying. It runs very well for a bunch of Docker based workloads and many other things (video editing, media creation, light gaming, etc.).

# CLI: Docker Engine and Docker Compose

We’ll use the official Arch repository Docker package and a few popular plugins:

# Install Docker, BuildX and Compose
sudo pacman -Syu docker docker-buildx docker-compose

# Allow your user to run Docker commands without root access
sudo usermod -aG docker $USER

# Ensure the Docker daemon is started and starts on boot
sudo systemctl enable --now docker.service

You’ll want to log out and log back in so the group setting takes effect. You can technically skip that by running newgrp docker in your current terminal session if you want to use Docker right now without logging out of your desktop environment.

Both BuildX and Compose are Docker plugins and on Arch Linux it’s common not to bundle 3rd party binaries in another package if they can be released separately.

Verify everything works by running:

• docker container run --rm hello-world
• docker buildx version
• docker compose version

You’re all set to run an assortment of Docker / Docker Compose projects!

# Docker Desktop

If you want to use all of Docker’s features, here we go.

Cleaning Up Docker Engine / Docker Compose

If you already have Docker Engine and Docker Compose installed you’ll need to at least remove docker-buildx and docker-compose, you can do that with:

sudo pacman -Rns docker-buildx docker-compose

Technically if you’re using most AUR helpers (yay, paru, etc.) they will offer to remove these conflicting packages but it’s a good idea to know what’s happening behind the scenes.

You can keep the docker package and have Docker continue to run independent of Docker Desktop. That’s because when you use the docker CLI Docker Desktop sets up a separate context so it uses the VM’s Docker Engine instead of your main system’s Docker Engine.

In fact, Docker Desktop will install the docker package for the CLI which is why we’re not removing it now, otherwise it will get re-installed anyways.

However, since you can’t have the Docker Compose package installed at the same time, I wouldn’t suggest keeping the Docker service running. You can but it will likely remain unused since Docker Desktop runs the Docker daemon in the VM.

The above is just a general guideline btw. If you do have super disk heavy operations that’s not using Docker Compose and you find yourself not wanting to use Docker Desktop for that but you want Docker Desktop for everything else then by all means please keep both, it’ll work nicely!

Stop and disable the Docker service with:

sudo systemctl disable --now docker.service docker.socket containerd.service

Now you have a decision point. Do you want to keep around your old images and volumes?

If you don’t want to keep them you can permanently delete your old images, volumes and all of Docker’s data files by running sudo rm -rf /var/lib/docker /var/lib/containerd.

Everything of substance has been removed and you’re ready to install Docker Desktop.

Install Docker Desktop

We’ll use the AUR to install Docker Desktop but don’t worry, it’s maintained by Docker. If using the AUR is out of the question for you that’s ok you can download and build the package directly with a few commands as pointed out in Docker’s documentation.

We’ll use the officially maintained Docker Desktop AUR package:

# Install Docker Desktop, feel free to use paru instead if you have it
yay -S docker-desktop

# Allow your user to run Docker commands without root access
sudo usermod -aG docker $USER

# Ensure Docker Desktop is started and starts on boot
sudo systemctl enable --now docker-desktop.service

If you encounter issues installing or starting Docker Desktop, make sure your system meets all of Docker Desktop’s requirements.

Right after installing Docker Desktop, it will pop up to ask you to agree to the terms of service, you can do that. Also it will ask you if you want to sign into Docker Desktop. Skip that for now, we’ll sign in together soon.

You can open it like any desktop application (search for “Docker Desktop”). If your status bar supports it it’ll get shown there. If you’re using Waybar with hidden icons, you’ll find a Docker icon tucked away in there.

Verify everything works by running:

• docker container run --rm hello-world
• docker buildx version
• docker compose version

Signing into Docker Desktop

If you plan to sign into Docker Desktop, it uses a GPG key along with the pass tool (installed by Docker Desktop) to store your credentials. This is something you only need to set up once and if you already use pass then you can skip this step.

If you don’t have a GPG key, here’s a post going over how to set one up. If your GPG key’s email address is different than your Docker Hub email that’s fine, these are separate things.

Once you have your GPG key, you can run pass init YOUR_GPG_EMAIL to set up your password store. If you happen to have multiple GPG keys assigned to the same email address you can run this command and get your public key ID to use instead:

$ gpg --list-keys nick.janetakis@gmail.com
pub   rsa3072 2025-12-21 [SCEAR] [expires: 2026-12-21]
      958E285350CCF8C0FCD2A9CF0968CF2437AA77F0
uid           [ultimate] Nick Janetakis <nick.janetakis@gmail.com>
sub   rsa3072 2025-12-21 [SEA] [expires: 2026-12-21]

In the above example that would be 958E285350CCF8C0FCD2A9CF0968CF2437AA77F0 and you can run pass init YOUR_PUB_KEY_ID instead to initialize the store.

Now you can sign in by running docker login from the terminal, press enter when it asks and check your browser.

Did the login command work?

If you’re already logged into the Docker Hub in your browser you should be good to go. If not, you can enter your Docker Hub email and password or create a new account if you don’t have an account yet.

In the end it should say “Login Succeeded” in the terminal.

After that you can go back to Docker Desktop and click the “Sign in” button which should log you in without prompting you for more additional information.

Did you get a GPG error?

The error might end with:

[stdin]: encryption failed: Unusable public keyPassword encryption aborted

That’s because the trust level of your key might not be set to “ultimate”. If you run gpg --list-keys YOUR_GPG_EMAIL, next to the uid line if it says [unknown] or anything other than [ultimate] that is the problem.

If you were to use GPG to generate a key today it will be “ultimate” by default. Perhaps you made a manual adjustment or generated a key a very long time ago.

You can resolve that by running:

• gpg --edit-key YOUR_GPG_EMAIL to enter the GPG edit screen for your key
• Type trust and hit enter
• Choose option 5
• Press y to agree and save
• Type quit to go back to your terminal prompt

Once you’ve addressed the above you can follow the steps above here in the “Did the login command work?” section to sign into Docker Desktop.

Docker Desktop Settings

Under resources you can allocate CPU, memory and disk for the VM. On my machine it allowed all of my CPU cores, 25% (8 GB) of memory and all of my disk by default. If you want to allocate more or less, that’s where to go.

There’s other settings to explore at your discretion.

DotFriedRice Configuration

If you’re using DotFriedRice most of everything we’ve covered isn’t necessary to do since it’s automated for you.

With no customization Docker Engine, BuildX and Docker Compose are installed by default, your user is configured to be in the Docker group and Docker automatically starts on boot. This gives you a fully working CLI solution to run Docker and Docker Compose projects.

If you want to use Docker Desktop instead you can set these in your config:

export PACKAGES_PACMAN_GUI_SKIP=("docker-buildx" "docker-compose")

export PACKAGES_AUR_GUI_EXTRAS=("docker-desktop")

Then you can run dotfriedrice like usual to update your system.

The above skips installing both conflicting packages. The yay package manager will handle removing the conflicting packages at install time for Docker Desktop. It will take a few minutes to install.

When Docker Desktop is detected, it will automatically handle:

• Disabling the Docker service
• Init the password store since DotFriedRice sets up a GPG key independent of Docker

It won’t prune or delete any old non-Docker Desktop directories, that’s up to you since that’s a very personal decision!

Switching from Docker Desktop to the CLI Version

Now to bring things back full circle, if you happened to want to switch back to using the CLI version, it’s an easy adjustment.

You can run yay -Rns docker-desktop to remove Docker Desktop. You can also rm -rf ~/.cache/yay/docker-desktop which will reclaim ~1.3 GB since the package itself is pretty big.

Then you can run sudo pacman -Syu docker docker-buildx docker-compose to get your CLI focused Docker set up back in action, as well as start it now and on boot with sudo systemctl enable --now docker.service.

After that, we’ll want to modify your user’s Docker config to prevent an error. In ~/.docker/config you can delete this line "credsStore": "desktop",, followed by running docker logout from your terminal.

If you skip deleting that line and logging out, when you run Docker commands that access the Docker Hub (even public images) you’ll likely see errors around getting credentials related to docker-credential-desktop.

For example:

$ docker container run --rm nginx
Unable to find image 'nginx:latest' locally
docker: error getting credentials - err: exec: "docker-credential-desktop": executable file not found in $PATH, out: ``

Run 'docker run --help' for more information

After doing the above steps you’ll be good to go and it will run successfully.

Next up, if you don’t use pass normally you can delete the password store with your encrypted Docker Hub credentials by running rm -rf ~/.config/password-store or rm -rf ~/.password-store depending on where you have it installed.

Lastly, if you want to delete the VM’s disk(s) and other Docker Desktop related files you can run rm -rf ~/.docker/desktop. This will reclaim quite a few gigs of space!

The video below demos most of the above.

# Demo Video

Timestamps

• 0:34 – Should you use Docker Desktop on Linux?
• 2:51 – I use both Docker Desktop and native Docker
• 3:57 – Performance differences and benchmarks
• 11:46 – Installing the CLI version of Docker and Docker Compose
• 14:34 – Cleaning up the CLI version before installing Docker Desktop
• 19:07 – Installing Docker Desktop
• 24:22 – Signing into Docker Desktop (GPG key)
• 25:51 – Fixing GPG key issues and signing in
• 27:45 – Docker Desktop settings
• 28:43 – DotFriedRice helps you install Docker
• 30:41 – Switching from Docker Desktop to the CLI version

How have you installed Docker on Arch? Let me know below.