Docker Engine's source, not the Docker product
Moby is easy to misread because the repository produces Docker Engine binaries and carries years of Docker history. The project describes itself as a set of components for assembling container systems. Docker uses it upstream, while other vendors can reuse or replace pieces. Its intended reader is an engine developer who wants to change container behavior, not an application developer looking for a friendly way to start a database.
That distinction shapes the code. Moby values modular APIs and replaceable implementations over a prescribed user experience. The source covers daemon behavior, image management, networking, volumes, execution, and Swarm orchestration. Related work lives in other repositories, including containerd for runtime primitives, BuildKit for builds, and docker/cli for the familiar command. A usable product assembles these pieces, packages them for an operating system, and supports the resulting combination.
The Apache 2.0 license permits broad reuse. Support expectations are equally clear. Repository releases receive best-effort support from maintainers, community members, and users. The README sends companies that need commercial support toward Docker Desktop or Mirantis Container Runtime. If a team only wants to run containers, starting from Moby source adds responsibility without improving the daily experience.
The Go module boundary matters
Docker v29 changed how Go consumers should treat this repository. The old github.com/docker/docker module is deprecated and will not receive updates. Applications that call the Engine API should import github.com/moby/moby/client; code sharing API types should use github.com/moby/moby/api. Those modules carry independent versions and tags.
The root github.com/moby/moby/v2 module exists to build engine binaries. Its APIs can change without library compatibility guarantees. Docker Engine tags use a docker- prefix and are also intended for binary builds, not consumption through go get. Using the root module ties an application to daemon internals that the maintainers explicitly decline to stabilize.
For most Go teams, the client module is the sensible choice. It provides a supported path to the Engine API without vendoring an engine. Forking the root becomes reasonable only when the daemon itself must change, such as for a storage integration, networking behavior, or container platform based on Moby.
What happened when we ran it
We cloned commit d93602c into a fresh unprivileged Debian container with three CPUs, 8 GB of memory, Go 1.24, and no secrets. The checkout contained 3,281 files, about 382,561 lines of source, and occupied 29.9 MB. Installation succeeded in 92 seconds and installed 0 packages. That zero describes the harness's package count, not an absence of Go dependencies.
The build succeeded in 188 seconds. This matters because the repository's core source could compile within the constrained container even though the environment could not provide the privileges expected by every test.
Tests continued until our 900-second limit and timed out. The Go parser recorded 19 passing and 4 failing tests out of 23. The tail shows TestGetCapabilitiesFromLegacyDriver, TestGetDefaultAddressSpaces, and TestRemoteDriver failing when they tried to create /etc/docker and received permission denied. The fourth failure is not visible in the supplied tail, so we cannot describe it. A timeout with four recorded failures is plainly not a pass.
These findings also show why a generic unprivileged container is an incomplete Moby development environment. Some packages can build and some tests can run, while daemon and networking code touches host-level paths and facilities. Contributors should use the project's documented targets and a disposable Docker-capable host, then narrow tests to the subsystem they changed before running wider suites.
Development assumes control of the host
Moby's contributor environment is a Docker image built from the repository. The documented prerequisites are Git, Make, and a current Docker installation. make shell creates the environment and opens a privileged container. Inside it, repository scripts build dockerd, install the binary, and start a debug daemon.
Privilege is expected because an engine manipulates namespaces, mounts, networks, cgroups, and container processes. That makes the source tree a bad fit for a casual hosted coding sandbox or a shared workstation holding important local containers. Use an isolated machine or virtual machine where daemon restarts, network changes, and disposable image state will not interrupt other work.
Testing is divided by responsibility. Go unit tests live near packages. API integration tests send requests to a daemon and inspect both the responses and daemon state. The wider path crosses repository boundaries because the user-facing CLI is maintained separately. This is normal for an engine, but it means one root command cannot reproduce every product combination.
Mature engineering, permanent platform movement
The repository was pushed on August 27, 2026. Docker Engine v29.7.2 was released on August 6. It fixed image-pull regressions on older kernels, an environment-variable panic in the separate CLI, and nftables compatibility, while updating BuildKit. GitHub reported 3,905 open issues and pull requests combined. The queue is large, but the recent push and current release show active maintenance.
Maturity here does not mean the environment stands still. Kernel behavior, containerd, runc, storage drivers, nftables, Windows, and API compatibility all move underneath the daemon. Moby has the history and contributor base to address that work, while downstream vendors still inherit the duty to test their kernel, runtime, filesystem, and networking combination.
Use packaged Docker Engine or Podman for ordinary container work. Use the Moby client when an application needs to control an existing engine. Take on the root source only when changing and supporting the engine is the actual job, because the build is just the beginning of that responsibility.