Docker (Moby)

Moby is the open source project maintained by Docker, Inc. and the community that produces Docker Engine — the container runtime, image builder, and networking stack that powers container execution on Linux and Windows hosts. Rather than being an end-user product, Moby is explicitly framed as a “Lego set” of modular components: a daemon, a versioned REST API, an independently versioned Go client SDK, and a builder, meant for engineers who want to assemble their own container-based systems rather than consume a finished product.

Architecturally, dockerd wires together subsystems for containers, images, volumes, networking (via an in-tree libnetwork), the Dockerfile/BuildKit-based builder, and swarm-mode clustering. Image, content, and snapshot handling is delegated to containerd instead of a bespoke storage driver, aligning the engine with the wider OCI ecosystem while retaining the familiar Docker CLI/API surface. The public API types and Go client ship as separately versioned modules from the root engine binary, which itself is not meant to be imported as a library — a deliberate API-stability boundary.

The project is extremely active and heavily used: it carries tens of thousands of GitHub stars, sustained triple-digit monthly commit volume, and a release cadence that ships versioned Docker Engine builds roughly monthly alongside independently tagged API and client releases. It’s licensed under Apache 2.0 with no license keys or self-hosting restrictions — commercial products like Docker Desktop and Mirantis Container Runtime build on top of Moby but live outside this repository.

Moby is not aimed at people looking for a supported, packaged product — it’s for engineers, integrators, and container tooling authors who want to hack on, extend, or embed the actual engine that underlies the broader Docker ecosystem.

What You Get

• The dockerd daemon binary and its full container lifecycle engine (create, run, network, exec, remove)
• A versioned REST API with a generated Swagger specification for programmatic control of the engine
• An independently versioned Go client SDK (github.com/moby/moby/client) for building tools against the Engine API
• An integrated builder with BuildKit support for building OCI images from Dockerfiles
• libnetwork-based container networking (bridge, overlay, macvlan) built directly into the daemon
• Swarm-mode clustering and service orchestration primitives without needing a separate control plane

Common Use Cases

• Running the Docker Engine on servers - self-hosters and cloud providers run dockerd directly to power CI runners, PaaS platforms, and developer environments.
• Building custom container platforms - integrators embed Moby’s modular components to assemble specialized container systems without adopting the full Docker product.
• Powering higher-level products - Docker Desktop, Mirantis Container Runtime, and various CI/CD systems use Moby as their upstream engine.
• Programmatic container automation - developers use the Go client or REST API to build orchestration tools, dev-environment managers, and testing harnesses.
• Lightweight built-in clustering - teams needing simple orchestration use the daemon’s swarm mode instead of adopting a separate Kubernetes control plane.

Under The Hood

Architecture Moby/Docker Engine follows a layered client-server architecture: a minimal entrypoint boots the daemon, and the bulk of the logic lives in a central daemon package that wires together subsystems for containers, images, networking, volumes, the builder, and swarm clustering. Image and snapshot management is delegated to containerd rather than a bespoke storage graphdriver, and this backend integration surfaces through dedicated handler files for each image operation. An HTTP API server exposes daemon functionality over a versioned REST API generated from a shared Swagger specification, with request/response types defined in a package consumed by both the daemon and an independently versioned Go client SDK — a clean separation that lets the client and API evolve on their own release cadence apart from the root engine binary. A dedicated error-definitions package formalizes cross-package error contracts through interfaces rather than sentinel values, enforcing consistent HTTP status mapping at the API boundary. Changing the containerd-backed image/snapshotter abstraction would ripple through the image handlers, the builder’s remote-context resolution, and every API endpoint returning image metadata — a wide but well-isolated blast radius given the strong directory boundaries.

Tech Stack Written in Go, the project is structured as a multi-module repository: the root module builds the daemon binary and is explicitly not meant to be imported as a library, while the API types and Go client ship as separate, independently versioned modules. The runtime layer offloads image, content, and snapshot management to containerd rather than maintaining an in-tree storage driver stack, and image builds are handled through an integrated BuildKit pipeline. Networking runs on an in-tree libnetwork implementation supporting multiple drivers. The REST API is generated and validated from a Swagger specification using protobuf-based code generation declared as build tooling. Cloud and observability integrations span major cloud logging providers and OpenTelemetry, alongside platform-specific integration for both Linux (cgroups, AppArmor, SELinux) and Windows (Hyper-V, native Windows container APIs) hosts. Build tooling is Make- and BuildKit-bake-based, with dependencies vendored directly into the repository.

Code Quality Testing is extensive, spanning colocated unit tests alongside dedicated integration and CLI-level black-box test suites that exercise the daemon end-to-end. Error handling is explicit and typed through a dedicated error-definitions package whose interfaces are asserted with helper functions rather than raw sentinel errors, wrapped through Go’s standard error-chain conventions. Naming conventions are idiomatic Go, with consistent platform-suffixed files enabling build-tag-based cross-platform compilation. CI is comprehensive, with dedicated workflows for unit testing, BuildKit integration, static analysis via CodeQL, multiple Windows Server versions, VM-based testing, and even a security scanner for the CI configuration itself.

What Makes It Unique Moby popularized rather than invented the modern container runtime model, but its ongoing technical differentiation is genuine: it was among the first mainstream engines to fully delegate image, content, and snapshot management to containerd instead of maintaining a bespoke storage layer, giving it a shared, OCI-compliant runtime foundation while still exposing the higher-level Docker UX — CLI, API, and BuildKit-integrated builds — on top. Its split of API types and client SDK into independently versioned modules, decoupled from a non-importable root engine module, is a deliberate solution to a Go monorepo versioning problem most container projects don’t bother addressing. It is not novel in the sense of introducing a new paradigm — containerd, Podman, and CRI-O compete on the same primitives — so its strength is disciplined engineering rather than a groundbreaking idea.

Self-Hosting

Licensing Model Apache License 2.0 — the entire codebase, including the daemon, API, and client, is fully open source with no restrictions or license keys required for self-hosted use.

Self-Hosting Restrictions None found — there are no ee/, enterprise/, or pro/ directories in the repository, and no license-gating logic was found in the source.

Enterprise Features Moby itself ships no paid tier. Commercial support and packaging (Docker Desktop, Docker Business, Mirantis Container Runtime) are built on top of Moby by Docker, Inc. and Mirantis but live outside this repository.

Cloud vs Self-Hosted Not applicable — Moby is a self-hosted engine only; Docker Hub and Docker Desktop are separate commercial products built around it, not a hosted version of the engine itself.

License Key Required No.