Docker Desktop gets a supported command line controller
Docker Desktop 4.39 makes its controller CLI generally available, with application logs and explicit platform selection for image archives.
Starting a container and starting the application that hosts its engine are different operations. Docker Desktop's command line controller makes that distinction visible. With Desktop 4.39, the controller reaches general availability, and its new logs command gives terminal users a direct way to inspect the application they depend on.
The release notes date 4.39.0 to March 5. Docker's March 6 announcement explains the controller's progression from the beta introduced in Desktop 4.37. The supported operations cover Desktop's own lifecycle, including starting and stopping it, restarting it, and checking its status.
I appreciate Docker most when an environment can be described and reproduced without a sequence of manual actions. A supported controller fits that preference. It lets a command line workflow include the state of Desktop itself, which is an input to the container operations that follow.
Desktop state is part of the workflow
The announcement presents the controller as a way to move between the graphical application and terminal operations. That is more specific than adding another way to run a container. The controller manages the application, while the familiar image and container operations remain the work performed through the engine.
For a script, this creates a place to express a prerequisite that might otherwise remain in a setup document. A developer can inspect Desktop status before attempting an operation that needs it. Restarting the application also becomes a named command line operation, with a defined interface instead of a dependency on window interaction.
The important property is that Docker supports this interface as part of Desktop. A script built around a documented controller has a different maintenance relationship from one that assumes a window title or an internal process arrangement. The GA announcement establishes the controller as an intended integration point.
Docker also identifies administrative automation as a use case. The announcement discusses using the commands to manage updates, and it describes printing logs alongside the lifecycle operations. Those functions make sense together because the same person who changes application state often needs evidence of what happened during the transition.
That does not make every Desktop operation equivalent to a daemon API call. A controller command concerns the Desktop application and its management. Keeping the two responsibilities distinct helps explain where an error belongs. A container definition can be valid while the application supplying its execution environment is unavailable.
Application logs have their own command
The new operation highlighted by the release is straightforward. It prints Docker Desktop log entries through the CLI.
docker desktop logs
Its value follows from the target of the command. A failure in Desktop startup is different from output produced by the process inside a container. Access to application logs helps investigate the former without pretending that the container's own output contains the answer.
The release notes give several examples of Desktop-level failures. Resource Saver could fail to engage again immediately after an engine restart. On Mac, startup could hang while the backend consumed a full CPU. These are failures of application behavior or its managed environment, so a route to Desktop logs is relevant even when no useful application container has started.
Other fixes concern the boundary between Desktop and API clients. The notes describe a three-second delay affecting clients other than the CLI and Desktop whenever a container with port mappings existed. That qualification matters. A workflow using another client could suffer a delay while the familiar interactive tools appeared unaffected.
The release also fixes Kubernetes clusters that stopped working because their PKI certificates expired. Again, the symptom belongs to a managed subsystem with its own lifecycle. A single Desktop installation can expose several kinds of failure, and diagnosing one requires identifying which component produced it.
My interest in this command is practical. Build reproducibility does not eliminate the need to inspect the system performing the build. Giving the host application a supported logging command makes that inspection easier to include in an ordinary terminal workflow.
An image archive can select one architecture
Desktop 4.39 also exposes platform filtering for image import and export. The announcement gives an export that selects the ARM64 member of a multi-platform image. The image reference here follows that illustrative example.
docker save --platform linux/arm64 -o my-image.tar my-app:latest
The choice concerns which variant the archive contains. A multi-platform name can identify content for several execution environments. A transfer intended for one architecture can now state that requirement directly, instead of relying on whichever variant an operator happens to assume the name represents.
Import has the corresponding selection. Docker's announcement describes choosing the AMD64 variant when loading a multi-architecture archive. This makes the receiving side's selection explicit as well, which is useful when the source artifact contains more than the destination requires.
History gains platform selection too. An operator examining a multi-platform image needs to identify which member's build history is relevant. The flag connects the inspection to that member, so conclusions about its construction do not rest on an unspecified architecture.
These operations solve different parts of one ambiguity. Saving chooses what leaves the machine. Loading chooses what enters the store from an archive. History chooses which member to inspect. The common platform value makes the intended architecture visible in each operation.
For someone who prefers small service images, the distinction is useful even when the executable is simple. The artifact still has an intended platform, and a multi-platform reference can contain multiple artifacts. A concise runtime image does not remove the need to select the correct member for an export or inspection.
The host runtime remains part of container behavior
The Mac fixes in the release notes illustrate how much container execution depends on the managed host environment. Docker downgraded the Linux kernel to 6.10.14 to address an OpenJDK problem involving cgroup controller identification. The notes also record a fix for Java programs emitting a SIGILL error on M4 MacBook Pro systems.
Those changes concern compatibility beneath the application image. They explain why Desktop lifecycle control and application diagnostics deserve their own interface. The same image description can encounter a problem in the environment that runs it, and the useful evidence then includes the managed runtime version.
The 4.39 announcement also describes expanded Docker AI Agent capabilities, including access to MCP servers and Kubernetes operations. That work adds another caller of local tools. A supported command interface remains useful because operations still need an identifiable target and inspectable result, regardless of how the caller selected them.
For this release, the controller's GA status establishes a supported place for scripts to manage Desktop. The logs command makes application evidence available alongside that control. Platform selection supplies a separate improvement to image handling, with the intended archive member now written into the command that saves, loads, or inspects it.