Docker Desktop puts port mappings beside container status

A running container and a reachable local service are different states. Docker Desktop Edge 2.1.7.0 makes it easier to see the relationship by showing port information inline with container status in its dashboard. The December 11 release notes identify this version as the release candidate for the next major Stable release. The port display is a small interface change tied to a concrete runtime fact.

The same notes describe corrections to dashboard navigation and overlapping shared directories. They also address moving the virtual-machine disk image and startup with an incomplete Kubernetes configuration. This is a Desktop maintenance release, so much of its value concerns the connection between application containers and the host environment used to develop them.

I value Docker because a build description produces an environment that can move between machines. The host endpoint used to reach that environment is a separate piece of information. Showing it beside status makes the dashboard describe more of the actual local deployment without changing what is inside the image.

A port number has two sides

The Docker CLI port documentation at 19.03.5 describes listing all mappings or requesting one private port's mapping. Its example maps container port 7890 over TCP to host port 4321. Those numbers need not match, and the protocol is part of identifying the mapping.

A compact inspection for the example container is enough to expose that distinction.

docker port test 7890/tcp

The documented result is a host binding at 0.0.0.0:4321. A query for the corresponding UDP port reports that no such public port is published. The same numeric container port therefore does not identify a usable endpoint without the protocol and published host-side mapping.

This is the information that belongs near a running status in a local management interface. Status answers whether the container is running. Port information helps identify where a client should connect. Neither answer alone supplies the other, and an application can be running while a developer looks at the wrong host port.

The December notes do not claim that inline port information is an application health check. It is a display of networking information. That scope is useful precisely because the mapping is a fact the runtime can report without interpreting whether the application's own request handling works.

The dashboard has become an application-management view

Earlier entries in the same release history establish the context for this change. The November 4 Edge release introduced a dashboard for interacting with containers and applications, accessing logs and viewing resource usage. On November 18, the release added starting and stopping Compose applications and viewing their combined logs. The December candidate refines an interface already handling those lifecycle operations.

Putting port information in the list reduces the need to enter a container's detail view just to find its published endpoint. This is an interface judgment based on the new placement, rather than a claim that the underlying port-mapping mechanism changed. The release notes announce visibility, not a different network protocol.

The navigation correction serves that same workflow. The notes describe inconsistent behavior of the back button when repeatedly switching between container details and Settings. Those destinations represent different tasks, inspecting a workload and changing Desktop configuration. Reliable navigation helps retain the relationship between the selected container and the information being examined.

The release does not describe a new dashboard data model. Its concrete changes are inline port information, the navigation fix and minor interface improvements. Reading them at that scope avoids treating a release candidate's interface refinement as an unannounced replacement of the container lifecycle commands.

Shared directories are outside the image contents

The overlapping-directory fix concerns files shared from the host. The notes also say Desktop stops injecting inotify events on directories because those events can make mount points disappear inside containers. Both entries concern the runtime view of host-provided files, which can change independently of the image's built contents.

This matters when interpreting a failure in a local container. Rebuilding an unchanged image does not directly correct how Desktop shares a host directory into a running environment. The filesystem seen by the process can include both image contents and host-mounted contents. The release's shared-directory corrections apply to the latter arrangement.

My preference for a small final service image remains useful for controlling what gets shipped. During development, however, an explicitly mounted source directory can supply files outside that artifact. Keeping that distinction visible helps explain why a Desktop integration fix can resolve behavior that the image build itself did not cause.

The release candidate therefore improves how the local environment can be inspected and how several host integrations behave. Inline port information provides the published endpoint beside container status. The directory and startup corrections address separate parts of Desktop's job, making host resources available to the environment in which those containers run.