Docker Desktop reaches the end of its subscription grace period
The January deadline applies to Docker Desktop in larger businesses. Its significance lies in the distinction between a maintained development environment and the open source container tools it contains.
Docker Desktop makes several separately maintained tools feel like one local development environment. That convenience is the subject of the subscription deadline arriving today. Docker's December newsletter identifies January 31, 2022 as the end of the grace period for its revised subscription agreement. The distinction between the Desktop product and its constituent tools matters more than the familiar whale icon suggests.
The change was announced on August 31, 2021. Docker's announcement says professional use of Desktop in larger businesses requires a paid Pro, Team or Business subscription. Personal use, education and non-commercial open source projects remain eligible for free use. Small businesses qualify when they have fewer than 250 employees and less than $10 million in annual revenue. Both conditions matter. Counting the engineers who install Desktop does not answer whether the business meets those conditions.
I value Docker principally for repeatable build files and images that can move between machines. That makes the product boundary especially relevant here. A decision about the development environment should preserve a clear understanding of which parts of the build and distribution process actually depend on it.
What the subscription covers
The August announcement explicitly leaves the licensing terms of Docker Engine and upstream Docker and Moby projects unchanged. It also says existing Pro and Team plans include commercial Desktop use. An organization can therefore need a paid Desktop subscription without needing the Business tier. The question of permission to use the product and the question of which administrative capabilities to buy have different answers.
This distinction changes how the deadline should be discussed inside an engineering organization. A statement that all container development now requires a subscription would make the scope seem larger than Docker announced. A statement that the change affects only a graphical dashboard would make it seem smaller. Product inventory needs to describe the installed Desktop package and the work it supports. A list of repositories containing Dockerfiles cannot establish that inventory by itself.
The deadline also concerns an existing transition. January 31 is the end of the grace period, not the original effective date of the revised terms. Those dates describe different stages of the same change. Docker's newsletter repeats the deadline months after the announcement, which makes it a useful contemporary reminder for organizations finishing their transition.
The maintained environment behind the command line
Docker explained the package in its September account of Desktop's implementation. Linux containers run inside a Linux virtual machine on Mac and Windows. Desktop maintains that environment and integrates it with the host filesystem and network. It also distributes the command line tools alongside the dashboard.
That integration explains why a terminal user can still depend on Desktop. The interface used to request a container does not identify the software maintaining its execution environment. Host access to a container port and access to source files inside a container require work across the virtual machine boundary. Docker describes port mapping, bind mounts and filesystem change notifications as parts of that work. Those are relevant capabilities even when the dashboard remains closed.
For a replacement evaluation, the meaningful comparison is the development environment the package supplies. A different installation may provide the required container tools, but equivalence depends on the workflows developers need. Source editing through a shared directory can have different requirements from building an image from a fixed input. Running a local service that a browser must reach introduces another integration requirement. These are consequences of the architecture, not reasons to assume that every developer needs the same package.
I consider maintained host integration a reasonable thing to charge for. The engineering question is whether that maintained integration is valuable enough for the work being done. Familiar command spelling alone gives little information about the cost of maintaining an alternative environment.
Identity management is a separate purchasing reason
There is also a concrete administrative addition available before the grace period expires. Docker introduced single sign-on for Business customers on January 13. It supports authentication through an organization's identity provider, with SAML 2.0 and Azure Active Directory named in the announcement. A user who successfully signs in with the configured company domain can join the Docker organization automatically.
The announcement distinguishes browser authentication from command line credentials. Existing users moving to SSO need personal access tokens for the Docker CLI, and pipeline automation must replace passwords with tokens. Enabling an identity provider does not remove those credential requirements. Organizations evaluating Business therefore have a specific integration task to consider alongside the subscription decision.
That distinction prevents an overly simple account of what SSO buys. Central authentication can improve control over interactive access, while automation still needs credentials that fit its execution model. An engineer choosing a subscription for personal commercial use has a different requirement from an administrator managing company access. The existence of the latter requirement does not imply that every covered user must purchase the same tier.
Browser authentication changes the local interaction
Docker's account of sign-in in Desktop 4.4.2 describes another visible part of this transition. Selecting Sign in in the dashboard or menu opens the default browser. The browser handles authentication before returning the user to Desktop. This gives the desktop application an authentication flow that can accommodate the identity provider integration.
The local container workflow and the organizational account workflow now deserve separate descriptions in internal documentation. A developer may know how to build a service while having no reason to know how the company provisions its Docker organization. Clear ownership of those account steps reduces ambiguity when a new developer sets up a machine. It also makes the subscription choice more concrete than a general discussion about whether containers should cost money.
My preference is to keep build definitions explicit enough that a choice of workstation package does not become an undocumented application requirement. That preference is compatible with paying for Desktop where its integration is useful. The practical consequence of today's deadline is a need to name that dependency accurately and choose the subscription that covers the actual use and administrative requirements.