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