The EWC container registry stores and distributes container images and other OCI artifacts.

On top of plain image storage it adds access control and other features you need to use container images safely in a team or production environment.

You interact with the service in three ways:

  • Web User Interface —  for browsing projects, inspecting images, and managing settings.
  • Container Engine CLI — e.g. "docker" or "podman" commands to push and pull images.

  • Kubernetes - clusters pull images from the container registry to run the workloads. The image is referenced in a Pod/Deployment spec and grant access with an image pull secret (typically backed by a robot account).


Basic Concepts


An artifact on the registry is stored with the following notation :

<registry>/<project>/<repository>:<tag>
└─ registry.example.com / my-team / my-app : 1.2.0


The following table describes the meaning of the adopted terms :

TermDescription
ProjectA namespace that groups related repositories. Access control, quotas, and policies are set per project. A project can be "public" or "private". 
RepositoryA named collection of images that share a purpose (e.g. one app). It holds many versions distinguished by tag.
ArtifactA single stored object — usually a container image, but can also be a Helm chart or other OCI artifact. Identified by a content digest ("sha256:…").
TagA human-friendly, movable label pointing at an artifact (e.g. "1.2.0", "latest"). Multiple tags can point to the same artifact. 


Tags vs. digests

A "tag" is mutable: `latest` can point at a different image tomorrow. A "digest" (`sha256:…`) is immutable and always refers to the exact same content.

It is recommended to use tags for convenience, and digests just when you need a guaranteed-identical image.

  • No labels