What Is Moby, Really?
It's easy to get confused. You type docker run and think you're using Docker. You are, but the code that makes it all happen lives here, in the Moby project. Since 2017, Moby has served as the open-source upstream for Docker Engine. Think of it less as a finished car and more as a factory that provides all the core parts: the engine, the chassis, the transmission, and the blueprints to assemble them. Docker Engine is one popular model assembled from these parts, but Moby's purpose is to allow anyone to build their own custom vehicle.
The README uses the perfect analogy: a 'Lego set'. Moby provides a vast collection of components for software containerization: a runtime, build tools, a registry, networking, and orchestration tools. It's a project for builders, a place where the fundamental problems of container technology are solved so that others can construct higher-level platforms on top of a stable, well-maintained foundation.
A Toolkit for Builders
Moby's core philosophy is 'batteries included but swappable'. This principle makes it exceptionally powerful for systems integrators. Out of the box, the project provides everything needed to assemble a fully featured container system. However, its modular architecture means you can replace individual components. This flexibility is crucial for anyone building a specialized platform, such as a custom PaaS or a container-optimized operating system. You get the benefit of a decade of development and bug-fixing on the core components, while retaining the freedom to innovate on the parts that are unique to your use case.
The target audience is explicitly not the everyday application developer. It's for the platform engineers and open-source contributors who are working one level of abstraction below. The APIs and documentation are tailored for this audience, focusing on functionality and control rather than a polished end-user experience.
The Go Developer's Experience
For Go developers, Moby is the definitive source for interacting with the Docker Engine API. A critical, recent development is the project's migration of its Go modules. As of the v29 release in late 2025, the long-standing github.com/docker/docker module is deprecated. The new, supported homes for the Go client and API types are github.com/moby/moby/client and github.com/moby/moby/api, respectively.
This was a major, and breaking, change. The README is admirably clear about the migration, providing diffs and linking to release notes. This move, while causing short-term pain for developers who had to update their import paths and adapt to API changes, is a sign of a healthy project. It modernizes the codebase, clarifies the project's identity separate from the Docker product, and follows current best practices for Go modules. The documentation also issues a stark warning: the root module, github.com/moby/moby/v2, is only for building the engine binaries and offers no API stability guarantees. This is an essential piece of information that prevents developers from building fragile integrations by depending on internal code.
Community Health and Project Velocity
A project's vitality can be judged by its activity, and Moby is thriving. With a release just last week and code pushed today, development is continuous. Its 72,000 stars on GitHub signal its central role in the software world. The nearly 4,000 open issues might initially seem concerning, but for a project of this scale and maturity, it's a sign of a massive, engaged user base that is constantly testing its limits and contributing feedback. A project with zero issues is often a project with zero users.
As the upstream for Docker, it benefits from the resources of Docker Inc., but it operates as a truly open project. It welcomes external maintainers and contributors, ensuring its longevity and direction are guided by the broader container community. This governance model has been key to its sustained success and relevance.
Where Moby Fits in Your Stack
Moby is the foundational layer. You don't typically choose 'Moby' for an application stack; you choose it when you are building the platform that the applications will run on. For example, if you were creating a specialized CI/CD system that needs to build and run containers in an isolated way, you would use the Moby Go client to talk to the engine. If you were designing a custom Linux distribution for edge devices that needed robust container support, you might build a custom engine from Moby's source.
This is where it contrasts with its alternatives. You'd pick Podman when your priority is a daemonless, rootless workflow that mirrors the Docker CLI experience. You'd choose containerd when you need a lower-level, minimal runtime to be controlled by a higher-level orchestrator like Kubernetes, which famously swapped out the full Docker Engine for containerd years ago. Moby, as the full-featured engine toolkit, sits at a higher level of abstraction than containerd but is the source from which tools like the standard Docker Engine are built.