--- title: "Registry: images, charts and models, signed on push · Frazer" description: "A container registry inside your Frazer cloud: images, Helm charts, models and files pushed from CI with no stored password, scanned and signed on every push, pulled from a cache next to your servers." url: https://frazer.ai/registry index: https://frazer.ai/llms.txt tokens: 2457 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # Registry: images, charts and models, signed on push · Frazer **Registry** frazer.ai # A registry inside your cloud. Every push scanned and signed. Push images, Helm charts, models and files from CI with no stored password. Frazer scans every push and signs the digest with your project’s key, and your clusters run only signed digests. Nodes pull from their peers and a cache at your site first. [Push your first image](https://frazer.ai/start?product=registry) [Read the docs](https://frazer.ai/docs) *The Frazer console showing the image checkout-api in the apps repository of the demo organization Acme: 8 versions by digest, each signed on push with the project key except one imported version, 3 in use in a cluster, a service or a preview, 0 critical and 1 high findings in running versions, and a cleanup dry run that would delete 2 untagged versions. The selected digest shows who pushed it from which commit and workflow, and its signature, SBOM, provenance and vulnerability report attached as OCI referrers.* An image’s versions by digest: signature, findings, where each runs product UI, demo organization 01 · How it works Fig. 1 ## From a CI push to a running pod. No password, no unsigned digest. **Fig. 1** One identity from CI to the node, and the pull ladder 02 · Push from CI ## No registry password to store or leak. CI GitHub Actions presents its OIDC token and gets a 15-minute Frazer token that may push only to the repositories you name. People `frazer auth configure-docker` installs a credential helper. Docker takes a Frazer token that lasts at most an hour. Clusters Each cluster pulls with its own token, valid for at most an hour and renewed for it. Nothing is stored in Git. ``` $ frazer auth configure-docker # Docker now signs in with a Frazer token $ frazer registry repositories create apps --format docker \ --immutable 'v*,release-*' --dry-run $ frazer registry repositories create dockerhub --format docker \ --mode remote --upstream docker.io --credential dockerhub-pull $ docker push registry.frazer.ai/acme-production/apps/checkout-api:v1.42.0 # scanned on push, signed with sign-acme-production ``` ``` $ frazer registry images list apps/checkout-api $ frazer registry images describe apps/checkout-api@sha256:51ab… $ frazer registry cleanup dry-run apps # shows what a policy would delete; nothing in use ever is $ frazer registry versions restore apps/checkout-api@sha256:e5c2… ``` ``` $ frazer registry files push generic/tools ./bin/zctl --version 1.4.0 # an immutable, versioned file, signed like an image ``` 03 · Repository settings Fig. 2 ## Cleanup that never deletes what runs. One settings page per repository. Immutable tags, cleanup with a dry run, scanning with a deploy policy, and signing. By default a repository keeps what runs anywhere, keeps `v*` and `release-*` tags and the last 20 tagged versions, and deletes untagged versions after 14 days. *The settings of the repository apps in the Frazer console, demo organization Acme: tags v* and release-* are immutable while main-* and pr-* may move; cleanup keeps versions in use anywhere, v* and release-* tags and the last 20 tagged versions, and deletes untagged versions older than 14 days after a dry run that deleted nothing in use; Images are scanned on push, and new rollouts of a fixable critical vulnerability are blocked; Frazer signs each pushed digest with the project key. Beside it, the remote repository dockerhub reports that the upstream returned 429 and cached copies keep serving.* **Fig. 2** A repository’s settings, and a remote repository during an upstream 429 product UI, demo organization 04 · Formats and modes ## Images, charts, models, files. Pushed, cached or combined. Formats Frazer Registry holds, and the clients that push and pull them | Format | What it holds | Clients | | --- | --- | --- | | Docker and OCI | Images and multi-arch indexes, with signatures, SBOMs and provenance as referrers | docker, podman, buildx, crane, oras | | Helm | Charts as OCI artifacts | helm push oci:// | | Model | Model weights as OCI artifacts (ModelKit, ModelPack), exported from the model catalog or pushed by you | kit, oras, frazer ai models export --oci | | Generic | Versioned, immutable files: binaries, datasets, build outputs | oras, frazer registry files push | | npm, PyPI, Go modules | Packages with the same access, cleanup and scanning | npm, pnpm, yarn, pip, uv, GOPROXY | - ### Standard You push. Tags you mark immutable never move; digests never do. - ### Remote A pull-through cache of Docker Hub, GHCR, Quay, registry.k8s.io, NVIDIA NGC or any OCI registry. The first pull caches; later pulls come from the cache, also when the upstream is down or rate-limits. - ### Virtual One read endpoint over ordered repositories, such as `apps`, then `base-images`, then `dockerhub`. 05 · What you get ## The parts a registry needs. Including the ones you would script. - ### Signed on push Every digest, with your project’s key, in cosign format. - ### Scanned on push Every push, then daily for versions in use or pulled in 30 days. - ### Where it runs Each digest lists the clusters, services, boxes and agents running it. - ### Cleanup with a dry run Keep rules win. What runs is never deleted. - ### Recoverable for 30 days A deleted version comes back with one command. - ### Pulls close to the server Node peers first, then a cache at your site, then the region. - ### Import from another registry A dry run first; the import credential is deleted when the import closes. - ### Private endpoint in your VPC Pull without a public address. 06 · Controls ## Who pushes, who pulls. Every token and digest on the record. ### Who may do what Registry reader, writer, repo admin Bound per repository, or inherited from project roles. CI service account Pushes only to the repositories its token names, for 15 minutes. Clusters and devboxes Pull with their own tokens, valid for at most an hour. Agents Read through the `registry` MCP toolset. Pushing stays with CI. ### What is logged - Every token, with the repository and the workflow that asked for it - Every push and pull, with the digest and the real principal - Who pushed, from which commit and workflow, inside the signature - Every cleanup run and restore ### At the cap - Bytes are reserved before an upload is accepted; a layer counts once per project - A storage cap per repository warns at 80 % - Default quotas: 100 repositories and 5 TiB per project - A cleanup that would delete more than 20 % of versions, or anything pulled in 14 days, stops and asks - At a budget cap, storage keeps serving; nothing is deleted 07 · Pricing ## Storage is the only meter. No scan, signing or pull fees. Registry storage counts toward an allowance for every server you bring, pooled across your billing account, and a layer counts once per project. Above the allowance you pay the Frazer Storage rate. [See every price](https://frazer.ai/pricing#lines) Your servers 50 GB per server included Above that $0.012 / GiB-month · no scan or signing fee Inside Frazer No charge for pulls, scans, signatures or replication Imports No Frazer fee; the source bills its own egress, shown in the dry run Questions ## Registry, answered. Does CI need a registry password? No. GitHub Actions presents its OIDC token, Frazer maps it to a service account such as `ci-release`, and returns a 15-minute token that can push only to the repositories you named. Nothing to store, nothing to rotate. What does “signed on push” mean? When a digest arrives, Frazer signs it with your project’s key and attaches the signature as an OCI referrer. The signature records who pushed, the repository, the commit and the workflow. Clusters admit only signed digests; production enforces it. Can cleanup delete an image that is running? No. “In use in any cluster, service, box or agent” is a keep rule that cannot be switched off. Every policy runs as a dry run first, a run that would delete more than 20 % of versions stops and asks, and deleted versions stay recoverable for 30 days. What happens when an upstream registry rate-limits us? A remote repository caches every image you pull through it. When the upstream is down or answers 429, cached copies keep serving and only new tags wait. Each upstream has a pull budget, shown on the repository. Can we bring the images we already have? Yes. The import wizard only reads the source registry, shows a dry run item by item, copies digest for digest with their referrers and verifies each one. The credential you gave it is deleted when the import closes; until then you can re-run deltas for up to 30 days while you cut over. Does it hold models too? Yes, as OCI artifacts. `frazer ai models export --oci` writes a model from the catalog into a Model repository, signed like any image, and a ModelKit you push can be imported into the catalog. ## More in Build and ship - [**Fir** Version control built for agents](https://frazer.ai/source) - [**Frazer CI** Native CI on Frazer Runners](https://frazer.ai/ci) - [**GitHub runners** GitHub Actions in a microVM](https://frazer.ai/runners/github) - [**Cache** One cache for CI and boxes](https://frazer.ai/runners/github#cache) - [**Environments and GitOps** Connect a repo, roll out](https://frazer.ai/gitops) - [**Templates and previews** A preview per pull request](https://frazer.ai/previews) ## Push once, by digest. Run only what Frazer signed. [Push your first image](https://frazer.ai/start?product=registry) [Read the docs](https://frazer.ai/docs)