Docker Extensions become part of the desktop workflow

A container image can distribute a developer tool as well as an application service. That is the useful design choice behind Docker Extensions, which become generally available in Docker Desktop 4.16 on January 12. The extension model gives tool authors a place inside the desktop application without requiring Docker to implement each tool itself. Quick Search reaches general availability in the same release and includes extensions in its results. Discovery and execution now share more of the same interface.

I value Docker most for making an environment into something that can be built and shipped between machines. Extensions apply that packaging idea to the tools around the environment. The interesting question is how much integration an image can provide once its contents include a user interface and instructions for installing it. The answer helps explain why this release concerns tool authors as much as people who run containers.

An image becomes an installed tool

Docker introduced the beta in its May 2022 Extensions announcement. It described specially formatted Docker images as the extension package and opened the SDK to developers. Extensions were available across Personal, Pro, Team and Business subscriptions. That initial design matters because it made the extension mechanism available beyond vendors with a separate distribution arrangement.

An image package gives the tool author an explicit deliverable. Installing an extension is a separate operation from browsing its source or running its development server. This distinction is useful even for a small internal tool. A maintainer can discuss the installed package when diagnosing a problem, while the source tree continues to change. It also makes packaging part of the tool itself, instead of leaving installation knowledge in a developer's shell history.

Docker's first-extension tutorial shows how the pieces fit together. Its generated project contains a React interface and a Go backend. The backend listens on a socket and exposes a small HTTP endpoint. A multistage Dockerfile builds the backend and interface, then places the resulting binary and assets in the final image. Desktop installs the interface and starts the backend service.

This is a useful separation of responsibilities. The interface can present an operation in terms a developer recognizes, while the backend owns the implementation. The final image contains what installation needs. Someone building an extension therefore has to think about its runtime contents, not merely whether the interface works in a development browser. Generated files help establish that structure, but the package remains a software deliverable that its author maintains.

A backend is optional

A simpler example appears in Docker's June 2022 Flappy Dock walkthrough. The game demonstrates a frontend-only extension. Docker Desktop extracts a web application from the image and displays it within the desktop interface. A metadata file identifies the assets and the dashboard tab. The example is deliberately small, which makes the packaging contract easier to see.

The following metadata follows that example's structure, with a different tab title. It assumes that the image contains the named icon and the web application at the specified paths.

{
  "icon": "docker.svg",
  "ui": {
    "dashboard-tab": {
      "title": "Local tools",
      "root": "ui",
      "src": "index.html"
    }
  }
}

Here, the image is a distribution package for files that Desktop knows how to display. It does not imply that the extension needs a permanently running application server. That distinction affects the design of a tool. A page that only presents information has different runtime needs from a tool that performs operations through a backend service. Adding a backend should follow from the work the extension performs.

The metadata also makes an installation error more concrete. The interface path is part of a declared package layout. If the assets move, the declaration must move with them. This is ordinary application packaging work, and it remains necessary when the application happens to appear inside Docker Desktop. Integration reduces the number of places a user must visit, while the extension author still owns the consistency of the package.

Search changes how a tool gets used

The 4.16 announcement places extension installation alongside search for containers and images. Developers can find local containers or Compose applications and perform actions such as opening logs or a terminal. Extensions appear in the same search experience and can be installed from their results. This makes search an entry point for work that previously required knowing which part of the interface to open.

For an extension author, that changes the importance of the listing. A tool's name and description have to explain its purpose to someone who has not installed it. A technically sound package can still be difficult to discover if its presentation assumes prior knowledge. Search integration makes that problem visible at the point where a developer is trying to complete a task.

For the user, shared discovery also creates a reason to distinguish the object being selected. An existing container and an extension package represent different operations. Opening logs examines something already running. Installing an extension adds software to the local toolset. Bringing both into search is convenient, but their purposes remain different when deciding what action to take.

I prefer this kind of integration when it exposes an operation clearly and leaves its implementation understandable. An extension should make the task easier to perform without making the installed software harder to identify. Docker's use of an image package gives that judgement a concrete object to examine.

General availability has a specific scope

The release notes promote Extensions and Quick Search separately. They also identify Rosetta for Linux on macOS 13 as a new beta. Those labels describe individual capabilities, so the status of the extension mechanism does not extend to every experimental option in the same Desktop release. This is a useful distinction when explaining what an upgrade changes.

The January announcement also says that the SDK is generally available across platforms. That gives authors a supported starting point for building tools, while each extension still needs a useful purpose and a maintained package. General availability of the mechanism cannot establish the quality of every program distributed through it.

The practical opportunity is a local tool with a defined installation format and a visible place in the developer's existing environment. Frontend-only packages can remain small. Tools that require a backend can ship its implementation with their interface. Quick Search makes both easier to find, and the image gives maintainers a specific package to build, install and discuss when that tool needs to change.