Overview
Store and manage your OCI-compliant container images and Helm charts from a single, workspace-scoped console. Registry gives your teams one place to push, pull, and govern artifacts, with vulnerability scanning, retention policies, deployment locks, and fine-grained access control built in, consolidating artifact storage and supply-chain governance into one consistent, IAM-integrated model.
Every namespace lives inside a workspace and exposes a registry URL your clients log in against.
Push and pull traffic flows straight through the registry data plane; the management operations
that need authorization and an audit trail, creating namespaces and repositories, deleting tags,
and setting policies, run through qibdo’s API and are gated by IAM.
Core resources
Section titled “Core resources”- Namespaces: the top-level isolation boundary inside a workspace’s registry. A namespace is pinned to a region, exposes a registry URL that clients authenticate against, and parents the repositories beneath it.
- Repositories: a named collection of artifacts (for example
nginxorredis). Each repository has a visibility (public or private), a format (Docker, Helm, or OCI) fixed at creation, and an optional immutable-tags setting that blocks overwriting a tag once it is pushed. - Artifacts and tags: an artifact is one OCI artifact, a manifest plus the blobs it
references, identified by a content digest (
sha256:…). A tag is a movable name that points at a digest; deleting a tag leaves the artifact in place unless it was the last reference. - Access control: access policies grant a principal (a user, group, or service account) a set of actions (pull, push, delete, or admin) over a namespace or a single repository. Cross-namespace grants extend a set of actions from one namespace to another, optionally limited by a tag pattern and an expiry.
- Supply-chain governance: scan policies configure vulnerability scanning, retention policies prune artifacts on a schedule (keep the last N, keep newer than N days, or keep tags matching a pattern), and deployment locks pin an in-use artifact so it cannot be deleted while a deployment depends on it.
- Operations: every mutation returns an operation record that captures the request and comes back already completed. A triggered vulnerability scan then runs asynchronously, with the artifact’s scan status advancing as it progresses.