Dockhand swaps its Apache 2.0 date for a rolling window and a commercial license

3 October 2026. A thread on r/selfhosted flags license changes in Dockhand’s GitHub repository. 9 October 2026. noted.lol confirms the changes after reviewing the license and the commit. 9 October 2026. The context sharpens: Dockhand is leading a poll on Docker management tools, weeks after Portainer announced its 3.0 release would pivot toward Kubernetes. Why it matters: Dockhand was the fallback recommendation for users leaving Portainer; its license changed exactly when those users are looking to move in.

Dockhand is a web interface for managing Docker containers: a dashboard to deploy, supervise and drive containers, manage their networks and volumes, and read the state of a fleet from a browser. Its positioning — simple, modern, close to what Portainer offered before its pivot — explains why it drew attention so quickly from users hunting for an alternative.

BSL 1.1: the code is visible, but it is not open source

Dockhand ships under the Business Source License 1.1 (BSL 1.1). The term invites confusion: the source code is publicly available, but BSL is not an open-source license by the OSI’s definition. It allows reading and some uses while restricting others — typically commercial production use — and schedules a deferred conversion to a genuinely open license.

That “deferred conversion” is precisely what just changed, and the detail is where it matters. A BSL is only as good as two parameters: what it forbids before conversion, and when conversion happens. Dockhand just changed both.

BSL 1.1 rests on three clauses visible in the LICENSE file: the Change License, which the code converts to — here Apache 2.0; the Change Date, which sets the deadline — now rolling; and the Additional Use Grant, which lists the allowed uses before conversion, including the homelab and educational exemptions. It is in that last clause that the commercial restriction lives: any production use not covered by the exemption requires a paid license.

What changed, concretely

First, the conversion date. Previously, Dockhand’s terms said the code would move to Apache 2.0 on 1 January 2029 — a fixed, readable date everyone could plan around. That date has been replaced with a rolling four-year conversion: each version moves to Apache 2.0 four years after its own release date. A release shipped in October 2026 would not convert until October 2030 — and a later release pushes the horizon further out.

Second, commercial use. The updated terms generally require businesses using Dockhand in production to purchase a commercial license. Exceptions exist — personal homelabs, qualifying nonprofits, educational organisations, and individuals running their own infrastructure without employees — but the principle is set: professional use becomes paid.

In plain terms, the hobbyist running Dockhand on a home server pays nothing, now or later. The company using it in production must buy a license.

There is also a grey zone. The updated terms carve out individuals running their own infrastructure “without employees using it alongside them” — which leaves the precise boundary of “production use” to the vendor’s interpretation. A small side project that earns money should not assume it is automatically exempt; the safe move is to ask, in writing, before building anything that touches revenue.

The practical effect of the rolling window is subtle but real. Under the old fixed date, every version would become Apache 2.0 in January 2029, so pinning an older release still guaranteed a near-term open future. Under the rolling window, the open version is always four years behind — a fine outcome for reading the code, but useless for anyone waiting to fork a current feature set.

A well-documented industry precedent

The mechanism did not start with Dockhand. BSL 1.1, created by MariaDB in 2017, was popularised by HashiCorp when it moved Terraform from MPL 2.0 to BSL in August 2023, prompting the OpenTofu fork. Redis and Sentinel followed in 2024 with non-free licenses. Each time, the pattern repeats: the code stays readable, the deferred conversion acts as a pressure valve, and the community splits between those who accept the compromise and those who fork.

What Dockhand changes relative to the standard model is the move from a fixed date to a rolling window. A fixed date gives usable certainty; a four-year per-version window pushes the horizon out indefinitely for recent releases. It is a signal from a vendor that wants to keep monetising new versions, and it should be read as such.

The Portainer context changes everything

This does not land in a vacuum. It comes weeks after Portainer announced that its 3.0 release would focus primarily on Kubernetes — a shift we documented in our analysis of Portainer 3.0. That announcement pushed many Docker users to look for an alternative, and Dockhand was among the most frequently recommended tools.

The sequence is uncomfortable for newcomers: they are fleeing a tool whose direction they distrust, only to land on another whose license just tightened its commercial terms. noted.lol notes that Dockhand was leading its Docker manager poll at publication time, and that the Reddit thread drew hundreds of votes, with alternatives like Arcane and Komodo named as replacements.

What homelab users should do

There is no urgency for personal use. Dockhand remains free for homelabs, and existing installs are not invalidated overnight. The real question is long-term dependence: adopting a management tool means investing time in configurations, automations and habits that outlive every upgrade.

The license change does not make Dockhand dangerous. It says a lot about the trajectory: like Terraform before it, a project that chooses a rolling-window BSL signals it intends to monetise professional users, and that full open-sourcing is no longer a dated promise but a horizon that recedes as the product advances.

In practice, three habits are enough: export your stacks and configs regularly, since they are text and therefore portable; watch the repository and its releases for further tightening; and keep a tested alternative — Arcane or Komodo — so you are not caught off guard if the terms shift again.

The most common confusion concerns what “open source” means here. Dockhand is source-available: you can read the code, audit it and contribute, but you cannot use it freely for commercial purposes until the conversion takes place. For a homelab the difference is thin; for a company that might want to fork or resell it, it is decisive.

Step back and the pattern is familiar. The self-hosted ecosystem has spent 2026 watching a string of projects tighten their terms — Portainer pivoting to Kubernetes, now Dockhand shifting its license — and each time the same question returns: how much control do you actually keep over software you run yourself? The answer increasingly depends on which license sits in the repository, not on where the container runs.

Verdict

If you are an individual managing containers on a homelab, Dockhand remains a legitimate, free choice — but keep your configurations exportable and watch the license. If you are a company, compare the commercial license cost against Arcane or Komodo before standardising, and do not build your deployment automations on a tool whose terms just changed without notice. In every case, read the license before you adopt, not after: BSL 1.1 is a vendor decision, and it is yours to decide whether it fits.

References

• noted.lol — Dockhand Changes Its License, Raising Concerns Among Self-Hosters
• ETTAYEB — Portainer 3.0 drops the Community Edition