Git & Delivery Core A2 · Formal specification Platform: General

Container Registry

A container registry is a service that stores and shares container images. Repositories group related content inside the registry.

See how it works
You might call it image registryOCI registryDocker registry

See how it works

Original worked exampleContainer Registry
BUILD → RUN → RELEASEContainer Registryregistry host / repository : tag -> manifest digest -> blobs
REGISTRY.EXAMPLEAUTHORIZED
REPOSITORYteam/catalog:1.4scope: repository:team/catalog:pull
tag 1.4manifest sha256:91f…→
Cached bloba2f… ✓Missing blobb7d… ↓
Pull completedigest verified
RESULTThe client pulls a manifest and only the missing blobs.BOUNDARYA registry stores and distributes images. It does not run them.
registry host / repository : tag -> manifest digest -> blobsOPS
Container RegistryRuntime & progressive delivery

Another example

Registry `registry.example.com` contains repository `team/checkout`. A tag names a version; a digest identifies its exact manifest.

Main parts

  1. 01Registry host
  2. 02Repository path
  3. 03Tag
  4. 04Manifest digest
  5. 05Push and pull access
  6. 06Retention and audit rules

Use it when

Use a registry when build systems and runtime hosts need controlled image push and pull. Set access and retention rules. Configure audit logs when available.

Do not use it when

Do not call one repository the whole registry. Do not deploy an unknown tag without checking its digest and source.

Name used in code

registry host / repository : tag -> manifest digest -> blobs

Before you ship

Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback.

Request you can copy

Outcome: Use Container Registry to release or recover the change safely, with a clear record. User context: Registry `registry.example.com` contains repository `team/checkout`. A tag names a version; a digest identifies its exact manifest. Delivery concept or operation: Container Registry. Why it fits: Use a registry when build systems and runtime hosts need controlled image push and pull. Set access and retention rules. Configure audit logs when available. Do not use it when: Do not call one repository the whole registry. Do not deploy an unknown tag without checking its digest and source. Delivery requirements: Name the code repository and target. List preconditions, changes, review and CI checks, conflict and data-loss risks, release order, and the rollback or recovery command. Repository safeguards: Keep unpublished work and a clear history. Do not run destructive steps without an explicit backup. Check the exact code diff and remote target before publishing. Acceptance criteria: Review the intended diff and pass all required checks. Keep the target version traceable. Practice failure recovery and keep published history clear. Evidence and limits (evidence boundary): A formal document may still be a draft, release candidate, or final version. Check its status and browser or platform support. Unknowns to confirm: Repository, branch, team activity, release environment, approval owner, protected checks, and rollback target.

Check this request

Review the current use of Container Registry. Definition: A container registry is a service that stores and shares container images. Repositories group related content inside the registry. Release checks: Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.

A2
How official is this term?

Formal specification

A published, versioned formal specification defines this term for the listed technical scope.

A formal document may still be a draft, release candidate, or final version. Check its status and browser or platform support.

Scope
OCI Distribution Specification 1.1.1 Registry definition and distribution API; not vendor products, interfaces, access policies, or retention behavior
Document status
stable
Checked on
2026-07-30

Evidence sources & scope

Authority source + Term reference · Open Container Initiative · stable OCI Distribution Specification 1.1.1 — Definitions — Registry Definitions — Registry Scope: OCI Distribution Specification 1.1.1 Registry definition and distribution API; not vendor registry interfaces, policies, or retention behavior; direct scope: Definitions — Registry Role here: Direct term reference Source covers: canonical name, definition, semantics, implementation Authority source · Open Container Initiative · stable OCI Distribution Specification 1.1.1 Scope: OCI Distribution Specification 1.1.1 Registry definition and distribution API; not vendor registry interfaces, policies, or retention behavior Role here: Authority within stated scope Source covers: canonical name, definition, semantics, implementation Background source Azure Container Registry documentation Role here: Helpful background, not a definition Background source Microsoft Learn — Azure Container Registry concepts (Traditional Chinese) Role here: Helpful background, not a definition

Copy it yourself

The browser could not copy this. Select the request below and copy it yourself.