docker

/v2/

Container images, as a registry mirror dockerd already understands

Point your client at it

json

// /etc/docker/daemon.json
{ "registry-mirrors": ["http://HOST:10220"] }

Replace HOST with your mirror’s address. Port 10220 is the server’s default.

Upstream: https://registry-1.docker.io
What is stored: Manifests and layer blobs in the blob store and catalogued; tag resolution revalidated.

How it works

This is the odd one out: it answers at /v2/, not under a /docker/ prefix like every other backend here. That is not an inconsistency but the point — /v2/ is the path the Registry API specifies, and serving it there is what lets an unmodified dockerd treat LibWorld as a registry mirror with one line of daemon.json.
Docker Hub wants a pull token even for public images. LibWorld fetches those transparently, so your clients stay anonymous and you configure no credential anywhere.
A digest addresses exact bytes, so manifests and blobs fetched by digest are cached permanently. A TAG is only a moving pointer to a digest, so tags are revalidated — which is why :latest still means what upstream currently says it means.
Multi-arch manifest lists are handled as first-class objects, so pulling on arm64 and amd64 both resolve correctly.

Things that have cost real time

Written down because they were paid for once already.

The Accept sent upstream deliberately includes the manifest-list types, so a multi-arch tag comes back as its index and the client then re-requests the platform manifest by digest — which is an immutable path this mirror already serves from cache. A pull-through cache never needs to know the caller's architecture, and one that tried would be guessing on behalf of every machine behind it.