Registry
A private OCI registry that scans
docker push, and the scan has already started.
A private OCI registry for your workspace. Every push to a tag is scanned, every finding names the version that fixes it, cosign signatures are recognised as signatures, and robots give CI exactly the access it needs.
- API
- OCI distribution
- Scanner
- Trivy
- Signing
- cosign · your KMS
- Multi-arch
- yes
$ docker push registry.subnomic.com/acme/api:1.4.0 1.4.0: digest: sha256:9f3a71c2… size: 3271
How it works
The commands you already type.
Log in
People log in with their account. CI logs in as a robot with its own secret, scoped to the repositories it needs.
$ echo "$ROBOT_SECRET" | docker login registry.subnomic.com \ -u 'robot$ci-pusher' --password-stdin Login Succeeded
Push
Repositories live under your workspace and are created on the first push, private. Multi-arch indexes and chunked uploads work as Docker and buildx expect.
$ docker push \
registry.subnomic.com/acme/api:1.4.0Read the verdict
The scan starts on push and never blocks it. Critical and high findings email the workspace owners; the tag shows what is affected and what fixes it.
What comes with a repository
Supply-chain state you do not have to go looking for.
Scanned on every push
Trivy scans each tag as it lands, and you can rescan whenever you like. A scan that fails says so — it is never shown as clean.
Findings with the fix
Up to 200 findings per image, worst first, each with its package, installed version and the version that fixes it.
SBOM on request
Generate a CycloneDX or SPDX-JSON bill of materials for any tag, read it as a package list or download it.
cosign-aware
Signature tags in either cosign format count as signatures: hidden from the tag list, shown as signed, and never pruned by retention.
Sign with your own key
Keep the key in AWS KMS, GCP KMS, Azure Key Vault or HashiCorp Vault — or upload one that is encrypted at rest and never written to disk. Rotated keys still verify old signatures.
Robot accounts
Pull, push and delete, for one repository or the whole workspace, with an optional expiry. Disable, rotate or delete; the secret is shown once.
Retention rules
Keep the last N tags, or tags pushed in the last N days, filtered by a pattern. Unreferenced layers are collected every hour.
Transfers
Import a tag from another registry, or export one to it. Credentials for the other side are used for that job and never stored.
Pull statistics
Pulls and pushes, storage used, a daily pull trend and the ten most-pulled repositories.
Findings
What is vulnerable, and what fixes it.
The repository list carries the counts that matter — critical, high, never scanned, signed or not — so the image that needs attention is visible before anybody opens it. The tag carries the detail.
- Each finding has its CVE, the package, the installed version and the fixed version, or says there is no fix yet.
- A critical or high result notifies the workspace owners in the app and by email.
- Signing is a deliberate step — “Sign now” with the workspace key — and the verify commands for your own pipeline are one copy away.
Compatibility
What the registry speaks, and what it does not do yet.
Scanning and signing tell you about an image; nothing in the registry refuses a push or a pull because of them. Verify signatures in your deploy pipeline or admission controller with the workspace’s public key.
Supported
- OCI image manifests and indexes, Docker v2 manifests and manifest lists — multi-arch included
- Monolithic and chunked uploads, cross-repository mount within the workspace
- Pull, push and delete by tag or digest; tag listing and catalog with paging
- Nested repository paths, created on first push and private by default
Not today
- —The referrers API — artifacts pushed only by digest are removed by garbage collection
- —Immutable tags — pushing a tag again moves it, so deploy by digest
- —Anonymous pulls, pull-through caching and continuous replication
- —Keyless signing and a transparency log
Plans
On every plan, including Free.
Every plan
The registry, scanning, SBOMs, signing and robots are not a paid add-on.
Not a plan limit
Images do not count toward the plan’s stored bytes, and there is no per-image price.
Your own key
Signing needs a key per workspace — in your KMS, or uploaded and encrypted.
Questions
Before you move CI over.
Can CI log in with an API token?
Use a robot account: robot$<name> and its secret. Workspace API keys work on the management API, not on docker login.
Does it block vulnerable or unsigned images?
No. The scan and the signature state tell you; the decision stays in your pipeline, where cosign verify or an admission controller can refuse a deploy.
Can people pull without logging in?
No — every pull needs a token, so the registry is for private images. Use a pull-only robot for anything that runs unattended.
Are tags immutable?
No. Pushing the same tag again moves it to the new image, so deploy by digest when it matters which bytes run.
The rest of the workspace
Same bill, same credentials, same audit log.
Push your first image in a minute.
Create a workspace, log in, push. The registry is included on the free plan.