---
title: "Registry"
canonical: "https://admiral.io/docs/concepts/registry"
description: "Publish a repository you own, or pull a copy of an artifact you do not. Revisions are content-addressed, and tags are labels on those revisions."
---

# Registry

The registry is where a component's bytes live after they are published. An environment does not fetch those bytes again at deploy time. It pins a revision, and that pin is what a changeset reviews.

A registry revision is the published bytes, identified by digest. When a component applies, it [records the revision it runs](https://admiral.io/docs/concepts/changesets-and-runs.md#what-an-apply-records).

## Two ways in [#two-ways-in]

```mermaid
flowchart TB
Repo["<b>Repository you own</b><br/>admiral.yaml"] -->|publish| Reg["<b>Registry</b><br/>revision = sha256"]
Other["<b>Artifact you do not own</b><br/>chart, module, git, archive"] -->|pull a copy| Reg
Reg --> Pin["<b>Environment</b><br/>pins the digest"]
```

**Push** is for a repository the tenant owns. `admiral.yaml` at the repository root lists the component paths, and an optional name for each path. `admiral component publish` packs every declared path and pushes it. Publishing the same tree twice yields the same revision, so a pipeline that publishes everything on each push is safe. Admiral does not scan the repository for components, and it does not compute a version number.

**Pull** is for an artifact the tenant does not own: a Helm chart, a Terraform module, a git tree at a ref, or an archive at a URL. Admiral pulls it, stores a copy in the tenant's registry, and records where it came from and what the reference resolved to. The console calls this "Add component". The CLI calls it `component pull`. The copy is named after the artifact unless you name it, and a chart or module version becomes a tag.

A pull is a copy, not a pointer. Nothing in the deploy path fetches the upstream again. A wrapper chart is optional. Values belong on the environment. A wrapper that adds templates of its own, a chart plus a ClusterIssuer for example, is a real component and stays one.

A private pull names the [credentials](https://admiral.io/docs/concepts/sources-and-catalog.md#credentials) it may use. Those credentials are an argument of that pull. They are not stored on the component, and a later pull attaches its own.

## Tags [#tags]

A tag is a label on a revision, the way a Docker tag names an image digest.

| Tag                                  | Moves?        |
| ------------------------------------ | ------------- |
| Semver, such as `v1.2.0`             | No. Set once. |
| Floating, such as `latest` or `main` | Yes.          |

You refer to a revision as `NAME:TAG` or `NAME@DIGEST`. A changeset stores the digest it resolved, and it stores the reference you typed beside that digest. What was reviewed is what runs, even if the tag moves later.

Revisions are not deleted. An untagged revision stays, and it stays readable by digest.

A push to a tracked branch publishes the affected components under the branch name and `sha-<short>`. A git tag shaped `vX.Y.Z` publishes under that immutable tag. Anything else publishes with no tag unless the pipeline passes one. For Helm, a change to `version` in `Chart.yaml` is the semver event, and that version is applied as an immutable tag.

## Where to go next [#where-to-go-next]

* [Applications & Components](https://admiral.io/docs/concepts/applications-and-components.md): How an environment pins a revision as a component