Docker Desktop 4.1 opens volume management to every subscription

An image can be rebuilt while a volume contains data that the build cannot recreate. Making both visible in a development tool does not give them the same lifecycle. Docker Desktop 4.1.0, released September 30, makes volume management available to every subscription, including Docker Personal. The change broadens access to an interface for understanding persistent state around containers.

The release also adds a Software Updates section in Settings and moves the choice of Compose V2 into General settings. Those are changes in how Desktop exposes decisions that affect a development environment. The volume change is especially useful because the identity and references of stored data can become unclear after the containers around it have changed.

I prefer application images that contain only their runtime requirements. That keeps the delivered program small and makes its construction understandable. It also makes the separation from application data more important, since rebuilding that program is a different operation from recovering a database stored in a volume.

The interface arrived before access expanded

Docker introduced volume management in its June Desktop 3.4 announcement. That release supported creating and deleting volumes and displaying whether they were in use. It described richer exploration for Pro and Team users, including seeing contents and identifying the containers using a volume. September's release expands availability across subscription tiers.

This is a change in access to management functionality, rather than the invention of Docker volumes. The existing command line already exposes volume objects. The volume listing documentation for Docker CLI 20.10.8 describes listing the volumes known to Docker and selecting them through filters. A graphical view provides another way to examine that state.

The useful distinction is between inspecting an object and deciding what its contents mean. Docker can report references from containers. It cannot infer from that relationship alone that an unreferenced database is disposable. The interface supplies information relevant to a decision whose application meaning still belongs to the developer.

Unreferenced is a precise relationship

The CLI documentation defines the dangling filter as matching volumes not referenced by any containers. It does not define it as matching volumes without valuable data or volumes that have never been used. The following command lists that relationship without removing anything:

docker volume ls --filter dangling=true

A container reference is a property Docker can inspect. The continued value of the files is a different question. An old development dataset may remain useful after its container has been removed, while a referenced cache may be reproducible. Neither judgement follows just from the reference count.

The volume removal documentation states that a volume in use by a container cannot be removed. That protects a particular relationship. It does not turn every removal allowed by the engine into a correct application-level cleanup decision.

This distinction also explains why stopping a service and removing its persistent storage are separate operations. The volume exists as its own managed object. A view that shows both the object and its container associations helps a developer understand which operation they are about to perform, but the data lifecycle still needs an explicit decision.

Names and labels add useful context

The same listing command supports filtering by driver, name and label. Name matching can select part of a volume name. Labels can select the presence of a key or an exact key-value pair. These provide ways to narrow a list beyond the simple referenced or unreferenced distinction.

For an environment that assigns a project label, a listing can identify that intended grouping:

docker volume ls --filter label=project=example

This command assumes that the volumes were actually created with that label. A label is explicit metadata, so filtering cannot recover an ownership convention that was never recorded. Where the convention exists, it helps preserve a connection between a storage object and the project that uses it.

The documentation says multiple label filters are combined as an AND search. That makes a narrow query useful when several metadata properties need to match. The result still describes known Docker objects, rather than proving the completeness of a project's backup or recovery process.

Formatted output exposes names and drivers, along with scope and mountpoint information. The command supports Go templates for choosing fields. This gives automation a way to work with the same object identities that a developer might inspect in Desktop, provided the automation preserves the distinction between discovery and deletion.

The formatting rules also distinguish a plain template from one using the table directive. A plain template emits the selected data directly, while the table form includes column headers. That choice matters to callers consuming the output because display text and object names have different roles in a script.

I find the expanded interface useful for that discovery work. Persistent state deserves an identifiable object and a visible relationship to its consumers. It is easier to reason about an explicit named volume than to infer data ownership from whichever containers happen to be running.

Compose and updates get visible controls too

Desktop 4.1 also bundles Compose V2 and lets users select it through General settings. The release notes identify Compose 2.0.0 in the upgrade list. This makes implementation choice visible in the main configuration area, following the earlier beta rollout controls.

The Software Updates section reports available updates and allows downloading them or reading what they contain. It places information about the next bundle near the control that obtains it. Together with volume management, these changes expose different kinds of state a developer needs to understand, including persistent data and the installed tooling around it.

For volume management, the important result is wider access to inspection and management. The engine's reference relationships remain specific, and an unreferenced object can still contain needed application data. Desktop can make that object easier to examine while leaving the decision about its retention grounded in the application that produced its contents.