Moby — Overview#

Identity#

Purpose#

Moby is the open-source upstream project behind Docker Engine — a modular toolkit for building and running container-based systems. It provides the container runtime daemon (dockerd), image management, networking, storage drivers, and cluster orchestration (Swarm) as composable components. Its primary audience is engineers, integrators, and platform builders who want to assemble custom container infrastructure rather than use a packaged product.

Significance#

Moby is one of the most influential infrastructure projects in the Go ecosystem: it predates the Go module system, shaped container standardization through OCI (runc, containerd, image-spec), and directly underpins Docker Desktop, Docker Engine CE, and several third-party runtimes. Its architectural decisions — such as splitting the runtime into containerd + shim layers, standardizing image layers with OCI, and implementing pluggable networking via libnetwork — became de-facto industry patterns. The project has tens of thousands of GitHub stars and is maintained by a large, active community.

Key metrics#

  • Go files: 2,145 (excluding vendor)
  • Top-level directories: api, client, cmd, contrib, daemon, dockerversion, docs, errdefs, hack, integration, integration-cli, internal, man, pkg, project, releases, vendor
  • Direct dependencies: ~115 (go.mod require block, non-indirect)
  • Indirect dependencies: ~178 (go.mod)
  • go.sum entries: 1,108 lines
  • Package distribution: daemon/ (~247 subdirs) dominates; api/ and client/ are now separate sub-modules (moby/moby/api, moby/moby/client)

Notable characteristics#

  • XL monorepo with sub-module extraction in progress: The main daemon/ package contains the overwhelming majority of code (~247 packages), but api/ and client/ have already been extracted as independent Go modules (referenced via require github.com/moby/moby/api and require github.com/moby/moby/client in the root go.mod). This reflects an ongoing architectural decomposition toward independently versioned components.

  • Deep integration with the OCI/containerd ecosystem: Moby delegates container execution to containerd (v2.2.2) and references the OCI runtime-spec, image-spec, and go-digest directly. The daemon/containerd/ sub-package wires Moby’s image and snapshot abstractions onto containerd’s gRPC API — a significant architectural shift from the legacy daemon/graphdriver/ overlay-based system.

  • Dual storage backend strategy: The codebase contains both a legacy graphdriver path (daemon/graphdriver/) and a modern snapshotter path (daemon/snapshotter/, daemon/containerd/) with runtime feature detection (daemon/image_store_choice.go). This coexistence of old and new is a textbook example of a large project managing a multi-year migration.

  • Heavy use of platform-conditional compilation: Nearly every major subsystem has _linux.go, _windows.go, _unix.go, and _unsupported.go variants. The codebase compiles to a functional daemon on Linux, Windows (via HCSShim/LCOW), and in rootless mode — a significant cross-platform engineering effort.

  • Batteries-included networking via libnetwork: The daemon/libnetwork/ sub-package is an embedded, production-grade SDN stack supporting bridge, overlay (Swarm VXLAN via hashicorp/memberlist + serf), macvlan, ipvlan, and host networking. It uses an immutable radix tree (hashicorp/go-immutable-radix) and in-memory DB (hashicorp/go-memdb) for endpoint/network state — a self-contained distributed systems component embedded in the daemon.

  • Authorization plugin architecture: The pkg/authorization/ package implements a middleware-based HTTP authorization plugin system, allowing external processes to approve or deny Docker API calls. This is an early and notable example of runtime extensibility in a Go system daemon.

Backward Kubernetes — Testing Moby — Structure Forward