✦ For everyone, free.

Practical knowledge for real and everyday life

Home

18.1.1.5 Desktop GUI Control

A focused guide to Desktop GUI Control, connecting core concepts with practical Docker and container operations.

Desktop GUI control covers the actual dashboard interface Docker Desktop provides for managing containers, images, and volumes interactively, which mirrors the same underlying CLI commands but offers a visual, point-and-click alternative particularly useful for quick inspection and routine operations without needing to recall exact command syntax.

The container list as a live, interactive view

The Dashboard's container list shows every container's current status, resource usage, and exposed ports at a glance, with direct controls to start, stop, restart, or remove a container without typing the equivalent CLI command:

docker stop my-api
docker start my-api
docker rm my-api

Each of these actions is available as a direct button click within the Dashboard's container list, which is functionally equivalent to running the corresponding CLI command but considerably faster for an occasional, ad hoc action where remembering or typing the exact command would be unnecessary friction.

Viewing logs directly within the interface

Selecting a specific container within the Dashboard opens a live, scrolling log view equivalent to running docker logs -f against that container, without needing to open a separate terminal session or remember the container's exact name:

docker logs -f my-api

The GUI log viewer additionally supports basic text search and filtering directly within the interface, which can be more convenient for a quick, visual scan through recent output than piping CLI log output through a separate search tool.

Opening an interactive terminal session from the GUI

The Dashboard provides a direct way to open an interactive shell session inside a running container, equivalent to docker exec -it, without needing to switch to a terminal application and type the container's name or ID manually:

docker exec -it my-api sh

This is particularly convenient when already working within the Dashboard for other reasons, removing the context switch to a separate terminal window that would otherwise be needed for a quick, exploratory check inside a running container.

Managing images and volumes visually

Separate Dashboard sections list images and volumes with their sizes and usage status directly, supporting the same removal and inspection operations available through the CLI, but with the added benefit of seeing everything at once in a sortable, filterable list rather than needing to construct a specific docker images or docker volume ls query:

docker images
docker volume ls

This visual overview is particularly useful for quickly identifying which images or volumes are consuming the most space, since the Dashboard typically presents this information sorted and immediately visible, without needing a separate docker system df -v command and manual review of its output.

When the GUI is genuinely more convenient

The Dashboard's real value is in interactive, exploratory, one-off tasks, quickly checking a container's status, glancing at recent logs, removing a handful of unused images, where the overhead of opening a terminal and recalling exact command syntax would exceed the actual time needed to accomplish the task through a few clicks instead.

Click container > View Logs > scroll and search visually

When CLI or scripting remains necessary

Anything requiring repeatability, automation, or precise, version-controlled configuration, a deployment script, a CI pipeline step, a routine maintenance task run on a schedule, needs the CLI or an equivalent programmatic interface, since the GUI has no mechanism for recording, repeating, or version-controlling a sequence of actions performed through it:

#!/bin/sh
docker compose pull
docker compose up -d
docker image prune -f

A script like this can be reviewed, version-controlled, and run identically every time; the equivalent sequence of GUI clicks has none of these properties and would need to be manually repeated, with no record of exactly what was done, every single time.

GUI settings as a layer over CLI-equivalent configuration

Many Dashboard settings, resource allocation, file sharing paths, the active backend, correspond directly to configuration that could otherwise be set through Docker Desktop's own configuration files or command-line flags, and understanding this correspondence is useful when troubleshooting needs to move beyond what the GUI itself surfaces:

cat ~/Library/Group\ Containers/group.com.docker/settings.json

Reviewing the underlying settings file directly can reveal the exact, current configuration in a form more amenable to scripting, version control, or sharing a known-good configuration across a team, compared to relying entirely on someone manually replicating a sequence of GUI settings adjustments.

Common mistakes

  • Relying on the GUI for any task that genuinely needs to be repeatable, automated, or version-controlled, rather than reserving it for interactive, one-off, exploratory work specifically.
  • Not recognizing that GUI actions and CLI commands are functionally equivalent, leading to confusion about whether something accomplished through one is genuinely the same as the equivalent done through the other.
  • Forgetting that the GUI provides no record of what actions were taken through it, making it a poor fit for anything needing an auditable history of changes.
  • Overlooking the underlying configuration file that GUI settings actually write to, missing an opportunity to script or version-control a known-good Desktop configuration directly.
  • Defaulting to typing CLI commands for genuinely quick, exploratory checks where the GUI would have accomplished the same thing with less friction and less need to recall exact syntax.

Desktop GUI control provides a genuinely convenient, visual alternative to CLI commands for interactive, exploratory, one-off operations, container management, log viewing, interactive shell access, image and volume inspection, while anything requiring repeatability, automation, or version control still depends on the CLI or an equivalent scriptable interface, since the GUI itself has no mechanism for recording or repeating a sequence of actions performed through it.