Distribution

What it is

Distribution is the reference implementation of the OCI Distribution Spec — the protocol that governs how container images get pushed, pulled, and stored in a registry. If you've ever run docker push or docker pull, there's a good chance Distribution's API is what's on the other end. It's not a registry product with a UI and RBAC — it's the engine underneath one. Docker Hub, GitLab Container Registry, and Harbor all build on it or implement compatible APIs against its spec.

Category placement as "Provisioning" is a bit loose — it's closer to core registry infrastructure than to environment provisioning, but the practical effect is the same: it's a foundational piece you stand up before anything else in your image supply chain works.

Who builds it and why

Originally Docker's own registry implementation (docker/distribution), it was donated to CNCF and now lives under the distribution/distribution org. 597 contributors is a large number for a project this narrowly scoped, which tells you it's load-bearing infrastructure for a lot of organizations — not a side project. Companies running their own registries (cloud providers, CI platforms, registry vendors) have direct incentive to keep it maintained since forking or replacing it is expensive.

CNCF sandbox status is worth noting here: sandbox is CNCF's earliest maturity tier, mostly signaling governance intake rather than technical immaturity. Distribution predates its CNCF donation by years and has been running production registries since the Docker Hub days — the sandbox label undersells its actual battle-testing.

Production readiness signal

Strong. 10,488 GitHub stars, active commits through mid-2026, and a contributor base in the high hundreds are all signals of a project under continuous real-world load, not one coasting on legacy adoption. Apache-2.0 licensing removes any copyleft friction for embedding it in commercial products. Go as the implementation language matches the rest of the container ecosystem (Docker, containerd, Kubernetes itself), so it integrates cleanly without cross-language friction.

v3.1.1 as the current release suggests a mature, incrementally-versioned project rather than one still finding its API surface. Founding date isn't publicly available in the data here, but given its Docker lineage, this is a project with roughly a decade of production history, not a recent bet.

Who should use this

• Teams building or operating a private/internal container registry from scratch
• Vendors and platform teams embedding registry functionality into a larger product (CI/CD platforms, internal developer platforms, air-gapped environments)
• Organizations that need full control over registry storage backends (S3, Azure Blob, filesystem, etc.) and don't want vendor lock-in to a managed registry
• Anyone needing OCI Distribution Spec compliance for interoperability with existing tooling

Who should NOT use this

• Teams that just need a registry and don't want to operate one — use a managed offering (ECR, GCR, ACR, Docker Hub) instead of standing up and patching Distribution yourself
• Organizations wanting registry features like fine-grained RBAC, vulnerability scanning, image signing UI, or replication policies out of the box — Distribution gives you the storage/API layer, not the governance layer. Look at Harbor if you want those bundled.
• Anyone expecting active community support for edge-case bugs — sandbox-tier CNCF projects don't carry the same support guarantees as graduated projects; you're largely on your own or reliant on vendor support if you're using a downstream product.
• Small teams with no existing platform engineering capacity — running your own registry infrastructure is operational overhead you may not need.

Alternatives

• Harbor — CNCF graduated project, wraps Distribution with RBAC, scanning, replication, and a UI; the natural upgrade path if you need more than raw registry API.
• Zot — a newer, OCI-native registry written in Go with a smaller footprint and built-in scanning/GC, positioned as a lighter alternative to Distribution.
• Managed registries (ECR, GCR, ACR, Docker Hub) — if you don't want to operate registry infrastructure at all, these remove the operational burden entirely at the cost of control and portability.

Pricing

Fully open source, Apache-2.0. No paid tier, no vendor. Your cost is entirely operational — compute, storage, and the engineering time to run and secure it yourself.