moby/moby

Architecture

Moby is a single Go module that produces the dockerd daemon and a few helper binaries. The daemon is a long-running HTTP server that translates Engine API requests into operations on containerd, libnetwork, an image/layer store, a volumes service, and (optionally) a swarm-mode cluster controller.

Top-level layout

Path	Role
`cmd/dockerd/`	`dockerd` entry point. Wires `daemon/command` and runs the daemon.
`cmd/docker-proxy/`	Userland TCP/UDP/SCTP port-forwarding helper used by the bridge driver.
`api/`	`swagger.yaml`, shared request/response types, swagger tooling. Its own Go module.
`client/`	Go client for the Engine API. Its own Go module.
`daemon/`	The bulk of the daemon: container lifecycle, images, networking, swarm, builder, server.
`daemon/server/`	HTTP server, routers, middlewares, backend interfaces.
`daemon/libnetwork/`	CNM networking, bridge/overlay/macvlan/ipvlan/null/host drivers, `libnetwork` controller.
`daemon/cluster/`	Embedded SwarmKit-based cluster manager (services, secrets, nodes).
`daemon/internal/distribution/`	Registry pull/push for the legacy v1 image store.
`daemon/internal/image/`	Legacy image store, layer assembly, tarexport.
`daemon/internal/libcontainerd/`	The bridge to `containerd` (local + remote shim, supervisor).
`daemon/internal/builder-next/`	BuildKit integration ("v1" builder).
`daemon/builder/`	Legacy "v0" classic Dockerfile builder, plus remote build context handling.
`daemon/containerd/`	Containerd-backed image service (the modern store).
`daemon/graphdriver/`	Legacy graphdrivers (overlay2, vfs, btrfs, zfs, fuse-overlayfs, windows).
`daemon/snapshotter/`	containerd snapshotter integration for the modern store.
`daemon/logger/`	Log driver registry and built-in drivers (json-file, journald, awslogs, gelf, etc.).
`daemon/volume/`	Volumes service, local driver, mount management, safepath helpers.
`daemon/pkg/`	Daemon-only utilities: authorization, plugins, registry, sysinfo, plugin store.
`pkg/`	Legacy public utility packages. No new code goes here.
`internal/`	Top-level internal helpers (testutil, namesgenerator, slice/iter helpers, tools).
`integration/`, `integration-cli/`	API integration tests; `integration-cli` is the deprecated legacy suite.
`hack/`	Build/test scripts, CI helpers, validation scripts.
`contrib/`	Init scripts, packaging hints, dev fixtures.
`docs/`	Project documentation (API CHANGELOG, contributing guide).
`project/`	Governance, branch/tag policy, release process.

Request lifecycle

A typical Engine API request flows through these layers:

sequenceDiagram
  participant Client
  participant Mux as gorilla/mux
  participant MW as middleware chain
  participant Router
  participant Backend
  participant CRD as containerd
  participant LN as libnetwork
  Client->>Mux: HTTP /v1.46/containers/create
  Mux->>MW: route match -> versioned mux
  MW->>MW: VersionMiddleware, CORS, Auth, Experimental
  MW->>Router: route.Handler()
  Router->>Backend: typed call (e.g. ContainerCreate)
  Backend->>CRD: pull image / create task
  Backend->>LN: allocate networks / sandbox
  CRD-->>Backend: container ID
  LN-->>Backend: endpoints attached
  Backend-->>Router: result struct
  Router-->>Client: JSON response

The HTTP plumbing lives in daemon/server/. Each subsystem exposes an interface to the routers under daemon/server/router/ and a backend implementation in daemon/server/backend/ that the Daemon struct satisfies.

The `Daemon` god-object

The daemon's central type is Daemon in daemon/daemon.go. It owns:

The container store (container.Store) and a separate read view (container.ViewDB).
An ImageService (containerd-backed or legacy graphdriver-backed; chosen at startup by daemon/image_store_choice.go).
A libnetwork.Controller for networking and a swarm cluster.Provider for cluster mode.
A volumesservice.VolumesService, a plugin.Manager, an events.Events bus, a stats.Collector, a registry.Service, and the containerdClient.
Per-runtime caches and singleflight groups for disk-usage queries.

daemon/daemon.go is ~1900 lines and is intentionally being split. The ROADMAP.md calls out "internal decoupling" and reducing this object as an ongoing goal.

Two image services, one daemon

Moby supports both the legacy graphdriver/layer-based image store and a containerd-backed store. The choice is made at startup in daemon/image_store_choice.go based on configuration and build/tags. The two services satisfy the same ImageService interface declared in daemon/image_service.go and are documented in Image management.

Two builders

The daemon ships two builders. The legacy classic builder lives in daemon/builder/ and reads Dockerfiles directly. BuildKit, the modern engine, lives in daemon/internal/builder-next/ and is wired in via the /build and /grpc endpoints. See Builder.

Build & deploy shape

dockerd is statically (or dynamically) linked, runs as root (or rootless via the daemon/internal/rootless/ helpers), and listens on a Unix socket and/or TCP. CI images are produced via the Dockerfile and docker-bake.hcl. The daemon talks to a separate containerd process and may launch the docker-proxy helper for port forwarding.