Docker Registry v2

The data plane. Dodil Registry serves the Docker Registry HTTP API v2 — the OCI Distribution Specification — under /v2/ on the registry host. Any conformant client (docker, podman, oras, buildkit, skopeo, crane, registry libraries) works as-is.

You normally never call these endpoints yourself; this page exists so you know what’s on the wire and can point tooling at it.

Names on the wire

The v2 <name> of a repository is <org>/<repo>:


registry.dodil.io/acme/web:1.2.0
                  └── <name> ──┘

Core endpoints

Endpoint	Method(s)	Purpose
`/v2/`	`GET`	API version check — the “am I talking to a v2 registry” probe
`/v2/<name>/manifests/<reference>`	`GET`, `HEAD`, `PUT`, `DELETE`	Fetch / check / push / delete an image manifest (reference = tag or digest)
`/v2/<name>/blobs/<digest>`	`GET`, `HEAD`, `DELETE`	Fetch / check layer and config blobs by digest
`/v2/<name>/blobs/uploads/`	`POST`, `PATCH`, `PUT`	Start and drive a (chunked or monolithic) blob upload
`/v2/<name>/tags/list`	`GET`	List tags in a repository

Semantics — error codes, chunked upload flow, content negotiation of manifest media types — are exactly the upstream spec’s; see the distribution spec and the classic Docker Registry HTTP API V2 reference .

Auth

Standard registry auth: docker login registry.dodil.io with any username and a dk_ API key as the password (see API Reference — Auth). Public repositories accept anonymous GET/HEAD (pull); every push requires credentials.

What the v2 plane does not do

Repository listing across the org, vulnerability reports, and visibility are not part of the v2 protocol — that’s what the control plane is for. The one management behavior the v2 plane does drive: pushing to a new <name> creates the repository.

Quick probe


curl -u "ci:dk_..." https://registry.dodil.io/v2/
# HTTP 200 → authenticated against a v2 registry
 
curl -u "ci:dk_..." https://registry.dodil.io/v2/acme/web/tags/list


{ "name": "acme/web", "tags": ["latest", "1.2.0"] }