Moby is the Apache-2.0 licensed upstream for Docker Engine, offering modular components for building custom container systems. It targets developers who want to modify or reassemble container infrastructure, not end users seeking commercial support.

Can I use moby/moby commercially?

Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is moby/moby still maintained?

Yes. The repository received new commits within the last day.

What programming language is moby/moby written in?

Mainly Go, according to GitHub's language statistics.

Moby Project Review: Building Custom Container Engines from Docker's Upstream

At a glance

What is it?: Moby is the Apache-2.0 licensed upstream for Docker Engine, offering modular components for building custom container systems. It targets developers who want to modify or reassemble container infrastructure, not end users seeking commercial support.
Who is it for?: Adopt Moby if you are an engineer or integrator who needs to build or modify a container engine from source, using its modular components and Go client. Do not use it if you need commercial support or a stable library import; the root module is binary-only and has no API guarantees.
Can I use it commercially?: Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository received new commits within the last day.
What is it written in?: Mainly Go, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · August 8, 2026 · moby/moby

What Moby Actually Is and Who It Serves

Moby is the open source project that Docker created and still uses as the upstream for Docker Engine. The README describes it as a "Lego set" of toolkit components: container build tools, a registry, orchestration tools, a runtime, and more. The intended audience is narrow: engineers, integrators, and enthusiasts who want to modify, hack, fix, experiment, or invent container-based systems. It is explicitly not for people looking for a commercially supported system. That distinction matters. If you want a supported container platform, the README points you to Docker Desktop or Mirantis Container Runtime. Moby is the raw material, not the finished product.

The Modular Architecture and Swappable Components

The README states four principles: modular, batteries included but swappable, usable security, and developer focused. The modular principle means components have well-defined functions and APIs that work together. The swappable principle is the key design choice: Moby includes enough to build a full container system, but most components can be replaced with different implementations. This is a deliberate trade-off. You get a working default set, but you are expected to replace parts when your use case demands it. The developer focus means the APIs are not end-user tools; they are building blocks for developers. The documentation and UX target developers, not operators. That is a clear boundary: Moby assumes you can read code and understand container internals.

How the Codebase Is Organized: Two Stable Modules Plus a Binary-Only Root

The repository uses Go modules with a specific structure. The root module is github.com/moby/moby/v2, which is the codebase for building container engines like Docker Engine. The README is explicit: this root module produces binaries only and is not intended to be imported as a Go library. It has no API stability guarantees. In contrast, two public modules are supported for import: github.com/moby/moby/client, the Go client for the Docker Engine API, and github.com/moby/moby/api, which holds API types shared between client and server. These two modules are versioned independently with their own tags, such as client/v1.x.x and api/v1.x.x. This separation is practical: you can use the client without pulling in the entire engine codebase.

Release Tags and Versioning: The docker- Prefix Trap

Docker Engine releases are tagged with a docker- prefix, for example docker-v29.0.0. The README warns that these tags are only used to build the Docker Engine binary from the root module and must not be consumed via go get. That is a critical constraint for anyone tempted to pull a specific engine version as a dependency. The client and api modules use their own versioning scheme. The recent releases show the pattern: docker-v29.8.0-rc.1, docker-v29.7.2, and docker-v29.7.1. The release candidate tag indicates the project follows a pre-release cycle. For a developer, this means you must track two versioning schemes: the engine tags and the module tags, and they do not align directly.

Migrating from github.com/docker/docker: Breaking Changes in v29

The README marks the old Go module github.com/docker/docker as deprecated starting with Docker v29 (released November 2025) and states it will not be updated. Migration requires changing import paths: from github.com/docker/docker/client to github.com/moby/moby/client, and from github.com/docker/docker/api/types to github.com/moby/moby/api/types. The README warns that v29 includes many breaking API changes: option structs, renamed methods, and moved types. The full list is in the v29.0.0 release notes. This is not a simple find-and-replace. If you maintain a tool that talks to the Docker Engine API, you must budget time for API migration. The deprecation is recent, so many existing projects may still use the old path, and you will need to decide when to move.

Getting Started: Commands and Configuration You Can Actually Use

The README does not provide installation commands, but it gives enough to start. You can clone the repository and build the engine binary from the root module. The release tags like docker-v29.7.2 identify the source for a given engine version. For Go developers, the migration section shows the exact import changes. There is no docker build or run command in the README, so do not expect a quick start guide. The project assumes you know how to build a Go project. The Go modules are the main entry point: use go get with the client or api module paths, but avoid the root module. The README links to pkg.go.dev for the modules, which is where you would find API documentation. The lack of a setup walkthrough is consistent with the developer-focused audience.

Limitations and When Moby Is the Wrong Tool

The most obvious limitation is the lack of commercial support. Releases are supported by maintainers, community, and users on a best-efforts basis only. If your production system depends on a container engine, Moby alone is not a support contract. The root module's no-API-stability guarantee is another limitation: you cannot treat the engine code as a stable library. The README also includes a legal notice about use and transfer being subject to restrictions by the United States and other governments. That is a real consideration for international teams. Moby is the wrong tool if you want a turnkey container platform or a stable Go library for engine internals. It is also wrong if you need enterprise support; the README explicitly directs those users to Docker Desktop or Mirantis Container Runtime.

Alternatives and How They Differ

The README names two commercial alternatives: Docker Desktop and Mirantis Container Runtime. Docker Desktop is a product that packages Docker Engine with a GUI and additional features, aimed at developers who want a supported, ready-to-run environment. Mirantis Container Runtime is another commercial offering that uses Moby components but provides enterprise support. The difference is approach: Moby is upstream source code with no support guarantees, while these products are downstream distributions with support contracts and additional tooling. If you need a supported container runtime, you choose one of those. If you need to build your own engine or integrate Moby components into a custom system, you use Moby directly. The README makes clear that all uses of Moby as upstream are treated equally, so you can fork or reuse components without special status.

Maintenance, Upgrade Cost, and License Implications

The project is actively maintained, with the last push in August 2026 and recent releases including a release candidate. The README does not specify a release cadence, but the tags suggest regular minor versions. Upgrade cost is significant for v29: the breaking API changes in the Go SDK mean you must update client code when moving from older versions. The deprecation of github.com/docker/docker means you cannot rely on the old module path for future fixes. The license is Apache-2.0, which is permissive for use and modification, but the README includes a legal notice about export restrictions. That is not legal advice, but it signals that you should review the NOTICE document and relevant laws before distributing a system built from Moby. The maintenance model is community-driven with best-effort support, so you should expect to handle issues yourself or contribute fixes upstream.

Editorial conclusion

Adopt Moby if you are an engineer or integrator who needs to build or modify a container engine from source, using its modular components and Go client. Do not use it if you need commercial support or a stable library import; the root module is binary-only and has no API guarantees. Before adopting, verify the v29 breaking changes in the release notes, confirm your Go SDK imports match the new client and api module paths, and check that your use complies with export restrictions noted in the README. Moby is a development upstream, not a product, so plan for maintenance on a best-effort basis.

Official sources

Community notes